指示に従ってもレプリケーションセットアップが機能しない場合、最初に行うことはエラーログでメッセージを確認することです。 多くのユーザーは、問題が発生したあとにこれを十分に実行せずに、時間を失います。
エラーログから何が問題だったのかがわからない場合は、次の手法を試してください。
SHOW MASTER STATUSステートメントを発行して、ソースのバイナリロギングが有効になっていることを確認します。 バイナリロギングはデフォルトで有効になっています。 バイナリロギングが有効になっている場合、Positionはゼロ以外です。 バイナリロギングが有効になっていない場合は、バイナリロギングを無効にする設定 (--skip-log-binオプションなど) でソースを実行していないことを確認します。ソースとレプリカの両方で起動時に
server_idシステム変数が設定され、ID 値が各サーバーで一意であることを確認します。レプリカが実行されていることを確認します。
SHOW REPLICA | SLAVE STATUSを使用して、Replica_IO_RunningとReplica_SQL_Runningの両方の値がYesであるかどうかを確認します。 そうでない場合は、レプリカサーバーの起動時に使用されたオプションを確認します。 たとえば、--skip-slave-startでは、START REPLICA | SLAVEステートメントを発行するまでレプリケーションスレッドが起動しません。-
レプリカが実行中の場合は、ソースへの接続が確立されているかどうかを確認します。
SHOW PROCESSLISTを使用して I/O スレッドと SQL スレッドを見つけ、それらのStateカラムをチェックしてそれらに何が表示されているかを確認してください。 セクション17.2.3「レプリケーションスレッド」を参照してください。 I/O スレッド状態がConnecting to masterである場合、次のことを確認してください。ソースのレプリケーションユーザーの権限を確認します。
ソースのホスト名が正しいこと、およびソースへの接続に正しいポートを使用していることを確認してください。 レプリケーションに使用されるポートは、クライアントネットワーク通信に使用されるポートと同じです (デフォルトは
3306です)。 ホスト名の場合、その名前が正しい IP アドレスに解決されることを確認してください。構成ファイルをチェックして、ネットワークを無効にするためにソースまたはレプリカで
skip_networkingシステム変数が有効になっているかどうかを確認します。 その場合は、設定をコメント化するか、削除します。ソースにファイアウォールまたは IP フィルタリング構成がある場合は、MySQL に使用されているネットワークポートがフィルタ処理されていないことを確認します。
pingまたはtraceroute/tracertを使用してホストにアクセスし、ソースに到達できることを確認します。
レプリカが以前に実行されていたが停止している場合は、通常、ソースで成功した一部のステートメントがレプリカで失敗したためです。 これは、ソースの適切なスナップショットを取得し、レプリケーションスレッド外のレプリカのデータを変更していない場合には発生しません。 レプリカが予期せず停止した場合は、バグであるか、セクション17.5.1「レプリケーションの機能と問題」 で説明されている既知のレプリケーション制限のいずれかが発生しています。 バグの場合は、報告方法の説明をセクション17.5.5「レプリケーションバグまたは問題を報告する方法」で参照してください。
-
ソースで成功したステートメントがレプリカでの実行を拒否した場合、レプリカデータベースを削除してソースから新しいスナップショットをコピーすることで、完全なデータベース再同期を実行できない場合は、次の手順を実行します:
レプリカ上の影響を受けるテーブルがソーステーブルと異なるかどうかを確認します。 これがどのように発生したかを理解しようとしてください。 次に、レプリカテーブルをソースと同一にして、
START REPLICA | SLAVEを実行します。前述のステップが機能しないか適用されない場合は、手動で更新を安全に行うかどうか (必要な場合) を理解してから、ソースの次のステートメントを無視してください。
-
レプリカがソースから次のステートメントをスキップできると判断した場合は、次のステートメントを発行します:
mysql> SET GLOBAL sql_slave_skip_counter = N; mysql> START SLAVE; Or from MySQL 8.0.22: mysql> START REPLICA;ソースの次のステートメントで
AUTO_INCREMENTまたはLAST_INSERT_ID()を使用しない場合、Nの値は 1 にする必要があります。 そうでない場合は、値は 2 であるべきです。AUTO_INCREMENTまたはLAST_INSERT_ID()を使用するステートメントに値 2 を使用する理由は、ソースのバイナリログで 2 つのイベントを取得するためです。 レプリカがソースと完全に同期化を開始し、レプリケーションスレッドの外部に関係するテーブルを誰も更新していないことが確実な場合は、バグの結果として相違が発生している可能性があります。 最新バージョンの MySQL を実行している場合は、この問題を報告してください。 古いバージョンを実行している場合は、最新の本番環境リリースにアップグレードして問題が持続するかどうかを判断してみてください。