Looks like I can't simply delete the relay binlog, since while the slave continued to run it continued to update it's place in the master binlog. So, short of copying all the data over again, what can I do? Can I just pick a random spot in the master binlog that was before the slave choked? Are there any side effects of having some of the replicated commands fail? Most of the updates to the db have been REPLACEs, with a few INSERTs and no DELETEs...If it fails on a few INSERTs is that likely to cause any problems? If it does cause problems, is it possible that failed INSERT commands to the master are causing the slave's relay logs to become corrupt? (There happen to be a good deal of failed inserts to the master as a result of a sloppy script that is run regularly...)
I'm really loathe to copy all the data (~250GB) from scratch again, as that took me all day last sunday, and this is the second time my relay logs have been corrupted.
My master server: P3 700MHz, 768MB with 3ware IDE RAID0 array
My slave server: Dual P3 700MHz, 512MB with Adaptec IDE RAID0 array
both running MySQL 4.0.15-Max and linux 2.4.18 kernels
Partap Davis wrote:
Hi,
So I set up replication and everything seemed to be going alright for a couple days until the slave server stopped responding. Any attempts to connect to the slave server hang indefinitely, and if I ssh into the machine, any attempts to access the data disk also hang.
I had to hard-boot the server to get any response...the data disk (reiserfs) claimed it was alright, but MySQL says the relay log file is corrupted, verified by mysqlbinlog:
[EMAIL PROTECTED] data]# mysqlbinlog stout-relay-bin.001 >/dev/null
ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 70266926, event_type: 46
ERROR: Could not read entry at offset 756432957 : Error in log format or read error
fsck says the file system is consistent. Also, no problems found with the master binlog...
Can I just delete the relay-bin files and reset the master info to continue at the point of failure? (assuming the disk is not bad and the data is valid...which it seems to be so far)
Thanks, Partap Davis
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
