Memecahkan masalah kegagalan replikasi karena catatan yang hilang

Saat menggunakan Amazon RDS for MySQL atau MariaDB dengan replikasi log biner, Anda mungkin mengalami kegagalan replikasi di mana proses berhenti karena catatan yang hilang pada replika baca. Bagian ini menjelaskan cara mendiagnosis dan menyelesaikan masalah ini.

Penyebab umum

Inkonsistensi data antara sumber dan replika dapat disebabkan oleh salah satu skenario berikut:

• Modifikasi data manual pada replika

• Transaksi dilewati menggunakan sql_replica_skip_counter (sql_slave_skip_countersebelum MySQL 8.0.26)

• Baris yang hilang pada replika selama sinkronisasi data awal menggunakan alat migrasi

Mengidentifikasi masalah

Indikator umum dari masalah ini adalah Error 1032 dengan pesanCan't find record. Pesan kesalahan berikut muncul di log kesalahan replika:

2025-11-04T21:24:11.038899Z 566 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': 
Worker 1 failed executing transaction 'ANONYMOUS' at source log 
mysql-bin-changelog.031523, end_log_pos 899; Could not execute Update_rows event on 
table test_replication.users; Can't find record in 'users', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's source log mysql-bin-changelog.031523, 
end_log_pos 899, Error_code: MY-001032

catatan

Format log kesalahan bervariasi antara mesin MySQL dan MariaDB. Untuk informasi tentang cara mengambil log, lihatMelihat dan mencantumkan file log basis data.

Mendiagnosis masalah

Untuk mendiagnosis kegagalan replikasi:

• Tinjau log kesalahan replika untuk mengidentifikasi di mana replikasi berhenti. Anda dapat menggunakan MY-010584 sebagai kata kunci pencarian.

• Jalankan SHOW REPLICA STATUS\G (SHOW SLAVE STATUS\Gsebelum MySQL 8.0.22) pada replika dan tinjau kolom: Last_Error

  Last_Error: Coordinator stopped because there were error(s) in the worker(s). 
  The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' 
  at source log mysql-bin-changelog.031523, end_log_pos 899. See error log and/or 
  performance_schema.replication_applier_status_by_worker table for more details 
  about this failure or others, if any.

• Periksa nama file log biner dan posisi di mana proses replikasi berhenti pada instance replika. Anda dapat menemukan informasi ini di log kesalahan instance replika.

Menganalisis log biner

Untuk menyelidiki kegagalan replikasi pada transaksi tertentu, Anda dapat menggunakan mysqlbinlogutilitas untuk memeriksa file log biner. Misalnya, jika replikasi gagal pada end_log_pos posisi 899 dalam file log binermysql-bin-changelog.031523, Anda dapat menganalisis lokasi spesifik ini untuk mengidentifikasi penyebab kegagalan.

catatan

end_log_posNilai menunjukkan posisi akhir dari peristiwa yang gagal. Dalam output log biner yang diterjemahkan, cari acara yang end_log_pos cocok dengan nilai ini.

Gunakan mysqlbinlog utilitas untuk mengunduh dan memeriksa log biner yang relevan. Gunakan endpoint untuk instance utama.

$ mysqlbinlog --read-from-remote-server \
--host=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<password> \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name

catatan

mysqlbinlogUtilitas adalah alat MySQL asli yang membantu Anda membaca dan menafsirkan konten log biner. Untuk informasi selengkapnya tentang mengakses log biner di Amazon RDS, lihat. Mengakses log biner MySQL

Log biner dari instance penulis menunjukkan bahwa instance penulis mencoba memperbarui catatan dengan id=1 dalam test_replication.users tabel:

#251104 21:13:13 server id 680788197  end_log_pos 899 CRC32 0x89b1e255     Update_rows: table id 101 flags: STMT_END_F
### UPDATE `test_replication`.`users`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
# at 899

Log kesalahan replika menunjukkan bahwa replika tidak dapat mengeksekusi UPDATE pernyataan karena catatan target tidak ada:

Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND

Untuk memverifikasi bahwa baris tidak ada, periksa apakah baris tertentu ada pada replika:

SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)

Output ini mengonfirmasi bahwa UPDATE operasi dari instans DB sumber gagal direplikasi karena baris target tidak ada pada replika.

Menghindari kegagalan replikasi

Kami merekomendasikan praktik terbaik berikut untuk menghindari inkonsistensi replikasi:

• Gunakan GTID-based replikasi. Untuk informasi selengkapnya, lihat Menggunakan GTID-based replikasi.

• Gunakan binlog_format seperti ROW pada contoh utama. Dengan binlog_format asMIXED, ada peluang replikasi untuk menyembunyikan inkonsistensi secara diam-diam.

• Konfigurasikan read_only ke 1 pada instance replika untuk mencegah modifikasi baris yang tidak diinginkan.

• Setel innodb_flush_log_at_trx_commit ke 1 pada contoh replika.

• Setel sync_binlog ke 1 pada contoh utama.

• Verifikasi paritas skema tabel antara primer dan replika.

• Pastikan tabel yang direplikasi memiliki kunci utama.