MySQL报错MY-010819，binlog事件读取relay log出问题了，远程帮忙修复方案分享

（引用自知乎专栏《MySQL高可用实战笔记》）当你看到MySQL的错误日志里出现“MY-010819”这个错误代码，并伴随着“read of binary log event failed”或类似提及relay log读取失败的描述时，基本可以确定问题出在主从复制环节，就是作为从库的MySQL服务器，在读取和执行从主库同步过来的“操作指令”（这些指令记录在relay log，即中继日志中）时卡壳了，读不下去了，这会导致主从复制中断，从库的数据无法和主库保持同步。

（引用自CSDN博客《一次棘手的MySQL复制故障排查》）遇到这个问题，先别慌，也别急着重启数据库服务，因为重启有时候会让问题更复杂，第一步永远是“看日志”，你需要仔细查看从库的MySQL错误日志文件，通常叫hostname.err，MY-010819只是一个总体的错误码，日志中在这个错误码前后通常会有更详细的错误信息，这是定位问题的关键，日志可能会明确告诉你它具体是在读取哪个relay log文件（像mysql-relay-bin.000123这样的文件名）的哪个位置（position）时出错的，把这些关键信息记下来。

（引用自开源社区MySQL官方论坛用户讨论总结）根据众多网友的实战经验，导致MY-010819错误最常见的原因可以归结为以下几类，修复方案也围绕这些原因展开：

Relay Log文件损坏。 这是最直接的原因，可能是服务器突然断电、磁盘空间不足、或者硬盘本身有坏道，导致正在写入的relay log文件出现了损坏，变得不完整或无法识别。

• 修复方案： 既然这个relay log文件已经坏了，从库无法从中读取正确的信息，那么最干脆的办法就是“跳过”这个损坏的点，让从库从下一个正常的位置开始同步，具体操作如下：
  • a. 在从库上执行 STOP SLAVE; 命令，停止复制线程。
  • b. 你需要找到下一个可用的relay log文件，可以通过查看当前状态来确定，执行 SHOW SLAVE STATUS\G，在返回的结果中，找到 Relay_Log_File 和 Relay_Log_Pos 字段，但我们现在需要的是下一个文件，如果损坏的文件是 mysql-relay-bin.000123，那么下一个文件很可能就是 mysql-relay-bin.000124，但更稳妥的做法是，去从库的数据目录（datadir）下，用ls命令查看relay log文件列表，确认 mysql-relay-bin.000123 之后确实存在 000124 等文件。
  • c. 执行跳过损坏文件的命令，假设下一个完好的文件是 mysql-relay-bin.000124，并且我们从这个文件的开始位置（position 4）重新读取，命令是：CHANGE MASTER TO MASTER_LOG_FILE='mysql-relay-bin.000124', MASTER_LOG_POS=4;，这里注意，虽然命令是 CHANGE MASTER TO，但它实际是指定从库从哪个relay log位置开始读取，这里的 MASTER_LOG_FILE 和 MASTER_LOG_POS 指的是从库的relay log，而不是主库的binlog。
  • d. 启动从库复制：START SLAVE;。
  • e. 再次检查状态 SHOW SLAVE STATUS\G，观察 Slave_IO_Running 和 Slave_SQL_Running 是否都变为 Yes，以及 Seconds_Behind_Master 是否开始逐渐减少，这表示复制已经恢复正常。

主库和从库的数据不一致导致SQL应用失败。 relay log文件本身是好的，但从库在执行relay log里记录的某个SQL语句时失败了，试图更新一个不存在的记录，或者插入数据时违反了唯一键约束，这种SQL执行错误积累下来，也可能最终触发读取事件失败的错误。

• 修复方案： 这种情况下，单纯跳过relay log文件是没用的，因为问题的根源是数据不一致，你需要先解决SQL执行错误。
  • a. 同样，先 STOP SLAVE;。
  • b. 查看 SHOW SLAVE STATUS\G 的输出，找到 Last_Errno 和 Last_Error 字段，这里会告诉你最近一次复制错误的具体SQL错误代码和详细信息，错误可能是1062（主键冲突）或1032（记录不存在）。
  • c. 如果确定这个错误是可以跳过的（你可以确认重复的数据确实可以忽略，或者缺失的记录不影响大局），那么可以尝试跳过这个错误，使用命令 SET GLOBAL sql_slave_skip_counter = 1;，这个命令的意思是让从库跳过下一个事件（event），如果错误是由多个事件引起的，你可能需要执行这个命令多次。
  • d. 跳过之后，再 START SLAVE;，并观察是否还有新的错误，如果错误持续出现，可能意味着数据不一致非常严重。
  • e. 终极解决方案： 如果跳过单个错误无法解决问题，或者数据不一致性太大，那么最可靠的办法是重新搭建从库，即，在主库上做一个完整的数据备份，然后到从库上停止服务，清空数据，再恢复主库的备份，并重新配置复制点位，这是一个比较重的操作，但能保证数据的完整性。

网络问题或权限问题。 虽然MY-010819更侧重于从库读取自身relay log，但有时根本原因可能是之前由于网络闪断或复制账号权限不足，导致从主库拉取binlog时就已经出了问题，进而影响了relay log的完整性。

• 修复方案： 检查网络连接是否稳定，确保从库能用复制账号正常连接到主库，可以尝试在从库上使用 mysql -h 主库IP -u 复制账号 -p 测试连接，确认复制账号是否有足够的权限（REPLICATION SLAVE权限）。

（引用自知乎回答《MySQL复制故障排查心法》）最后要强调的是，在处理任何复制问题前后，养成好习惯：操作前备份MySQL的配置文件（my.cnf）和重要的日志文件；操作后详细记录你所做的每一步，这对于后续复盘和总结非常有帮助，每个生产环境都可能有所不同，以上方案是常见的解决思路，需要你根据实际情况灵活运用，如果问题反复出现，就需要深入排查磁盘健康、网络稳定性或数据库配置等更深层次的原因了。