Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# 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_counter`sebelum 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 pesan`Can'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, lihat[Melihat dan mencantumkan file log basis data](USER_LogAccess.Procedural.Viewing.md).
## 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\G`sebelum 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 [`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html)utilitas untuk memeriksa file log biner. Misalnya, jika replikasi gagal pada `end_log_pos` posisi `899` dalam file log biner`mysql-bin-changelog.031523`, Anda dapat menganalisis lokasi spesifik ini untuk mengidentifikasi penyebab kegagalan.
**catatan**
`end_log_pos`Nilai 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= \
--port=3306 \
--user= \
--password= \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```
**catatan**
`mysqlbinlog`Utilitas 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](USER_LogAccess.MySQL.Binarylog.md)
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='updated4@example.com' /* 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='updated5@example.com' /* 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](mysql-replication-gtid.md).
+ Gunakan `binlog_format` seperti `ROW` pada contoh utama. Dengan `binlog_format` as`MIXED`, 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.