我已经在谷歌上彻底搜索了解决此问题的明确解决方案或一组步骤，但似乎没有很多高质量的结果，而且我还没有找到有关堆栈溢出的问题。我们正在尝试使用一台从服务器设置 MySQL 复制。从站看起来复制正常，然后出现以下错误：
无法解析中继日志事件条目。可能的原因有：master的二进制日志损坏（可以通过在二进制日志上运行“mysqlbinlog”来检查）、slave的中继日志损坏（可以通过在中继日志上运行“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
我尝试按照错误中的说明进行操作，并在从属的中继日志上运行 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 中找到的主服务器二进制日志上运行了 mysqlbinlog，并且在命令行上没有看到任何错误（但没有机会打开生成的 100mb 日志文件，因为我不想陷入困境）关闭生产服务器）。
所以现在我不知道还能尝试什么。我基本上只是在寻找有关可能出现问题的任何见解或有关下一步采取哪些步骤的任何建议。谢谢！
我不确定根本原因是什么。但要从这种情况中恢复，您需要指示 MySQL 清除超出以下点的所有中继箱日志
通过执行以下操作：
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 日志。
我不知道是否有人会觉得这个有用，但是当我遇到这个问题时，是因为mysql.conf.cnf中的配置错误，我重命名了数据库并忘记更新配置文件中的binlog_do_db...