5.4.6 レプリケーションバグまたは問題を報告する方法|無料CGI PHPサイト(新着情報、営業日カレンダーなど)

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

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

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

ユーザによるエラーではないことを確認します。例：スレーブスレッド外側のスレーブを更新する場合は、非同期のデータになり、更新時にユニークキー制約である可能性があります。この場合、スレーブスレッドは停止している状態で、それらを同期で持ち込むために、手動によるテーブルのクリーンアップを待機しています。これは、レプリケーションに関する問題ではありません。これは外部からの障害がレプリケーションの失敗に起因しているということです。
--log-slave-updates および --log-bin オプションでスレーブを実行します。これらのオプションでスレーブがマスタから受信する更新をスレーブのバイナリログに記録するようにします。
レプリケーション状態をリセットする前にすべての証拠を保存します。ノート：この問題を解決するには、できるだけ多くの問題を控えておいてください。収集する必要がある証拠
- マスタからのすべてのバイナリログ
- スレーブからのすべてのバイナリログ
- 問題を認識した時点のマスタからの SHOW MASTER STATUS 出力
- 問題を認識した時点のスレーブからの SHOW SLAVE STATUS 出力
- マスタおよびスレーブのエラーログ
バイナリログを調べるには、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. 「質問またはバグの報告」で参照してください。

無料PHPプログラム

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

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