一次修改数据库物理文件形成Mysql宕机的恢复记录

事件起始

某夜，我正在床上冥想准备入睡，突然同事向我求救：消息内容以下：

Oh My Gold 改了些配置，啥都没了!都没了!没了!了!

我仔细询问，原来是她由于某些缘由将某库的物理文件夹更名后，发现数据库找不到了。因而又将名称改回来。结果仍然找不到。这让她以为数据可能被损坏了，因而赶紧来找我修复。

修复过程

咱们数据库用的版本是 MySQL5.7 ,放置在Linux服务器上，在my.cnf 配置了数据库物理文件的存放地址。存放于 data 文件夹下。

表的存储引擎所有使用 InnoDB，data 目录的文件依次以下

• 用数据库名命名的文件夹，文件夹内存放的 .ibd , .frm 文件依次是数据库表数据文件和表结构文件
• ibdata1 (存放InnoDB表元数据、undo logs、the change buffer, and the doublewrite buffer) 文件
• ib_logfile0 ，ib_logfile1 事务日志

这个时候我首先想到的是我本机用Navicat备份过一个文件，马上打开Navicat尝试还原备份，然而日志全是 Err错误，显示表存在，可是咱们是看不到的。这时候我就打算删除该库，直接使用备份恢复，然而数据库删除仍然报错。我只得去备份了一下物理文件而后删除。删除后再使用Navicat还原

通过一番操做，数据库文件是回来了。可是我电脑上的备份文件他不是实时的，虽然恢复了数据库，但仍然丢失了部分数据，我心有不甘。因而我想了一个“妙计”： 我把刚才备份的物理文件里面的 .frm .ibd 文件替换到新建立的物理文件夹中。这样狸猫换太子以后，我岂不是就拥有了最完整的数据？

说干就干，一通 cp -rf 事后，成功替换掉原来的文件。打开Navicat链接没有问题，内心窃喜。就在这时，陆续有同事反应数据库连不上了，个人天呐。什么鬼？我打开MoBa查看linux 进程，发现Mysql 服务已经宕掉了。我尝试重启，报出以下错误：

查看Mysql 错误日志：

This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

通过上网查询，说是能够经过在 my.cnf 添加以下的配置来强制启动数据库官方文档对于该配置的解释 ，同类问题的回答

[mysqld]
innodb_force_recovery = 1

• 1 （SRV_FORCE_IGNORE_CORRUPT）

  使服务器即便检测到损坏的页也能够运行 。尝试跳过损坏的索引记录和页，这有助于转储表。

• 2 （SRV_FORCE_NO_BACKGROUND）

  阻止主线程和任何清除线程运行。若是在清除操做期间发生崩溃，则此恢复值可防止崩溃。

• 3 （SRV_FORCE_NO_TRX_UNDO）

  崩溃恢复后 不运行事务回滚。

• 4 （SRV_FORCE_NO_IBUF_MERGE）

  防止插入缓冲区合并操做。若是它们会致使崩溃，请不要这样作。不计算表 统计信息。此值可能会永久损坏数据文件。使用此值后，准备删除并从新建立全部二级索引。设置 InnoDB为只读。

• 5 （SRV_FORCE_NO_UNDO_LOG_SCAN）

  启动数据库时 不查看撤消日志： InnoDB甚至将未完成的事务也视为已提交。此值可能会永久损坏数据文件。设置InnoDB为只读。

• 6 （SRV_FORCE_NO_LOG_REDO）

  不进行与恢复有关的重作日志前回滚。此值可能会永久损坏数据文件。使数据库页面处于过期状态，这又可能致使B树和其余数据库结构遭受更多破坏。设置 InnoDB为只读。

官方文档特别说明：当级别 >= 4 时，可能会对数据库文件形成不可挽回的破坏。我尝试从1 开始逐步修改该值启动。直到 6 才正常启动。启动后，只能执行查询语句，增删改都不行。因而我将数据库文件所有备份后。关闭数据库，删除原来的 数据库物理文件、ibdata1 文件、ib_logfile0 文件。以后将 innodb_force_recovery 值还原为默认值0。从新恢复了数据库文件。解除了这次危机。

启发

1. 定时备份数据库！即便是测试库。测试库能够调的时间间隔长一点
2. 在不懂的状况下不要自做聪明乱动物理文件！