MySQL报错MY-012356和ER_IB_MSG_531，远程帮忙修复故障经验分享

前段时间,我遇到一个非常棘手的MySQL数据库故障，当时数据库毫无征兆地就崩溃了，重启也失败，把我和团队都急坏了，故障现象是MySQL服务完全起不来，查看错误日志后，发现了两个关键的报错信息，一个是MY-012356，另一个是ER_IB_MSG_531，这两个错误码就像谜题一样，需要我们一步步去解开。

根据MySQL官方文档和一些技术社区的案例分享（来源：MySQL官方文档及Percona社区讨论），MY-012356这个错误通常与InnoDB存储引擎的重做日志（Redo Log）有关，错误信息大致是说“在重做日志文件中发现了一个被损坏的检查点”，你可以把重做日志想象成数据库的“工作日记”，它记录所有还没正式保存到数据文件里的操作，而检查点就像是日记里的一个重要书签，标记着哪些工作已经完成了一半，这个书签坏了，数据库就不知道从哪里开始继续它的工作，所以它干脆就“罢工”了。

而另一个错误ER_IB_MSG_531，根据同样的信息来源，它往往是伴随出现的，更具体地指出了问题所在，信息类似“日志扫描未能找到有效的检查点”，这相当于确认了第一个错误的判断，数据库在尝试翻阅它的“工作日记”来恢复状态时，从头到尾都没找到一个能用的起点。

这两个错误一结合,问题的根源就清晰了：数据库的重做日志文件（通常是ib_logfile0和ib_logfile1）很可能因为服务器突然断电、硬件故障或者磁盘空间不足等原因而损坏了。

当时的情况是,客户的生产环境数据库在一次非正常关机后出现了这个问题，由于没有最近的完整备份，直接丢弃重做日志意味着会丢失一部分数据，这是不能接受的，我们制定的修复目标是：在尽可能保留数据的前提下，恢复数据库服务。

我们的修复步骤是这样的,整个过程非常紧张：

第一步,绝对备份，在动手做任何操作之前，我们立刻将整个MySQL的数据目录（主要是/var/lib/mysql）完整地打包压缩，复制到安全的机器上，这是最重要的“后悔药”，万一修复操作让情况更糟，我们还能回到起点。

第二步,尝试强制恢复，MySQL提供了一个参数叫innodb_force_recovery，它可以让InnoDB引擎忽略一些错误，强行启动起来，然后我们就能有机会把数据导出来，这个参数的值从1到6，严重程度递增，我们当时的策略是从最低的级别1开始尝试。

我们修改了MySQL的配置文件（通常是my.cnf），在[mysqld]模块下加了一行：innodb_force_recovery = 1，然后尝试启动MySQL服务，结果失败了，错误依旧，我们不甘心，逐步提高这个值到2、3……直到设置为4的时候，MySQL服务终于勉强启动起来了！当时大家稍微松了一口气。

第三步,紧急数据导出，数据库以恢复模式（innodb_force_recovery=4）启动后，状态是非常不稳定的，只能进行只读操作，我们不敢有任何耽搁，立刻用mysqldump这个工具，将所有重要的业务数据库快速导出成SQL文件，在这个过程中，我们发现有一两张表确实因为日志损坏而无法读取，出现了报错，但绝大部分核心数据都成功导出了，我们记录了哪些表受损，以便后续通知业务方。

第四步,彻底重建，数据导出后，我们彻底关闭MySQL服务，为了有一个干净的环境，我们做了以下操作：

1. 再次确认MySQL服务已停止。
2. 将原来的数据目录重命名作为备份（比如mv /var/lib/mysql /var/lib/mysql_backup）。
3. 重新初始化一个全新的MySQL数据目录（使用mysqld --initialize命令）。
4. 将之前导出的SQL文件重新导入到新的数据库中。
5. 恢复正常启动MySQL,并通知业务方进行数据验证。

这次远程故障修复花了大概四个小时,主要时间都耗在尝试不同的innodb_force_recovery级别和数据导出导入上，虽然最后成功恢复了绝大部分数据，但教训是非常深刻的，它让我们意识到，定期的、可靠的数据备份和日志备份（二进制日志）是多么重要，如果当时有完整的备份，恢复过程会简单和快速得多，也不至于那么提心吊胆，也让我们对InnoDB的重做日志机制有了更深刻的理解，以后再看到类似的错误码，心里就不会那么慌了。