From: Date: March 2 2005 6:44pm Subject: Re: "Could not parse relay log event entry." error on slave List-Archive: http://lists.mysql.com/mysql/180793 Message-Id: <4225FB6C.2080204@boats.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the response. We can't afford to lose information, and I don't like doing dangerous things. I guess it's time to rebuild the slave. David Gleb Paharenko wrote: >Hello. > > > > > >>Other than rebuilding the slave from a backup of the master, is there >> >> > > > >>any way to get the replication backup up? >> >> > > > >Have you tried to stop a slave and then start with SQL_SLAVE_SKIP_COUNTER = n, > >as suggested at: > > http://dev.mysql.com/doc/mysql/en/replication-problems.html > > > >But if the replication starts succesfully, you'll lose some information > >(which can be critical). You may RESET the slave and then use a CHANGE > >MASTER statement to begin the replication with 889778259 bin-log position. > >However it is dangerous: if the slave SQL thread was in the middle of > >replicating temporary tables when it was stopped, and RESET SLAVE is issued, > >these replicated temporary tables are deleted on the slave. > > > > > > > >David Griffiths wrote: > > > >>We have a master-slave setup in production. >> >> > > > > > > >>The master is running on a dual-Opteron with SuSE 8 SLES. >> >> > > > > > > >>The slave is running on a dual Xeon with SuSE 9. >> >> > > > > > > >>Both run MySQL 4.0.20 >> >> > > > > > > >>We recently moved our traffic database to the machine and started >> >> > > > >>writing additional traffic (perhaps as much as 600,000 inserts/updates >> >> > > > >>plus at least as many selects per day). >> >> > > > > > > >>We use Nagios to monitor the machines, and have gotten alerts that the >> >> > > > >>slave is not responding (this started yesterday, which is our busiest day). >> >> > > > > > > >>This morning, the alert appeared again, but this time, there was an >> >> > > > >>error in "show slave status" >> >> > > > > > > >>"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 am running a "mysqlbinlog" on the current binary log on the slave, but >> >> > > > >>it's a large file, and is still going. >> >> > > > > > > >>On the master, the binary-log-pos is 929084940. On the slave, it's way >> >> > > > >>back at 889778259 >> >> > > > > > > >>Other than rebuilding the slave from a backup of the master, is there >> >> > > > >>any way to get the replication backup up? >> >> > > > > > > >>David >> >> > > > > > > > >