Hello.
I recommend you to upgrade to 4.1.12 (4.0.24) because there were a lot of bug fixes as of 4.0.20. David Griffiths <[EMAIL PROTECTED]> wrote: > We are running 4.0.20 on two servers (AMD Opteron and Xeon). > > Our slave has died twice in the last month with the following error: > > "Could not parse relay log event entry. The possible reasons are: the > master's binary log is corrupted (you can check this by running > 'mysqlbinlog' on the binary log), the slave's relay log is corrupted > (you can check this by running 'mysqlbinlog' on the relay log), a > network problem, or a bug in the master's or slave's MySQL code. If you > want to check the master's binary log or slave's relay log, you will be > able to know their names by issuing 'SHOW SLAVE STATUS' on this slave." > > I've tried "resetting" replication by setting the master log file and > position to the values that are given by "show slave status" in case it > was a network hiccup, but the same error. > > After I did this, the slave's binary log file shows, > > /*!40019 SET @@session.max_insert_delayed_threads=0*/; > # at 4 > #691231 16:00:00 server id 1 log_pos 0 Rotate to > colossus-bin.030 pos: 12435199 > # at 47 > #691231 16:00:00 server id 1 log_pos 0 Rotate to > colossus-bin.030 pos: 12435199 > > > So I went to the master, and turned the binary log into a text file > using mysqlbinlog and scanned by hand the approximate time it died; I > didn't see anything particularily interesting. > > I then use mysqlbinlog with the -j option (to start parsing at a > particular spot; in this case, 12435199). The error I got was, > > ERROR: Error in Log_event::read_log_event(): 'Event too big', data_len: > 1701209458, event_type: 44 > Could not read entry at offset 12435199:Error in log format or read error > > Googling on some of the phrases in that error message didn't turn up > much, other than it could be potentially be a hardware or > disk-controller issue (we are using 3ware, self-built drivers).... > > Anyone have any thoughts? This has been fairly recent (we had some > max-allowed-packet issues till I bumped that up and reduced the size of > the binary logs). The hardware and software has been in place nearly a > year (except the kernel, which we bumped up to try to get around > corruption in the Innodb data files on the Opteron master). > > David > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
