関係するユーザーエラーはないと判断したけれども、依然としてレプリケーションがまったく機能しないか安定しない場合は、バグレポートを送る時期です。 バグを突き止めるため、できるだけ多くの情報をユーザーから入手する必要があります。 優れたバグレポートを準備するために、ある程度の時間と労力を費やしてくださるようにお願いします。
そのバグをはっきりと示す再現可能なテストケースがある場合は、セクション1.6「質問またはバグをレポートする方法」で示す手順を使用してオラクルのバグデータベースに入力してくださるようにお願いします。 「幽霊のような」問題 (意のままに再現できないもの) の場合は、次の手順を使用してください。
ユーザーエラーが関係していないことを確認します。 たとえば、レプリケーションスレッド外でレプリカを更新すると、データが同期しなくなり、更新時に一意キー違反が発生する可能性があります。 この場合、レプリケーションスレッドは停止し、テーブルを手動でクリーンアップして同期化するまで待機します。 これは、レプリケーションの問題ではありません。 外部干渉の問題でレプリケーションが失敗しています。
バイナリロギングを有効にして (
log_binシステム変数)、--log-slave-updatesオプションを有効にしてレプリカが実行されていることを確認します。これにより、ソースから受信した更新がレプリカによって独自のバイナリログに記録されます。 これらの設定はデフォルトです。-
レプリケーション状態をリセットする前のすべての証拠を保存します。 情報がなかったり、不完全な情報しかなかったりすると、オラクルでは問題を突き止めることが困難または不可能になります。 収集すべき証拠:
ソースのすべてのバイナリログファイル
レプリカからのすべてのバイナリログファイル
問題を検出した時点でのソースからの
SHOW MASTER STATUSの出力問題を検出した時点でのレプリカからの
SHOW REPLICA | SLAVE STATUSの出力ソースおよびレプリカからのエラーログ
-
mysqlbinlog を使用してバイナリログを調べます。 問題の説明ステートメントを見つけるには、次のことが役立ちます。
log_fileおよびlog_posは、SHOW REPLICA | SLAVE STATUSのMaster_Log_FileおよびRead_Master_Log_Posの値です。shell> mysqlbinlog --start-position=log_pos log_file | head
問題の証拠を収集したあとは、まずそれらを個別のテストケースとして切り分けてみてください。 そのうえで、セクション1.6「質問またはバグをレポートする方法」での指示を使用して問題およびできるだけ多くの情報をオラクルのバグデータベースに入力してください。