DevOpsナレッジハブ
DevOpsナレッジハブ

MySQLレプリケーションの一般的な障害を迅速にトラブルシューティングする

この実践的なガイドで、一般的なMySQLレプリケーションの障害を迅速に解決しましょう。`SHOW REPLICA STATUS`からのエラーコードの解釈、MySQLエラーログの検査、バイナリログの目的の理解を学びます。この記事では、重複エントリ、欠落したバイナリログファイル、データ分岐などの問題の診断に役立つ実行可能なステップとベストプラクティスを提供し、健全なレプリケーションセットアップの維持を支援します。

39 ビュー

MySQLレプリケーションの一般的な障害を迅速にトラブルシューティングする

MySQLレプリケーションは、高可用性、リードスケーリング、ディザスタリカバリに不可欠な、データベースの複数のコピーを維持できる強力な機能です。しかし、レプリケーションの設定と維持の過程で、予期せぬ障害が発生することがあります。本ガイドでは、エラーコードの理解と関連ログの確認に焦点を当て、一般的なMySQLレプリケーションの問題を迅速に診断し解決するための実践的なアプローチを提供します。

レプリケーションが停止すると、重要な操作が halt される可能性があるため、体系的なトラブルシューティングプロセスを持つことが不可欠です。最も頻繁に発生する問題を取り上げ、根本原因を特定し、効率的に解決策を実装するための知識を提供します。症状を理解し、どこに手がかりを探すべきかを知ることで、ダウンタイムを最小限に抑え、レプリケーション設定が健全に維持されることを保証できます。

MySQLレプリケーションの基本の理解

トラブルシューティングに入る前に、MySQLレプリケーションがどのように機能するかを簡単に復習しておくと有益です。一般的なマスター・スレーブ（またはプライマリ・レプリカ）構成では、次のようになります。

  • プライマリのバイナリログ（Binlog）： プライマリサーバーは、すべてのデータ変更イベントをバイナリログファイルに記録します。
  • レプリカのレプリケーションスレッド： レプリカサーバーには2つのスレッドがあります。
    • I/Oスレッド： プライマリに接続し、プライマリのバイナリログからイベントを読み取り、自身のレプリケーションログ（リレーログ）に書き込みます。
    • SQLスレッド： リレーログからイベントを読み取り、レプリカのデータベース上で実行します。

レプリケーションの障害は通常、I/Oスレッドがイベントを取得できないか、SQLスレッドがそれらを適用できない場合に発生します。

一般的なレプリケーションエラーコードとその意味

MySQLは、レプリケーションの問題について貴重な洞察を提供するエラーコードを提供します。SHOW REPLICA STATUS（古いバージョンではSHOW SLAVE STATUS）コマンドは、レプリケーションの状態を確認するための主要なツールです。

SHOW REPLICA STATUS\G

以下の主要なフィールドを確認してください。

  • Replica_IO_Running: Yesであるべきです。
  • Replica_SQL_Running: Yesであるべきです。
  • Last_IO_Errno および Last_IO_Error: I/Oスレッドに関連するエラー。
  • Last_SQL_Errno および Last_SQL_Error: SQLスレッドに関連するエラー。
  • Seconds_Behind_Source: プライマリに対するレプリカの遅延時間を示します。

以下に、一般的なエラー番号とその典型的な原因をいくつか示します。

エラー 1062: 重複エントリ (Duplicate Entry)

  • Last_SQL_Errno: 1062
  • Last_SQL_Error: Error 'Duplicate entry '...' for key '...' on query. Default database: '...'.

原因： SQLスレッドが、レプリカ上で重複キー違反を引き起こすプライマリからのイベントを適用しようとしています。これは、レプリカが遅延し、同じデータを作成する可能性のある他の書き込みを既に処理していた場合、またはレプリカ上で手動で不整合が導入された場合に頻繁に発生します。

解決策：
1. 問題のクエリを特定する： エラーメッセージには通常、失敗したクエリが含まれています。
2. トランザクションをスキップする（注意が必要）： スキップしても安全であると確信できる場合は、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; の後に START SLAVE SQL_THREAD;（または START REPLICA SQL_THREAD;）を使用できます。警告： トランザクションをスキップするとデータが分岐する可能性があります。続行する前にその影響を理解してください。
3. データ不整合の調査： スキップがオプションでない場合、データを手動で調整するか、重複が発生した理由を調査する必要があります。レプリカが大幅に同期から外れている場合は、特定の時点からレプリケーションをリセットする必要があるかもしれません。

エラー 1236: バイナリログインデックスで最初のログファイル名が見つかりません

  • Last_IO_Errno: 1236
  • Last_IO_Error: Error 'Could not find first log file name in binary log index' when trying to read event from the http client side...

原因： I/Oスレッドが、プライマリによって指定されたバイナリログファイルを見つけることができません。これは通常、レプリカが読み取る前にプライマリからバイナリログファイルがパージされたこと、またはレプリカが既に存在しないbinlogファイルを指定して接続しようとしていることを意味します。

解決策：
1. プライマリのbinlog保持期間を確認する： プライマリの expire_logs_days（または binlog_expire_logs_seconds）が、レプリカが追いつくのに十分な期間ログを保持するように設定されていることを確認します。
2. レプリカの再初期化： 最も一般的な解決策は、レプリケーションを停止し、レプリカのマスタ情報（master data）をリセットし、プライマリの新しいログファイルと位置が正しく設定されていることを確認した上で、クリーンなバックアップまたはスナップショットから再初期化することです。

