我已经彻底搜索了谷歌的最终解决方案或解决此问题的一系列步骤，但似乎没有很多高质量的结果，我还没有找到关于堆栈溢出的问题。我们正在尝试使用一个slave来设置MySQL复制。从属似乎复制正常，然后发生以下错误：
无法解析中继日志事件条目。可能的原因是：主服务器的二进制日志已损坏（您可以通过在二进制日志上运行'mysqlbinlog'来检查），从服务器的中继日志已损坏（您可以通过在中继日志上运行'mysqlbinlog'来检查），网络问题，或者主服务器或从服务器的MySQL代码中的错误。如果要检查主站的二进制日志或从站的中继日志，您可以通过在此从站上发出“SHOW SLAVE STATUS”来了解其名称。
为了使大量的人从搜索中不可避免地偶然发现这个问题，如果有人回复提供了可能出错的概述以及采取了哪些措施来解决这个问题，将会很有帮助，但是我还会提供下面与我的具体情况有关的更多细节，希望有人可以帮我解决。
我们导入到从服务器以启动它的转储是在主服务器上使用以下命令创建的：
mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql
执行此备份的脚本还会记录主服务器当前的二进制日志位置。然后我们采取以下步骤开始在奴隶上复制：
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]
有关更多日志记录信息，我已经设置了一个批处理脚本，每小时运行“SHOW SLAVE STATUS”和“SHOW FULL PROCESSLIST”。以下是失败前后的结果：
--Monitoring: 3:00:00.15
Slave Status:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.xxx.xxx
Master_User: slave_user
Master_Port: xxxx
Connect_Retry: 60
Master_Log_File: mysql-bin.000xxx
Read_Master_Log_Pos: 316611912
Relay_Log_File: dbname-relay-bin.00000x
Relay_Log_Pos: 404287513
Relay_Master_Log_File: mysql-bin.000xxx
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: dbname
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 316611912
Relay_Log_Space: 404287513
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
*************************** 1. row ***************************
Id: 98
User: system user
Host:
db: NULL
Command: Connect
Time: 60547
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 99
User: system user
Host:
db: NULL
Command: Connect
Time: 5
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 3. row ***************************
Id: 119
User: root
Host: localhost:xxxx
db: NULL
Command: Query
Time: 0
State: NULL
Info: SHOW FULL PROCESSLIST
--Monitoring: 4:00:02.71
Slave Status:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.xxx.xxx
Master_User: slave_user
Master_Port: xxxx
Connect_Retry: 60
Master_Log_File: mysql-bin.000xxx
Read_Master_Log_Pos: 324365637
Relay_Log_File: dbname-relay-bin.00000x
Relay_Log_Pos: 410327741
Relay_Master_Log_File: mysql-bin.000xxx
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB: dbname
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_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.
Skip_Counter: 0
Exec_Master_Log_Pos: 322652140
Relay_Log_Space: 412041238
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
*************************** 1. row ***************************
Id: 98
User: system user
Host:
db: NULL
Command: Connect
Time: 64149
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 122
User: root
Host: localhost:3029
db: NULL
Command: Query
Time: 0
State: NULL
Info: SHOW FULL PROCESSLIST
我尝试按照错误中的说明操作并在slave的中继日志上运行mysqlbinlog，其中包含start_position数千条语句，并在失败点后停止数千条语句，并将输出重定向到文本文件。我没有在命令行或日志文件中看到任何损坏错误。这就是日志文件围绕失败点所说的内容：
...
# at 410327570
#120816 3:43:26 server id 1 log_pos 322651969 Intvar
SET INSERT_ID=3842697;
# at 410327598
#120816 3:43:26 server id 1 log_pos 322651997 Query thread_id=762340 exec_time=0 error_code=0
SET TIMESTAMP=1345113806
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation");
# at 410327741
#120816 3:44:26 server id 1 log_pos 322754486 Intvar
SET INSERT_ID=3842701;
# at 410327769
#120816 3:43:26 server id 1 log_pos 322754514 Query thread_id=762340 exec_time=0 error_code=0
SET TIMESTAMP=1345113866;
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation");
# at 410327912
...
有意思的是它在那时记录了一个无效的浮点运算，但我不确定这会如何导致复制在该位置中断。我在上面的SHOW SLAVE STATUS中找到的master的二进制日志上运行mysqlbinlog，并且在命令行上没有看到任何错误（但是没有机会打开因为我不想生成而生成的100mb日志文件在生产服务器上。）
所以现在我不知道还有什么可尝试的。我基本上只是在寻找可能出现问题的任何见解，或者对于接下来要采取的步骤提出任何建议。谢谢！
答案 0 :(得分：24)
我不确定根本原因是什么。但是要从这种情况中恢复，你需要指示MySQL清除以下几点之外的所有relay-bin-logs
执行以下操作：
STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000xxx', MASTER_LOG_POS = 322652140; START SLAVE;
注意：对于那里的读者，不要被Relay_Master_Log_File搞糊涂，它与Read_Master_Log_Pos不同。并且不要将Exec_Master_Log_Pos与Read_Master_Log_Pos混淆。 Read_ *是一种预读策略，MySQL在本地执行复制的实际实现之前从主服务器下载复制bin日志。