MySQL报错MY-013035，ER_IB_MSG_1210故障修复和远程处理办法分享

MySQL数据库在运行过程中,有时会在错误日志中看到编号为MY-013035的报错信息，这个错误对应的内部代码是ER_IB_MSG_1210，根据MySQL官方文档和社区的经验分享，这个错误通常与InnoDB存储引擎的恢复过程密切相关，它的核心意思是：InnoDB引擎在启动时，尝试重做日志文件（通常名为ib_logfile0, ib_logfile1）中的操作来恢复数据，但发现这些日志记录的事务信息与当前系统表空间（通常是ibdata1文件）中的信息对不上，或者日志文件本身出现了不可预料的损坏，导致恢复过程无法继续。

这个错误往往发生在数据库服务器意外关闭之后,比如服务器突然断电、操作系统崩溃，或者是MySQL进程被强制杀死（kill -9）等非正常关机的情况，当再次启动MySQL服务时，InnoDB会进入恢复模式，读取重做日志来重放那些已经提交但尚未完全写入数据文件的事务，以及回滚那些未提交的事务，从而保证数据的一致性，而MY-013035错误正是在这个关键环节出现了问题。

导致这个错误的具体原因可能包括以下几个方面：

1. 重做日志文件损坏： 这是最常见的原因，由于突然断电或磁盘问题，正在被写入的日志文件可能只写了一部分内容，造成了文件损坏，日志文件有固定的格式和校验和，一旦损坏，InnoDB就无法正确解析。
2. 系统表空间（ibdata1）损坏或不一致： 系统表空间存储了非常重要的元数据，如果它本身在意外关机中受损，或者其状态与日志文件记录的状态存在无法调和的分歧，也会触发这个错误。
3. 不兼容的服务器版本变更： 在某些极少数情况下，如果你在未经过正确步骤的情况下，降级了MySQL服务器的版本，新（旧）版本的InnoDB可能无法正确读取旧（新）版本生成的日志文件，从而导致恢复失败。
4. 磁盘空间不足： 在数据库运行期间，如果磁盘空间已满，可能会导致日志写入不完整，进而引发损坏。
5. 硬件故障： 内存错误或磁盘坏道等底层硬件问题，是导致数据文件损坏的根本原因之一。

当面对MY-013035错误时，尤其是在远程管理服务器的情况下，可以按照以下步骤进行排查和修复，请务必谨慎操作，因为每一步都关系到数据的安全。

第一步：立即停止服务并备份现场

在尝试任何修复操作之前,最重要的一步是停止MySQL服务，防止任何进一步的写入操作加重损坏，命令很简单： systemctl stop mysql 或 /etc/init.d/mysql stop。

立即对整个MySQL数据目录（通常是/var/lib/mysql）进行完整的备份，这是你的“救命稻草”，即使修复失败，你还可以回到最初的状态，可以使用tar命令打包：tar -czvf mysql_data_backup_before_repair.tar.gz /var/lib/mysql。

第二步：检查错误日志获取更多线索

使用cat或tail命令仔细查看MySQL的错误日志文件（通常位于/var/log/mysqld.log或数据目录下的hostname.err），MY-013035错误信息的前后通常会有更详细的上下文信息，可能会提示是哪个具体的日志文件出了问题，或者有其他相关错误，这些信息对判断损坏程度很有帮助。

第三步：尝试最基本的修复方法——配置强制恢复

InnoDB提供了一个强大的参数innodb_force_recovery，它可以强制InnoDB存储引擎启动，即使是在恢复过程中遇到某些错误的情况下，这个参数的值从1到6，数字越大，尝试的恢复力度越强，但也会使得数据库处于只读模式，并且可能会丢失部分数据。

远程操作时，建议从低到高逐个尝试：

1. 编辑MySQL的配置文件,通常是/etc/my.cnf或/etc/mysql/my.cnf。
2. 在[mysqld]部分添加一行：innodb_force_recovery = 1。
3. 保存并尝试启动MySQL服务：systemctl start mysql。
4. 如果启动失败,继续查看错误日志，如果错误依旧，则停止服务，将参数值改为2，然后重复步骤3。
5. 依此类推,直到最大值6。

根据MySQL官方手册的说明，不同级别的含义大致如下：

• 1 (SRV_FORCE_IGNORE_CORRUPT): 即使检测到损坏的页，也强制服务器运行。
• 2 (SRV_FORCE_NO_BACKGROUND): 阻止主线程和任何清理线程运行。
• 3 (SRV_FORCE_NO_TRX_UNDO): 在崩溃恢复后不运行事务回滚。
• 4 (SRV_FORCE_NO_IBUF_MERGE): 阻止插入缓冲区的合并操作。
• 5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 启动数据库时不查看撤销日志。
• 6 (SRV_FORCE_NO_LOG_REDO): 不进行前滚恢复操作。

重要提示： 当使用级别3或更高级别启动成功后，数据库将变为只读，此时你的首要任务不是继续提供写服务，而是立即使用mysqldump工具将能读取出来的所有数据导出备份，因为在这种模式下，数据库是不稳定的。

第四步：如果强制恢复无效，考虑替换日志文件

如果innodb_force_recovery设置到6都无法启动，而错误信息明确指向重做日志文件，可以尝试一个更激进的方法：用新的日志文件替换掉可能损坏的旧日志文件。这个方法会导致最后一次检查点之后的所有数据变更丢失。

1. 确保MySQL服务已完全停止。
2. 将数据目录下旧的日志文件重命名（而不是删除）以作备份：mv ib_logfile0 ib_logfile0.bak 和 mv ib_logfile1 ib_logfile1.bak。
3. 再次启动MySQL服务,InnoDB检测到日志文件不存在，会尝试创建新的日志文件，如果启动成功，InnoDB会完成一个“不完美”的恢复，可能会丢失一些数据。
4. 启动后,立即对数据库进行全面的检查和数据导出备份，可以使用mysqlcheck -A --check-upgrade或CHECK TABLE语句来检查表的一致性。

第五步：从备份中恢复数据

无论通过第三步还是第四步成功启动了数据库并导出了数据,最后一步都应该是：

1. 停止MySQL服务。
2. 彻底清空或移除当前的问题数据目录。
3. 重新初始化一个全新的MySQL数据目录。
4. 将第三步中用mysqldump导出的SQL文件重新导入到新的数据库中。

预防措施

为了避免再次遇到此类问题,应该：

• 配置不间断电源（UPS）： 防止突然断电。
• 实施定期备份： 包括全量备份和二进制日志增量备份，并定期验证备份的可恢复性。
• 使用稳定可靠的硬件： 特别是存储设备。
• 遵循规范流程： 永远使用systemctl stop mysql等命令正常关闭数据库服务，避免强制杀进程。

MY-013035错误是一个严重的启动错误，修复过程存在数据丢失的风险，远程处理时，冷静、有序地按照从温和到激进的步骤进行尝试，并始终把备份放在第一位，是成功解决问题的关键，如果所有自救方法都失败，并且数据极其重要，那么寻求专业数据库恢复服务的帮助可能是最后的选择。