Dalam pengaturan replikasi hosting MySQL, parameter Seconds_Behind_Master (SBM), seperti yang ditampilkan oleh perintah SHOW SLAVE STATUS, biasanya digunakan sebagai indikasi jeda replikasi saat ini dari slave . Dalam postingan blog ini, kami membahas cara memahami dan menafsirkan nilai ini dalam berbagai situasi.
Kemungkinan Nilai Detik Di Belakang Master
Nilai SBM, seperti yang dijelaskan dalam dokumentasi MySQL, bergantung pada status budak MySQL secara umum, dan status budak MySQL SQL_THREAD dan IO_THREAD pada khususnya. Sementara IO_THREAD terhubung dengan master dan membaca pembaruan, SQL_THREAD menerapkan pembaruan ini pada budak. Mari kita periksa kemungkinan nilai SBM selama status MySQL Slave yang berbeda.
Bila Nilai SBM adalah Null
- SBM selalu NULL jika slave Anda dihentikan, atau SQL Thread Anda dihentikan (atau tidak berjalan).
- SBM juga akan menjadi NULL jika IO Thread dihentikan, asalkan SQL Thread telah memproses semua peristiwa dari log relai. Contoh keluaran SHOW SLAVE STATUS (dipangkas untuk hanya menampilkan nilai yang menarik) menunjukkan hal ini:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Tidak
Slave_SQL_Running:Ya
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave telah membaca semua log relai; menunggu pembaruan lainnya
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Bila Nilai SBM adalah Nol atau Positif
- SBM akan mencerminkan nilai yang valid (>=0) saat SQL Thread secara aktif memproses peristiwa. Ini benar terlepas dari status IO Thread. Misalnya:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Tidak
Slave_SQL_Running:Ya
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Menunggu pekerja budak memproses antrean mereka
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Pada contoh di atas, kita dapat melihat bahwa slave berada di belakang master dengan membandingkan Retrieved_GTID_Set dan Executed_GTID_Set. Dalam kasus seperti itu, Seconds_Behind_Master akan mewakili perbedaan antara stempel waktu transaksi terakhir yang diproses oleh SQL Thread dan stempel waktu dari transaksi yang sama saat diproses di master. Stempel waktu transaksi master ini dipertahankan melalui replikasi dan karenanya slave akan dapat menghitung SBM secara lokal.
Selain itu, setelah slave sepenuhnya mengikuti semua log relai, (yaitu GTID yang dijalankan menjadi 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master akan putar ke '0' jika IO Thread sedang berjalan, atau ke 'NULL' jika IO Thread tidak berjalan.
Tutorial #MySQL – Memahami Detik Dibalik Master ValueKlik Untuk Tweet
Memahami Kecepatan Eksekusi MySQL Slave
Dengan asumsi bahwa SQL Thread dan IO Thread pada slave dalam status berjalan, dimungkinkan untuk memahami kecepatan eksekusi relatif master dan slave dengan memantau nilai SBM. Nilai '0' yang konsisten atau nilai konstan menunjukkan bahwa slave mengeksekusi pada kecepatan yang sama dengan master. Di sisi lain, kemiringan ke atas untuk Seconds_Behind_Master menunjukkan bahwa kinerja slave lebih lambat daripada master.
Konsol Pemantauan ScaleGrid untuk MySQL di Azure memplot nilai SBM dari waktu ke waktu untuk node slave.
Nilai SBM Nol Atau Konstan
Pada contoh di atas, slave dimulai sekitar 40 jam setelah master aktif menulis. Setelah dimulai, slave mulai mereplikasi data itu, dan kita melihat SBM cukup datar yang menunjukkan bahwa slave dieksekusi pada kecepatan yang sama dengan master. Perhatikan juga penurunan SBM ke '0' sangat curam, yang berarti bahwa meskipun transaksi terakhir yang dijalankan slave dijalankan sekitar 40 jam sebelumnya pada master, setelah kita mengejarnya, ada penundaan '0'.
Meningkatkan Nilai MBS
Pada grafik di bawah, kita dapat melihat bahwa SBM terus meningkat, yang berarti bahwa kecepatan eksekusi slave lebih rendah dibandingkan dengan master. Ini sebenarnya adalah kasus di mana kami menjalankan 20 utas melakukan penulisan terus menerus pada master dan budak utas tunggal tidak dapat mengimbanginya.
Terakhir, penting untuk dicatat bahwa dalam diskusi kami sejauh ini, kami tidak mengasumsikan adanya kemacetan jaringan. Dalam kasus jaringan lambat, IO Thread budak itu sendiri akan tertinggal di belakang master, dan jika Thread SQL cukup cepat, SBM akan berosilasi antara '0' dan angka positif. Dalam kasus seperti itu, SBM tidak akan menjadi parameter yang berguna untuk memahami kelambatan yang sebenarnya dengan master.
Jika Anda menyukai entri blog ini, lihat tutorial manajemen database MySQL populer lainnya untuk mempelajari lebih lanjut tentang mengoptimalkan penerapan Anda:
- Menghitung Ukuran Kumpulan Buffer InnoDB untuk Server MySQL Anda
- Tutorial MySQL – Mengonfigurasi dan Mengelola SSL di Server MySQL Anda
- Dijelaskan Kerangka Ketersediaan Tinggi MySQL – Bagian I:Pendahuluan