エラー 1577: プライマリのバイナリログ位置が必要です

  • Last_IO_Errno: 1577
  • Last_IO_Error: Error: The primary's binary log position is required for this operation.

原因： このエラーは通常、レプリカで正しいバイナリログファイル名と位置を指定せずにレプリケーションを開始しようとした場合に発生します。これは、特定の設定変更や手動操作の後に発生することがあります。

解決策：
1. CHANGE MASTER TO（または CHANGE REPLICATION SOURCE TO）コマンドの確認： レプリケーションを設定する際に、MASTER_LOG_FILE と MASTER_LOG_POS（または SOURCE_LOG_FILE と SOURCE_LOG_POS）を正しく指定したことを確認します。
2. リセットと再構成： レプリケーションを停止し、レプリカの状態をリセットし、プライマリから取得した正しいパラメータを使用して CHANGE MASTER TO コマンドを再適用します。

エラー 1032: '...' テーブルのレコードが見つかりません

  • Last_SQL_Errno: 1032
  • Last_SQL_Error: Error 'Can't find record in '...' table' on query. Default database: '...'.

原因： エラー 1062 と同様に、SQLスレッドがレプリカ上に存在しないレコードに対して UPDATE または DELETE 操作を実行しようとしていることを示します。これはデータ分岐を示唆しており、以前にスキップされたトランザクションや手動変更が原因であることが多いです。

解決策：
1. クエリとテーブルの特定： エラーメッセージが詳細を提供します。
2. データドリフトの調査： プライマリとレプリカで影響を受けるテーブルの状態を比較します。
3. スキップ（細心の注意を払って）： 失われたレコードが重要でない場合、または他の手段で処理されている場合は、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; と START REPLICA SQL_THREAD; を使用してトランザクションをスキップできる可能性があります。
4. 手動データ修正： 重要なケースでは、不足しているレコードを手動で挿入するか、テーブル/データベースを再同期する必要があるかもしれません。

レプリケーションログの検査

SHOW REPLICA STATUS 以外にも、MySQLのエラーログとバイナリログ自体は非常に貴重なリソースです。

MySQLエラーログ

通常、/var/log/mysql/error.log（OSや構成によって異なる場合があります）に格納されており、このログには、レプリケーションスレッドに関連するものを含む、MySQLサーバーが遭遇したエラーに関する詳細情報が含まれています。

確認すべき点：
* エラーの詳細なスタックトレース。
* プライマリとレプリカ間の接続問題。
* タイムアウトやネットワーク関連の問題。

プライマリのバイナリログ

レプリカのリレーログはSQLスレッドにとって重要ですが、プライマリのバイナリログを調べることで、障害につながったイベントのシーケンスを理解できる場合があります。この目的には mysqlbinlog ユーティリティを使用できます。

例：特定のバイナリログファイルからイベントを表示するには：

mysqlbinlog /path/to/mysql-bin.000001

例：特定の時刻または位置周辺のイベントを表示するには：

mysqlbinlog --start-datetime="2023-10-27 10:00:00" --stop-datetime="2023-10-27 11:00:00" /path/to/mysql-bin.000001

使用例：
* レプリカのSQLエラーを引き起こした正確なトランザクションを理解する。
* 書き込まれているイベントの一貫性を検証する。

一般的なトラブルシューティング手順

レプリケーションが停止した場合、次の手順に従ってください。

  1. SHOW REPLICA STATUS の確認： 常にここから開始します。問題の概要を把握する最も速い方法です。
  2. Last_IO_Error および Last_SQL_Error の調査： 特定のエラーコードとメッセージを理解します。
  3. MySQLエラーログの参照： サーバー側でより詳細なコンテキストを探します。
  4. ネットワーク接続の検証： レプリカがプライマリに到達できることを確認します（ファイアウォール、DNS）。
  5. ユーザー権限の確認： プライマリ上のレプリケーションユーザーが必要な権限（REPLICATION SLAVE）を持っている必要があります。
  6. プライマリがレプリケーション用に構成されていることの確認： log_bin が有効になっており、server_id が一意であることを検証します。
  7. レプリカの read_only 設定の確認： レプリカで read_only が有効になっている場合、特定の条件が満たされない限り、または一時的に無効にされない限り、プライマリからの書き込みは適用されません。

障害を防ぐためのベストプラクティス

  • レプリケーション遅延の監視： Seconds_Behind_Source が過度に増加した場合にアラートを出すように、監視ツールを使用します。
  • 定期的なバックアップ： レプリカを迅速に再初期化できるように、プライマリの一貫したバックアップを維持します。
  • 十分なBinlog保持期間： プライマリで expire_logs_days を適切に構成します。
  • 一意の server_id： レプリケーショントポロジ内のすべてのサーバーが一意の server_id を持っていることを確認します。
  • フェイルオーバ手順のテスト： レプリケーション設定が堅牢であることを確認するために、役割の切り替えを定期的に練習します。

結論

MySQLレプリケーションの障害のトラブルシューティングには、体系的なアプローチが必要です。一般的なエラーコードの理解、SHOW REPLICA STATUS 出力の解釈方法の習得、MySQLのエラーログおよび mysqlbinlog ユーティリティの活用により、ほとんどのレプリケーション問題を効率的に診断し解決できます。積極的な監視とベストプラクティスの順守は、これらの問題の発生をさらに最小限に抑え、データベース環境の安定性と可用性を保証します。