View a markdown version of this page

レコードの欠落によるレプリケーション障害のトラブルシューティング - Amazon Relational Database Service
一般的な原因問題の特定問題の診断バイナリログの分析レプリケーションの失敗を回避する

レコードの欠落によるレプリケーション障害のトラブルシューティング

バイナリログレプリケーションで 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 エンジンで異なります。ログを取得する方法については、「データベースログファイルの表示とリスト化」を参照してください。

問題の診断

レプリケーションの失敗を診断するには、次の手順を実行します。

  • レプリカのエラーログを確認して、レプリケーションが停止した場所を特定します。検索キーワードとして 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 ユーティリティを使用してバイナリログファイルを調べることができます。例えば、バイナリログファイル mysql-bin-changelog.031523 の end_log_pos 位置 899 でレプリケーションが失敗した場合、この特定の場所を分析して失敗の原因を特定できます。

注記

end_log_pos 値は、失敗したイベントの終了位置を示します。デコードされたバイナリログ出力で、end_log_pos がこの値と一致するイベントを探します。

mysqlbinlog ユーティリティを使用して、関連するバイナリログをダウンロードして調べます。プライマリインスタンスのエンドポイントを使用します。

$ 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
注記

mysqlbinlog ユーティリティは、バイナリログの内容の読み取りと解釈に役立つネイティブ MySQL ツールです。Amazon RDS のバイナリログへのアクセス方法の詳細については、「MySQL バイナリログにアクセスする」を参照してください。

ライターインスタンスのバイナリログには、ライターインスタンスが 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 ベースレプリケーションを使用する」を参照してください。

  • プライマリインスタンスでは、binlog_format に ROW を使用します。binlog_format を MIXED にすると、レプリケーションの不整合が検出されないまま見過ごされる可能性があります。

  • 意図しない行の変更を防ぐために、レプリカインスタンスで read_only を 1 に設定します。

  • レプリカインスタンスで innodb_flush_log_at_trx_commit を 1 に設定します。

  • プライマリインスタンスで sync_binlog を 1 に設定します。

  • プライマリとレプリカ間のテーブルスキーマの同等性を確認します。

  • レプリケートされたテーブルにプライマリキーがあることを確認します。