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

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

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

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

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

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

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

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

   • 問題を発見した時点の、マスターからの SHOW MASTER STATUS の出力

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

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

4. mysqlbinlog を使用してバイナリログを調べます。次のことは、問題のステートメントを見つけるのに役立つはずです。log_file および log_pos は、SHOW SLAVE STATUS からの Master_Log_File および Read_Master_Log_Pos 値です。

   shell> mysqlbinlog --start-position=log_pos log_file | head

問題の証拠を収集したあとは、まずそれらを個別のテストケースとして切り分けてみてください。そのうえで、セクション1.7「質問またはバグをレポートする方法」での指示を使用して問題およびできるだけ多くの情報をオラクルのバグデータベースに入力してください。