利用 force recovery 解决服务器 crash 导致 MySQL 重启失败的问题

时间:2024-07-20 22:07:08

小明同学在本机上安装了 MySQL 5.7.17 配合项目进行开发,并且已经有了一部分重要数据。某天小明在开发的时候,需要出去一趟就直接把电脑关掉了,没有让 MySQL 正常关闭,重启 MySQL 的时候,报错如下:

...
[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=3611051955, page number=1571966525], should be [page id: space=86, page number=4]
...
[ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=86, page number=4]. You may have to recover from a backup.
...
[ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or,  there was a failure in tagging the tablespace  as corrupt.
...

从日志内容来看,MySQL 在机器关机的时候有数据没有落地,导致日志文件损坏,重启之后无法正常恢复,线程在数据页中读取不到需要的 page 和数据。

因为日志文件已经损坏,需要做特殊操作,让 MySQL 跳过恢复,启动 MySQL,然后把数据导出来,再重建数据库导入。

MySQL 有个一个特性:Forcing InnoDB Recovery,启用这个特性需要设置 innodb_force_recovery 大于 0。

innodb_force_recovery 可以设置为 1-6,大的数字包含前面所有数字的影响。

  1. (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。
  2. (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行,如主线程需要执行 full purge 操作,会导致 crash。
  3. (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作。
  4. (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作。
  5. (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志,InnoDB 存储引擎会将未提交的事务视为已提交。
  6. (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。

注意:
为了安全,当设置参数值大于 0 后,可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的,当 innodb_force_recovery 的值大于等于 4 的时候,InnoDB 表处于只读模式。

前面说了,日志数据不一致,重启时前滚恢复失败,因此在重启的时候不要执行前滚的操作,在 /etc/mysql/my.cnf 中添加:

innodb_force_recovery=6

然后重启 MySQL,立即对数据库用 mysqldump 把数据导出。完成后,去掉 innodb_force_recovery 或者设置为 0,然后重新创建数据库,把数据导入。

MySQL crash 或者 MySQL 服务器 crash 会导致各种各种的问题 ,但 MySQL 5.6 版本开始怎增了 crash-safe 的特性,可以在最大程度上避免 error 1594 的问题,如何开启这个功能可以参考上一篇博文:MySQL 5.6 从库开启 crash-safe 功能,遇到问题,要淡定,细心阅读日志,从中找的相关错误提示,然后依据错误找到相关的解决方法来解决问题。