我已经彻底搜索了谷歌一个确定的解决方案或一组步骤来解决这个问题,但似乎没有很多高质量的结果,我没有发现堆栈溢出的问题.我们正在尝试使用一个slave来设置MySQL复制.从属似乎正在复制,然后发生以下错误:
无法解析中继日志事件条目.可能的原因是:主服务器的二进制日志已损坏(您可以通过在二进制日志上运行'mysqlbinlog'来检查),从服务器的中继日志已损坏(您可以通过在中继日志上运行'mysqlbinlog'来检查),网络问题,或者主服务器或从服务器的MySQL代码中的错误.如果要检查主站的二进制日志或从站的中继日志,您可以通过在此从站上发出"SHOW SLAVE STATUS"来了解其名称.
为了使大量的人从搜索中不可避免地偶然发现这个问题,如果有人回复提供了可能出错的概述以及采取了哪些步骤来解决这个问题,那将会很有帮助,但我会还提供了与我的特定情况相关的更多详细信息,希望有人可以帮我解决.
我们导入到从服务器以启动它的转储是在主服务器上使用以下命令创建的:
mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql
执行此备份的脚本还会记录主服务器的当前二进制日志位置.然后,我们采取以下步骤在slave上启动复制:
1. STOP SLAVE;
2. DROP DATABASE dbname;
3. SOURCE dbname.sql;
(... waited a few hours for the 10gb dump to import)
4. RESET SLAVE;
5. CHANGE MASTER TO MASTER_HOST='[masterhostname]', MASTER_USER='[slaveusername]', MASTER_PASSWORD='[slaveuserpassword]', MASTER_PORT=[port], MASTER_LOG_FILE='[masterlogfile]', MASTER_LOG_POS=[masterlogposition];
6. START SLAVE;
经过大约一天的复制工作正常,它在凌晨3:43再次失败.MySQL错误日志中出现的第一件事就是上面的错误.然后使用相同的时间戳出现另一个一般错误:
Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log '[masterlogfile]' position [masterlogpos] …