Skip navigation links
MySQL 5.1 リファレンスマニュアル :: 5 レプリケーション :: 5.4 レプリケーション ノートとヒント :: 5.4.6 レプリケーション バグまたは問題を報告する方法
5.5 レプリケーションの実装 »
Section Navigation      [Toggle]

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

ユーザによるエラーではないことが確認でき、レプリケーションが全く機能しないまたは不安定である場合は、バグとして報告してください。バグ問題を解決するには、より多くの情報を必要とします。そのため、バグ報告を行う際には、時間をかけて、できるだけ詳細な情報を送信してください。

そのバグを実証する再現可能なテスト ケースがある場合には、項1.7. 「質問またはバグの報告」 を参照して、それをバグ用のデータベースに入れてください。「phantom」 問題 (説明できない問題など) の場合は、次の手順に従ってください。

  1. ユーザによるエラーではないことを確認します。例：スレーブ スレッド外側のスレーブを更新する場合は、非同期のデータになり、更新時にユニーク キー制約である可能性があります。この場合、スレーブ スレッドは停止している状態で、それらを同期で持ち込むために、手動によるテーブルのクリーン アップを待機しています。これは、レプリケーションに関する問題ではありません。これは外部からの障害がレプリケーションの失敗に起因しているということです。

  2. --log-slave-updates および --log-bin オプションでスレーブを実行します。これらのオプションでスレーブがマスタから受信する更新をスレーブのバイナリ ログに記録するようにします。

  3. レプリケーション状態をリセットする前にすべての証拠を保存します。ノート： この問題を解決するには、できるだけ多くの問題を控えておいてください。収集する必要がある証拠

    • マスタからのすべてのバイナリ ログ

    • スレーブからのすべてのバイナリ ログ

    • 問題を認識した時点のマスタからの SHOW MASTER STATUS 出力

    • 問題を認識した時点のスレーブからの SHOW SLAVE STATUS 出力

    • マスタおよびスレーブのエラー ログ

  4. バイナリ ログを調べるには、mysqlbinlog を使用します。次に示すものは、問題があるステートメントを探し出すために役立ちます。 log_pos および log_file は、SHOW SLAVE STATUS からの Master_Log_File および Read_Master_Log_Pos 値です。 

    shell> mysqlbinlog -j log_pos log_file | head

問題からの証拠を収集した後は、まず全く別のテスト ケースとして、それを隔離してください。そして、より多くの情報とともに、バグ用のデータベースに入れてください。詳細は 項1.7. 「質問またはバグの報告」 で参照してください。