# レコードの欠落によるレプリケーション障害のトラブルシューティング
バイナリログレプリケーションで Amazon RDS for MySQL または MariaDB を使用する場合、リードレプリカのレコードがないためにプロセスが停止するレプリケーションエラーが発生する可能性があります。このセクションでは、これらの問題を診断して解決する方法について説明します。
## 一般的な原因
ソースとレプリカ間のデータの不整合は、次のいずれかのシナリオが原因で発生する可能性があります。
+ レプリカでの手動データ変更
+ `sql_replica_skip_counter` (MySQL 8.0.26 より前では `sql_slave_skip_counter`) を使用してスキップされたトランザクション
+ 移行ツールを使用した初期データ同期中にレプリカで行が欠落
## 問題の特定
この問題の一般的な指標は、`Can't find record` メッセージを伴う `Error 1032` です。次のエラーメッセージがレプリカのエラーログに表示されます。
```
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
```
**注記**
エラーログの形式は、MySQL エンジンと MariaDB エンジンで異なります。ログを取得する方法については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」を参照してください。
## 問題の診断
レプリケーションの失敗を診断するには、次の手順を実行します。
+ レプリカのエラーログを確認して、レプリケーションが停止した場所を特定します。検索キーワードとして `MY-010584` を使用できます。
+ レプリカで `SHOW REPLICA STATUS\G` (MySQL 8.0.22 より前では `SHOW SLAVE STATUS\G`) を実行し、`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.
```
+ バイナリログファイルの名前と、レプリカインスタンスでレプリケーションプロセスが停止した場所を確認します。この情報は、レプリカインスタンスのエラーログにあります。
## バイナリログの分析
特定のトランザクションでのレプリケーションの失敗を調査するには、[`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html) ユーティリティを使用してバイナリログファイルを調べることができます。例えば、バイナリログファイル `mysql-bin-changelog.031523` の `end_log_pos` 位置 `899` でレプリケーションが失敗した場合、この特定の場所を分析して失敗の原因を特定できます。
**注記**
`end_log_pos` 値は、失敗したイベントの終了位置を示します。デコードされたバイナリログ出力で、`end_log_pos` がこの値と一致するイベントを探します。
`mysqlbinlog` ユーティリティを使用して、関連するバイナリログをダウンロードして調べます。プライマリインスタンスのエンドポイントを使用します。
```
$ mysqlbinlog --read-from-remote-server \
--host= \
--port=3306 \
--user= \
--password= \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```
**注記**
`mysqlbinlog` ユーティリティは、バイナリログの内容の読み取りと解釈に役立つネイティブ MySQL ツールです。Amazon RDS のバイナリログへのアクセス方法の詳細については、「[MySQL バイナリログにアクセスする](USER_LogAccess.MySQL.Binarylog.md)」を参照してください。
ライターインスタンスのバイナリログには、ライターインスタンスが `test_replication.users` テーブル内の `id=1` のレコードを更新しようとしたことが示されています。
```
#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
```
レプリカのエラーログには、ターゲットレコードが存在しないため、レプリカが `UPDATE` ステートメントを実行できなかったことが示されています。
```
Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND
```
行が欠落していることを確認するには、レプリカに特定の行が存在するかどうかを確認します。
```
SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)
```
この出力は、ターゲット行がレプリカに存在しないため、ソース DB インスタンスからの `UPDATE` オペレーションがレプリケートに失敗したことを確認します。
## レプリケーションの失敗を回避する
レプリケーションの不整合を避けるため、次のベストプラクティスをお勧めします。
+ GTID ベースのレプリケーションを使用します。詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
+ プライマリインスタンスでは、`binlog_format` に `ROW` を使用します。`binlog_format` を `MIXED` にすると、レプリケーションの不整合が検出されないまま見過ごされる可能性があります。
+ 意図しない行の変更を防ぐために、レプリカインスタンスで `read_only` を `1` に設定します。
+ レプリカインスタンスで `innodb_flush_log_at_trx_commit` を `1` に設定します。
+ プライマリインスタンスで `sync_binlog` を `1` に設定します。
+ プライマリとレプリカ間のテーブルスキーマの同等性を確認します。
+ レプリケートされたテーブルにプライマリキーがあることを確認します。