Pengaturan cluster replikasi master/slave adalah kasus penggunaan umum di sebagian besar organisasi. Menggunakan Replikasi MySQL memungkinkan data Anda direplikasi di lingkungan yang berbeda dan menjamin bahwa informasi akan disalin. Ini asinkron dan utas tunggal (secara default), tetapi replikasi juga memungkinkan Anda untuk mengonfigurasinya menjadi sinkron (atau sebenarnya "semi-sinkron") dan dapat menjalankan utas budak ke beberapa utas atau paralel.
Ide ini sangat umum dan biasanya datang dengan penyiapan sederhana, menjadikan slave-nya sebagai pemulihan atau solusi cadangan. Namun, ini selalu ada harganya terutama ketika kueri buruk (seperti kurangnya kunci utama atau unik) direplikasi atau ada masalah dengan perangkat keras (seperti masalah jaringan atau IO disk). Ketika masalah ini terjadi, masalah yang paling umum dihadapi adalah jeda replikasi.
Replikasi lag adalah biaya penundaan untuk transaksi atau operasi yang dihitung berdasarkan perbedaan waktu eksekusi antara node utama/master dengan node standby/slave. Sebagian besar kasus tertentu di MySQL bergantung pada kueri buruk yang direplikasi seperti kurangnya kunci utama atau indeks buruk, perangkat keras jaringan yang buruk atau kartu jaringan yang tidak berfungsi, lokasi yang jauh antara wilayah atau zona yang berbeda, atau beberapa proses seperti pencadangan fisik yang berjalan dapat menyebabkan database MySQL Anda untuk menunda penerapan transaksi yang direplikasi saat ini. Ini adalah kasus yang sangat umum ketika mendiagnosis masalah ini. Di blog ini, kami akan memeriksa cara menangani kasus ini dan apa yang harus dilakukan jika Anda mengalami jeda replikasi MySQL.
"SHOW SLAVE STATUS":Mantra MySQL DBA
Dalam beberapa kasus, ini adalah solusi terbaik ketika berhadapan dengan jeda replikasi dan sebagian besar mengungkapkan semua penyebab masalah dalam database MySQL Anda. Cukup jalankan pernyataan SQL ini di node slave Anda yang diduga mengalami lag replikasi.
Bidang awal yang biasa dilacak untuk masalah adalah,
- Slave_IO_State - Ini memberi tahu Anda apa yang sedang dilakukan utas. Bidang ini akan memberi Anda wawasan yang baik jika kesehatan replikasi berjalan normal, menghadapi masalah jaringan seperti menyambung kembali ke master, atau mengambil terlalu banyak waktu untuk melakukan data yang dapat menunjukkan masalah disk saat menyinkronkan data ke disk. Anda juga dapat menentukan nilai status ini saat menjalankan SHOW PROCESSLIST.
- File_Log_Master - Nama file binlog master tempat utas I/O saat ini diambil.
- Baca_Master_Log_Pos - posisi file binlog dari master tempat utas I/O replikasi telah dibaca.
- Relay_Log_File - nama file log relai yang saat ini sedang dijalankan oleh utas SQL
- Relay_Log_Pos - posisi binlog dari file yang ditentukan dalam Relay_Log_File yang telah dieksekusi utas SQL.
- Relay_Master_Log_File - File binlog master yang telah dieksekusi oleh utas SQL dan kongruen dengan nilai Read_Master_Log_Pos.
- Seconds_Behind_Master - kolom ini menunjukkan perkiraan perbedaan antara stempel waktu saat ini pada slave dengan stempel waktu pada master untuk peristiwa yang saat ini sedang diproses pada slave. Namun, bidang ini mungkin tidak dapat memberi tahu Anda kelambatan yang tepat jika jaringan lambat karena perbedaan detik diambil antara utas SQL budak dan utas I/O budak. Jadi mungkin ada kasus yang bisa terjebak dengan utas I/O budak yang membaca lambat, tapi saya menguasainya sudah berbeda.
- Slave_SQL_Running_State - status utas SQL dan nilainya identik dengan nilai status yang ditampilkan di SHOW PROCESSLIST.
- Retrieved_Gtid_Set - Tersedia saat menggunakan replikasi GTID. Ini adalah set GTID yang sesuai dengan semua transaksi yang diterima oleh slave ini.
- Dieksekusi_Gtid_Set - Tersedia saat menggunakan replikasi GTID. Ini adalah kumpulan GTID yang ditulis dalam log biner.
Misalnya, mari kita ambil contoh di bawah ini yang menggunakan replikasi GTID dan mengalami jeda replikasi:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.70
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000038
Read_Master_Log_Pos: 826608419
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 468413927
Relay_Master_Log_File: binlog.000038
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 826608206
Relay_Log_Space: 826607743
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 251
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 45003
Master_UUID: 36272880-a7b0-11e9-9ca6-525400cae48b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: copy to tmp table
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:7631-9192
Executed_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:1-9191,
864dd532-a7af-11e9-85f2-525400cae48b:1-173,
df68c807-a7af-11e9-9b56-525400cae48b:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)Mendiagnosis masalah seperti ini, mysqlbinlog juga dapat menjadi alat Anda untuk mengidentifikasi kueri apa yang telah berjalan pada posisi binlog x &y tertentu. Untuk menentukan ini, mari kita ambil Retrieved_Gtid_Set, Relay_Log_Pos, dan Relay_Log_File. Lihat perintah di bawah ini:
[[email protected] mysql]# mysqlbinlog --base64-output=DECODE-ROWS --include-gtids="36272880-a7b0-11e9-9ca6-525400cae48b:9192" --start-position=468413927 -vvv relay-bin.000004
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 468413927
#200206 4:36:14 server id 45003 end_log_pos 826608271 CRC32 0xc702eb4c GTID last_committed=1562 sequence_number=1563 rbr_only=no
SET @@SESSION.GTID_NEXT= '36272880-a7b0-11e9-9ca6-525400cae48b:9192'/*!*/;
# at 468413992
#200206 4:36:14 server id 45003 end_log_pos 826608419 CRC32 0xe041ec2c Query thread_id=24 exec_time=31 error_code=0
use `jbmrcd_date`/*!*/;
SET TIMESTAMP=1580963774/*!*/;
SET @@session.pseudo_thread_id=24/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
ALTER TABLE NewAddressCode ADD INDEX PostalCode(PostalCode)
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;Ini memberi tahu kita bahwa ia mencoba mereplikasi dan mengeksekusi pernyataan DML yang mencoba menjadi sumber kelambatan. Tabel ini adalah tabel besar yang berisi 13 juta baris.
Centang SHOW PROCESSLIST, SHOW ENGINE INNODB STATUS, dengan kombinasi perintah ps, top, iostat
Dalam beberapa kasus, SHOW SLAVE STATUS tidak cukup untuk memberi tahu kami pelakunya. Ada kemungkinan bahwa pernyataan yang direplikasi dipengaruhi oleh proses internal yang berjalan di budak database MySQL. Menjalankan pernyataan SHOW [FULL] PROCESSLIST dan SHOW ENGINE INNODB STATUS juga menyediakan data informatif yang memberi Anda wawasan tentang sumber masalah.
Misalnya, katakanlah alat pembandingan sedang berjalan yang menyebabkan IO dan CPU disk jenuh. Anda dapat memeriksa dengan menjalankan kedua pernyataan SQL. Gabungkan dengan ps dan perintah teratas.
Anda juga dapat menentukan kemacetan dengan penyimpanan disk Anda dengan menjalankan iostat yang menyediakan statistik volume saat ini yang Anda coba diagnosa. Menjalankan iostat dapat menunjukkan seberapa sibuk atau dimuat server Anda. Misalnya, diambil oleh seorang budak yang lagging tetapi juga mengalami pemanfaatan IO tinggi pada saat yang sama,
[[email protected] ~]# iostat -d -x 10 10
Linux 3.10.0-693.5.2.el7.x86_64 (testnode5) 02/06/2020 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.42 3.71 60.65 218.92 568.39 24.47 0.15 2.31 13.79 1.61 0.12 0.76
dm-0 0.00 0.00 3.70 60.48 218.73 568.33 24.53 0.15 2.36 13.85 1.66 0.12 0.76
dm-1 0.00 0.00 0.00 0.00 0.04 0.01 21.92 0.00 63.29 2.37 96.59 22.64 0.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.20 392.30 7983.60 2135.60 49801.55 12.40 36.70 3.84 13.01 3.39 0.08 69.02
dm-0 0.00 0.00 392.30 7950.20 2135.60 50655.15 12.66 36.93 3.87 13.05 3.42 0.08 69.34
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.06 183.67 0.00 183.67 61.67 1.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.40 370.93 6775.42 2557.04 46184.22 13.64 43.43 6.12 11.60 5.82 0.10 73.25
dm-0 0.00 0.00 370.93 6738.76 2557.04 47029.62 13.95 43.77 6.20 11.64 5.90 0.10 73.41
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.03 107.00 0.00 107.00 35.67 1.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 299.80 7253.35 1916.88 52766.38 14.48 30.44 4.59 15.62 4.14 0.10 72.09
dm-0 0.00 0.00 299.80 7198.60 1916.88 51064.24 14.13 30.68 4.66 15.70 4.20 0.10 72.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.10 215.50 8939.60 1027.60 67497.10 14.97 59.65 6.52 27.98 6.00 0.08 72.50
dm-0 0.00 0.00 215.50 8889.20 1027.60 67495.90 15.05 60.07 6.60 28.09 6.08 0.08 72.75
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 32.33 0.00 32.33 30.33 0.91
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.90 140.40 8922.10 625.20 54709.80 12.21 11.29 1.25 9.88 1.11 0.08 68.60
dm-0 0.00 0.00 140.40 8871.50 625.20 54708.60 12.28 11.39 1.26 9.92 1.13 0.08 68.83
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 27.33 0.00 27.33 9.33 0.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.70 284.50 8621.30 24228.40 51535.75 17.01 34.14 3.27 8.19 3.11 0.08 72.78
dm-0 0.00 0.00 290.90 8587.10 25047.60 53434.95 17.68 34.28 3.29 8.02 3.13 0.08 73.47
dm-1 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.83 416.45 0.00 416.45 63.60 12.72
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.30 851.60 11018.80 17723.60 85165.90 17.34 142.59 12.44 7.61 12.81 0.08 99.75
dm-0 0.00 0.00 845.20 10938.90 16904.40 83258.70 17.00 143.44 12.61 7.67 12.99 0.08 99.75
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.10 24.60 12965.40 420.80 51114.45 7.93 39.44 3.04 0.33 3.04 0.07 93.39
dm-0 0.00 0.00 24.60 12890.20 420.80 51114.45 7.98 40.23 3.12 0.33 3.12 0.07 93.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.60 13420.70 57.60 51942.00 7.75 0.95 0.07 0.33 0.07 0.07 92.11
dm-0 0.00 0.00 3.60 13341.10 57.60 51942.00 7.79 0.95 0.07 0.33 0.07 0.07 92.08
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Hasil di atas menampilkan penggunaan IO yang tinggi dan penulisan yang tinggi. Ini juga mengungkapkan bahwa ukuran antrian rata-rata dan ukuran permintaan rata-rata bergerak yang berarti ini merupakan indikasi beban kerja yang tinggi. Dalam kasus ini, Anda perlu menentukan apakah ada proses eksternal yang menyebabkan MySQL mencekik utas replikasi.
Bagaimana ClusterControl Dapat Membantu?
Dengan ClusterControl, menangani lag slave dan menentukan penyebabnya sangat mudah dan efisien. Ini langsung memberi tahu Anda di UI web, lihat di bawah:
Ini mengungkapkan kepada Anda kelambatan budak saat ini yang dialami node budak Anda. Tidak hanya itu, dengan dasbor SCUMM, jika diaktifkan, memberi Anda lebih banyak wawasan tentang apa yang dilakukan oleh health node slave Anda atau bahkan seluruh cluster:
Tidak hanya hal-hal ini tersedia di ClusterControl, ini juga memberi Anda kemampuan untuk menghindari terjadinya kueri buruk dengan fitur-fitur ini seperti yang terlihat di bawah,
Indeks yang berlebihan memungkinkan Anda menentukan bahwa indeks ini dapat menyebabkan masalah kinerja untuk kueri masuk yang mereferensikan indeks duplikat. Ini juga memberi tahu Anda tabel yang tidak memiliki Kunci Utama yang biasanya merupakan masalah umum slave lag saat kueri SQL tertentu atau transaksi yang mereferensikan tabel besar tanpa kunci utama atau unik saat direplikasi ke slave.
Kesimpulan
Mengatasi keterlambatan Replikasi MySQL adalah masalah yang sering terjadi dalam pengaturan replikasi master-slave. Ini bisa mudah didiagnosis, tetapi sulit dipecahkan. Pastikan Anda memiliki tabel dengan kunci utama atau kunci unik yang ada, dan tentukan langkah-langkah dan alat tentang cara memecahkan masalah dan mendiagnosis penyebab lag budak. Efisiensi selalu menjadi kunci saat memecahkan masalah.
