使用しているレプリケーション設定で問題が発生しています。数か月間は問題なく機能しており、週末にかけて、スレーブはマスターbinlogからの更新の読み取りをエラーGot fatal error 1236 from master when reading data from binary log: 'bogus data in log event'
で停止しました。
Mysqlbinlogを使用して関連するバイナリログを読み取ろうとすると、次のエラーが表示されます。
[root@slglcd-01] # mysqlbinlog ibm-pr-slglcd-01.000075 > /dev/null
ERROR: Error in Log_event::read_log_event(): 'Event too small', data_len: 0, event_type: 0
ERROR: Could not read entry at offset 1828: Error in log format or read error.
[root@slglcd-01] #
イライラ! --start-position
と--offset
のさまざまな組み合わせを使用して悪いデータを試してみましたが、何も機能していないようです...
私が求めているのは、バイナリログ内からこのエラーをスキップ(または削除)して、問題のある項目なしで新しいバイナリログを作成し、レプリケーションを続行できるようにする方法です。
ステートメントが失われることは心配していません。これはsyslogコレクションデータベースであり、欠落している行の1つが損傷することはありません。
マスターがBLACKHOLE
エンジンを使用しているため、マスターからスレーブを再作成することはできません。したがって、実際のデータは保存されていません...
最悪の事態が発生した場合は、シーケンスの次のバイナリログから始めて、問題のログに残っているデータを失う必要があります。
事前に感謝、デイブ
マスターのバイナリログが破損しているため、他にできることはありません。お悔やみ申し上げます。次のbinlogにスキップしてください:
STOP SLAVE;
CHANGE MASTER TO master_log_file='ibm-pr-slglcd-01.000076',master_log_pos=107;
START SLAVE;
もちろん、107はMySQL 5.5バイナリログの開始位置です。マスターが5.1(または5.0.95)の場合は106を使用します。マスターが5.1より前の場合は98を使用します。
マスターBinLogの破損が頻繁に発生する場合は、マスターのバイナリログに小さいサイズ(デフォルトの1Gではなく128M)を使用することを検討する必要がある場合があります。
[mysqld]
max_binlog_size=128M
これによって破損が止まることはありませんが、サイズを小さくすると、データの損失が1Gから128Mに最小化されます。
非常によく似た問題が1回ありました。
すでに述べたように、問題は正しい--start-positionを見つけることです。
Hexeditor/xxdで破損したbinlog-fileを調べて(私の場合、破損した位置でいくつかのブロックがゼロになっているのを見つけるために)、binlog-fileのこの明らかに壊れた部分をスキップして次の部分を探し、有用なSQLステートメントがhexdumpに表示され、binlogはおそらくそのままでした。
Hexdumpで正しいbinlog-headerを識別するために、開発者のドキュメント http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log を調べました。
基本的に、ヘッダーはタイムスタンプ(4バイト)、タイプフィールド(1バイト)、およびMaster-Server-Replication-ID(4バイト)で始まります。
私の場合、サーバーIDは比較的簡単に識別できたので、サーバーIDの位置だと思ったものから5を引いて、この値をmysqlbinlogの開始位置として入力しました。
これをスレーブの新しいmaster-posとして設定すると、最終的にレプリケーションが再び実行されます。
はい、これは「ダーティ」であり、いくつかのステートメントを失いますが、あなたはすでにこれを認識しているので、これはあなたの場合に役立つかもしれません。