このページは機械翻訳したものです。

17.5.5 レプリケーションバグまたは問題を報告する方法

関係するユーザーエラーはないと判断したけれども、依然としてレプリケーションがまったく機能しないか安定しない場合は、バグレポートを送る時期です。 バグを突き止めるため、できるだけ多くの情報をユーザーから入手する必要があります。 優れたバグレポートを準備するために、ある程度の時間と労力を費やしてくださるようにお願いします。

そのバグをはっきりと示す再現可能なテストケースがある場合は、セクション1.6「質問またはバグをレポートする方法」で示す手順を使用してオラクルのバグデータベースに入力してくださるようにお願いします。 「幽霊のような」問題 (意のままに再現できないもの) の場合は、次の手順を使用してください。

1. ユーザーエラーが関係していないことを確認します。 たとえば、レプリケーションスレッド外でレプリカを更新すると、データが同期しなくなり、更新時に一意キー違反が発生する可能性があります。 この場合、レプリケーションスレッドは停止し、テーブルを手動でクリーンアップして同期化するまで待機します。 これは、レプリケーションの問題ではありません。 外部干渉の問題でレプリケーションが失敗しています。

2. バイナリロギングを有効にして (log_bin システム変数)、--log-slave-updates オプションを有効にしてレプリカが実行されていることを確認します。これにより、ソースから受信した更新がレプリカによって独自のバイナリログに記録されます。 これらの設定はデフォルトです。

3. レプリケーション状態をリセットする前のすべての証拠を保存します。 情報がなかったり、不完全な情報しかなかったりすると、オラクルでは問題を突き止めることが困難または不可能になります。 収集すべき証拠:

   • ソースのすべてのバイナリログファイル

   • レプリカからのすべてのバイナリログファイル

   • 問題を検出した時点でのソースからの SHOW MASTER STATUS の出力

   • 問題を検出した時点でのレプリカからの SHOW REPLICA | SLAVE STATUS の出力

   • ソースおよびレプリカからのエラーログ

4. 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「質問またはバグをレポートする方法」での指示を使用して問題およびできるだけ多くの情報をオラクルのバグデータベースに入力してください。