用innodb_force_recovery 修复崩溃的MySQL数据库

今天一大早访问网站,发现打不开了,提示数据库连接错误。重启服务器不起作用,一直提示

ERROR! MySQL server PID file could not be found!

郁闷!这次跟以前不一样,见《MySQL服务器启动错误 The server quit without updating PID file 的解决方法》,硬盘大小不是问题,我也早已停掉MySQL的日志文件。

查看/usr/local/mysql/var 目录下 CentOS错误日志 VM_14_80_centos.err,发现从昨晚23:04分开始,MySQL就已经报错,错误出在InnoDB引擎上。
170104 23:04:21 InnoDB: The InnoDB memory heap is disabled

那么就有个简单的方法开启数据库了,我们可以在etc/目录下的MySQL的配置文档 my.cnf 里的[mysqld]下添加一条语句

[mysqld]
innodb_force_recovery = 1

之后,重启lnmp,强制恢复 InnoDB引擎。待InnoDB恢复之后再将这句话删除,然后重启MYSQL服务即可。

不过在执行上述步骤之前,请先通过SFTP将 /usr/local/mysql/var 整个目录备份到本地,以免强制恢复的过程中出现不可逆转的错误。

警告
只有在紧急情况下将innodb_force_recovery设为大于0的值,你才能启动InnoDB并转储表。在进行此操作之前,确保你有数据库的备份副本,以备需要重建它。4及以上的值可以永久破坏数据文件。只有在数据库的独立物理副本的成功地测试了设置,才能在生产服务器实例使用4及以上的innodb_force_recovery设置。当强制InnoDB恢复,你应该总是以innodb_force_recovery=1启动,且仅在需要时增加值。
innodb_force_recovery默认为0(没有强制恢复的正常启动)。对于innodb_force_recovery允许的非零值是1至6。较大值包括较小值的功能。例如,为3的值包括所有的值1和2的功能。

如果你能以innodb_force_recovery为3或更低值转储你的表,那么你是比较安全的,只有在损坏的个人页的一些数据会丢失。4或更大的值被认为是危险的,因为数据文件可以被永久地损坏。值6被认为是严重的,数据库页被留在一个陈旧的状态,这反过来又可能带给B-trees和其它数据库结构更多的损坏。

最后,用数据备份工具备份一次数据,确保安全就可以了。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注