stop slave;
change master to master_log_file='Relay_Master_Log_File' ,
master_log_pos=Exec_master_log_pos;
#Get the values for the above command from your show slave status output.
start slave;
The above process should fix your problem.
On 9/4/07, Russell E Glaue <rglaue@stripped> wrote:
>
> I had a disk full error on the master MySQL (4.1.22), which was
> replicating to a
> slave (4.1.22).
>
> My question is, how do I recover a slave replica when the master had a
> disk full
> error, space was freed, but the 'disk full' issue left a corrupted master
> binlog?
> 1) Do I have to reinitialize the slave from scratch,
> 2) or can I use some CLI tool to repair the damaged binlog (see below)
> 3) or can I skip to the next binlog
>
> This is assuming I performed a stop and start of the master mysql, then
> 'purge
> binary logs' from master.
> And would the resolution be the same if I did not start and stop the
> master mysql?
>
>
> According to bug 9949 (http://bugs.mysql.com/bug.php?id=9949) this was
> addressed
> in 4.1.9.
> I am running 4.1.22, and have experienced this issue as outlined.
>
> I am not finding a good sum of reasoning and process to proceed with
> resolving
> this type of predicament. Can anyone clue me in to resolving this?
>
>
> I purged enough binlogs to free up disk space on master, and then started
> the
> slave replica process on the slave.
>
> I get this famous error:
> -
> 070904 12:46:26 [Note] Slave I/O thread: connected to master
> 'replica_user@stripped:3306', replication started in log '
> master1-bin.000054' at
> position 138164107
> 070904 12:46:26 [ERROR] Error reading packet from server: binlog truncated
> in
> the middle of event (server_errno=1236)
> 070904 12:46:26 [ERROR] Got fatal error 1236: 'binlog truncated in the
> middle of
> event' from master when reading data from binary log
> -
>
> I do a binlog dump on 'master1-bin.000054', and I get the below error
> ('Error in
> log format or read error') at the end of the output:
>
> -
> #070904 11:46:22 server id 2 end_log_pos 137541177 Query
> thread_id=48871
> exec_time=0 error_code=0
> #070904 11:46:22 server id 2 end_log_pos 137655584 Query
> thread_id=48871
> exec_time=0 error_code=0
> #070904 11:46:22 server id 2 end_log_pos 137655719 Query
> thread_id=48773
> exec_time=0 error_code=0
> #070904 11:46:22 server id 2 end_log_pos 137770204 Query
> thread_id=48773
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 137770339 Query
> thread_id=48870
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 137962851 Query
> thread_id=48870
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 137962986 Query
> thread_id=48871
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 138152129 Query
> thread_id=48871
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 138152264 Query
> thread_id=48773
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 138163972 Query
> thread_id=48773
> exec_time=0 error_code=0
> #070904 11:46:24 server id 2 end_log_pos 138164107 Query
> thread_id=48870
> exec_time=0 error_code=0
> ERROR: Error in Log_event::read_log_event(): 'read error', data_len:
> 81904,
> event_type: 2
> Could not read entry at offset 138164107:Error in log format or read error
> -
>
>
> -RG
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=1
>
>
--
Thanks
Alex
http://alexlurthu.wordpress.com