MySQL报错MY-013025怎么破，远程帮忙修复故障全过程分享

那天下午，我正在摸鱼想着晚上吃啥，突然钉钉上弹出一条紧急消息，是一个合作团队的开发小哥发来的，点开一看，是一张数据库连接失败的截图，还有一句带着哭腔的文字：“哥，救命！数据库突然连不上了，服务全挂了！”

我让他别慌，先把MySQL的错误日志发给我看看，他登录到服务器，在/var/log/mysql/error.log文件里，很快就找到了罪魁祸首,日志里用红色字体醒目地报出一个错误：

[ERROR] [MY-013025] [Server] Database 'mysql' is not accessible (error: -1, database not initialized)

看到这个错误代码MY-013025，我心里咯噔一下，因为这个错误通常意味着MySQL认为它最重要的系统数据库（名字就叫mysql）出问题了，甚至认为这个数据库压根没被初始化，这可不是普通的表损坏,这是动摇了根基的大问题。

我首先问他：“兄弟，你是不是手滑把mysql这个系统库给删了？或者服务器磁盘是不是满了？”他非常肯定地说绝对没有删除任何数据库，而且检查了磁盘空间,还剩很多。

这就奇怪了，我让他再用systemctl status mysql命令看看MySQL服务的状态，他反馈说，服务状态是active (exited)，这个状态很关键，exited意味着服务启动过，但很快就退出了,属于启动失败。

既然服务起不来，日志又指向mysql库无法访问，我怀疑是mysql库的表文件损坏了，我告诉他，我们需要尝试修复这些核心的系统表，因为MySQL服务本身已经无法启动，我们没法用常规的mysqlcheck之类的在线修复工具。

这时候，我想起了MySQL官方文档里提到的一种“大招”——强制恢复模式，这个方法有点风险，但往往是这种情况下唯一的希望,我让他按我的步骤来：

第一步，先彻底停止MySQL服务，他执行了sudo systemctl stop mysql,确认服务已经停止。

第二步，也是最关键的一步，是修改MySQL的配置文件my.cnf（通常位于/etc/mysql/或/etc/my.cnf），我让他在[mysqld]这个配置段下面,添加一行配置：

innodb_force_recovery = 1

我特别跟他强调，这个参数的值可以从1设置到6，数字越大，强制恢复的能力越强，但数据损坏的风险也越高,我们一定要从最小的数字1开始尝试。

第三步，保存配置文件后，我让他再次启动MySQL服务：sudo systemctl start mysql，我们俩都屏住呼吸盯着终端，过了一会儿，他兴奋地说：“哥，服务状态变成active (running)了！启动了！”

服务是起来了，但这只是第一步，我提醒他，现在MySQL是运行在一种“只读”的紧急模式下，主要是为了让我们能把数据导出来,我们不能在这种模式下长期运行业务。

第四步，既然服务能连了，我让他立刻用命令行工具连接上MySQL，然后赶紧执行数据库全库备份，特别是要把那个出问题的mysql系统库完整地导出,他执行了类似下面的命令：

mysqldump -u root -p --all-databases > full_backup.sql

备份过程很顺利，没有报错，这让我们都松了一口气，只要有备份,心里就有底了。

第五步，备份完成后，我让他再次停止MySQL服务，回到my.cnf配置文件里，注释掉或者直接删除我们刚才添加的那行innodb_force_recovery = 1，这一步非常重要，如果不取消,MySQL会一直处于只读的恢复模式。

第六步，再次启动MySQL服务，这一次，MySQL会以正常模式启动，令人欣喜的是，服务正常启动，没有任何错误日志！他尝试连接数据库，查询mysql.user表，一切正常，应用程序重新连接,也恢复了工作。

整个故障从发生到解决，大概用了一个小时，事后我们分析，很可能是因为服务器之前非正常关机（比如突然断电），导致mysql系统库的InnoDB表空间文件出现了轻微的逻辑错误，从而触发了MY-013025这个报错，而innodb_force_recovery这个参数，就像是给MySQL打了一剂“强心针”，暂时忽略了某些一致性检查，强行把服务拉起来,给我们创造了宝贵的备份和修复窗口。

这次远程支援也算是有惊无险，我最后叮嘱开发小哥，一定要把刚才备份出来的full_backup.sql文件妥善保存好,并且以后务必保证数据库服务器的定期备份和正常关机流程。