Re: Could not parse relay log event entry. error on slave
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 [EMAIL PROTECTED] 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 -- 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]
Re: Could not parse relay log event entry. error on slave
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 [EMAIL PROTECTED] 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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Could not parse relay log event entry. error on slave
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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
