I have been using the mysqlbinlog to investigate the 'saturn2-bin.051' binlog file.. I have come to pinpoint the problem position in the binlog, but don't know how i can bypass the corrupted segment.
This is a bit tricky. Open the binlog in a hex editor, and go to the last good offset (printed in the comments). At offset 9 from there you will find a 4-byte integer in little-endian format. That is the length of the last good event. Add it to the last good offset. Now you are at the corrupted event. This is where the science ends and the black magic begins.
Again, at offset 9 you will find what is supposed to be the event length, and at offset 4 you will find 1 byte event type code. The codes are listed in sql/log_event.h in the enum Log_event_type. Figure out where the next good event really starts, and fix up the type to be something innocent (eg. INTVAR_EVENT) + the length so that you will jump to the next event.
As a word of caution, you may not find much useful data after the corrupted event, but if it is at the end of file, you can manually put a ROTATE_EVENT to instruct the slave to switch to the next log.
However, if this is a practical problem, and not just a study of how things work, I would suggest reporting the bug ( if this happened with the latest version), and resetting the replication.
-- Sasha Pachev Create online surveys at http://www.surveyz.com/
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
