我已经在谷歌彻底搜索了一个明确的解决方案或一组步骤来解决这个问题，但似乎没有很多高质量的结果，我也没有找到堆栈溢出的问题。我们正在尝试使用一个从属设备来设置 MySQL 复制。从站似乎复制正常，然后出现以下错误：
无法解析中继日志事件条目。可能的原因是：主服务器的二进制日志已损坏（您可以通过在二进制日志上运行“mysqlbinlog”来检查），从服务器的中继日志已损坏（您可以通过在中继日志上运行“mysqlbinlog”来检查），a网络问题，或者主从的 MySQL 代码中的错误。如果你想检查主服务器的二进制日志或从服务器的中继日志，你可以通过在这个从服务器上发出“SHOW SLAVE STATUS”来知道它们的名字。
为了使大量在搜索中不可避免地偶然发现这个问题的人受益，如果回复的人概述了可能出现的问题以及解决此问题应采取的步骤，这将是有帮助的，但我会还在下面提供与我的特殊情况相关的更多详细信息，希望有人可以帮助我解决它。
我们导入到从属服务器以启动它的转储是在主服务器上使用以下命令创建的：
mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql
执行此备份的脚本还会记录 master 的当前二进制日志位置。然后我们采取以下步骤在从属设备上开始复制：
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
我尝试按照错误中的说明在从属的中继日志上运行 mysqlbinlog，之前使用 start_position 数千条语句，在故障点之后使用 stop_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 日志文件，因为我不想陷入困境关闭生产服务器）。
所以现在我不知道还有什么可以尝试的。我基本上只是在寻找关于可能出了什么问题的任何见解或关于下一步采取什么步骤的任何建议。谢谢！