MySQL报错ER_RPL_CORRUPTED_INFO_TABLE，远程帮忙修复故障怎么搞

这个ER_RPL_CORRUPTED_INFO_TABLE错误,说白了就是MySQL用来管理主从复制（就是一台服务器的数据变动自动同步到另一台服务器的那套机制）的关键信息表坏了，这张表名字通常是slave_relay_log_info或slave_master_info，它存在于从库的数据库里，根据MySQL官方文档的描述，这类表（InnoDB引擎的复制信息表）在特定情况下可能会因为部分写入或损坏而导致复制中断并抛出此错误。

当你看到这个报错,意味着从库已经无法准确知道自己同步到主库的哪个位置了，复制进程（SQL线程或IO线程）会停止，修复的核心思路是重新确定从库的同步起点，然后重新开始同步，但在这之前，你必须做出一个关键决策：是尝试修复这张表，还是直接重置复制信息。

重要警告：以下操作涉及数据库变更，存在风险，强烈建议在执行任何操作前，对从库数据库进行完整备份，如果可能，先在测试环境演练。

尝试简单修复（如果损坏不严重）

这个方法适用于你认为表损坏可能是由于临时的写入问题导致的,或许还能抢救一下。

1. 停止复制：你需要在从库上停止复制进程，连接到从库的MySQL命令行，执行：

   STOP SLAVE;

2. 检查表状态：尝试查看损坏的表的内容，确认损坏程度，查看mysql.slave_relay_log_info表：

   SELECT * FROM mysql.slave_relay_log_info;

   如果这个命令能执行,但数据显示乱码或不完整，或者命令直接报错说表不存在或损坏，那就需要更进一步的行动。

3. 使用MySQL修复工具：如果表是MyISAM引擎（旧版本默认），可以尝试使用REPAIR TABLE命令，但根据MySQL官方文档的说明，如果这些表是InnoDB引擎（新版本默认且推荐），REPAIR TABLE命令不被支持，你可以用SHOW CREATE TABLE mysql.slave_master_info;来查看表引擎，对于InnoDB表，这一步通常可以跳过，因为修复能力有限。

4. 手动纠正表内容（高级操作，需谨慎）：

   • 如果表存在但内容明显错误（主库日志坐标Master_Log_File和Master_Log_Pos的值变得非常奇怪），并且你非常清楚正确的同步位置，你可以尝试用UPDATE语句直接修改这张表。
   • 这极其危险！ 一旦坐标写错，会导致数据不一致，除非你是专家，否则不建议这样做。

由于方法一成功率不高且风险大,对于生产环境，更常用、更稳妥的方法是方法二。

重置复制信息（最常用、最彻底的方法）

这个方法的本质是抛弃旧的、损坏的同步位置信息，从头开始或者从一个已知的可靠位置重新建立同步。

1. 停止复制：

   STOP SLAVE;

2. 重新定位同步起点：这是最关键的一步，你需要决定从主库的哪个位置开始重新同步，有两个主流选择：

   • A. 从头开始同步：这适用于你可以接受从库数据被完全覆盖，或者主从数据差异不大且可以接受短暂服务中断的情况，你需要获取主库当前的二进制日志位置。
     • 在主库上执行：SHOW MASTER STATUS; 记录下返回的File和Position值。
   • B. 从最近的一致性备份点开始：这是更安全、更推荐的做法，特别是主从数据可能已存在较大差异时，你需要找到一个从库在损坏之前最后一次正常同步时所对应的主库日志位置，这个信息通常包含在你之前为从库做备份时的元数据中（比如使用mysqldump --master-data备份的文件开头会有CHANGE MASTER TO语句）。

3. 重置从库的复制环境：在从库上执行以下命令，这将清除所有旧的复制信息，包括损坏的表中的数据。

   RESET SLAVE ALL; -- MySQL 8.0及更新版本推荐使用ALL选项，更彻底。

   在老版本中,可能只需要RESET SLAVE;，执行后，原来的slave_master_info等表会被清空。

4. 重新配置复制链路：使用第2步中确定的正确位置，重新告诉从库如何连接到主库以及从哪里开始同步。

   CHANGE MASTER TO
   MASTER_HOST='你的主库IP地址',
   MASTER_USER='复制专用的用户名',
   MASTER_PASSWORD='复制用户的密码',
   MASTER_LOG_FILE='第2步中记录的文件名',
   MASTER_LOG_POS=第2步中记录的位置值;

   请将单引号内的内容替换为你的实际信息。

5. 启动复制并验证：

   START SLAVE;

   然后检查复制状态：

   SHOW SLAVE STATUS\G

   查看输出中的Slave_IO_Running和Slave_SQL_Running是否都是Yes，并检查Seconds_Behind_Master是否逐渐减少变为0，确保没有新的错误信息。

预防措施

根据MySQL官方文档和一些最佳实践,为了避免此类问题再次发生，你可以考虑：

• 使用事务性表：确保master_info_repository和relay_log_info_repository设置为TABLE（这是默认设置），并且这些表使用事务性存储引擎（如InnoDB），以保证复制元数据写入的原子性，你可以通过SHOW VARIABLES LIKE '%repository%';来检查。
• 定期监控：定期检查从库的复制状态，确保没有延迟和错误。
• 定期备份：不仅备份业务数据，也要记录备份时主库的二进制日志位置，这在恢复时至关重要。

ER_RPL_CORRUPTED_INFO_TABLE错误虽然听起来吓人,但通过重置复制并从一个已知的良好位置重新开始，通常可以解决，重点是确保你选择的重新同步起点是正确的，以避免数据混乱，如果你无法确定正确的起点，那么从最新的完整备份恢复从库是更安全的选择。