记录一次数据库炸后恢复数据经历

事情起因

在docker作业1的时候，把卷映射到了宿主机原来的mysql数据库目录上，宿主机原来的mysql版本为8.0，docker容器版本为5.6，导致翻车。

具体操作

备份目录

将/var/lib/mysql备份到~/mysql_backup：cp /var/lib/mysql ~/mysql_backup -r

重装mysql

教程

第一次恢复数据

尝试根据备份文件进行恢复。

把备份的数据库guess_word_game拷贝到新的数据库文件目录中：

# 关闭mysql服务 systemctl stop mysqld
mkdir /var/lib/mysql/guess_word_game cp ~/mysql_backup/guess_word_game/* /var/lib/mysql/guess_word_game/ -r
# 修改所有者
chown -R mysql:mysql /var/lib/mysql
# 启动mysql服务
systemctl start mysqld

重启mysql服务后，发现没有guess_word_game数据库。

覆盖ibdata1到数据目录中：

# 关闭mysql服务 systemctl stop mysqld
cp ~/mysql_backup/ibdata1 /var/lib/mysql
# 修改所有者
chown -R mysql:mysql /var/lib/mysql

重启mysql服务，发现启动失败

查看日志less /var/log/mysqld.log

又炸了--，重装吧，原因可能是我用hyperf的migrate建表了，然后导致数据不对。

第二次恢复数据

查阅文档，终于找到解决方法：博客网址，只需把备份目录中的文件迁移到数据库目录中即可，然后再把需要恢复的数据库文件夹迁移进去。

• ibdata1：保存表中元信息，mysql8把表中元信息整合到了.ibd中了
• ib_logfile0/1：redo日志
• ib_buffer_pool：缓冲池
• auto.cnf：存储了server-uuid的值，集群模式下有用
• mysql.ibd：存储着一些MySQL服务器内部的元数据信息，例如用户权限、存储引擎、字符集等等

迁移完后，嗯，不出意外的话，又出意外了。

这里说mysql版本号太旧，新建的文件是80032版本的，而数据库版本是80031版本的，尼玛这也不兼容，好烦，只能重装新版mysql了。

重装之后，数据恢复了555555

有可能是我在/etc/my.cnf中写了innodb_force_recovery=8，删掉再重启试试

嗯，我又把redo_log迁移过去了，一夜回到解放前。吐了。。。

第三次恢复数据

不用重装mysql，直接删除/var/lib/mysql目录，这次只迁移ibdata1、mysql.ibd和对应数据库文件夹，更改文件夹权限，然后重启mysqld服务，发现不报错了，并且数据得到恢复。

可以发现，密码没有重置、且对数据库操作权限都在，所以判断这些内容都存在mysql.ibd中

总结

• mysql无法启动时，立即将数据文件备份，数据文件目录默认在：/var/lib/mysql中。
• innodb_force_recovery：故障时候强制恢复，使用这个的时候可以忽略错误正常启动mysql，具体见官方文档（文档中有数字1-6的具体解释，我也不知道数字8代表什么，我就不知道在哪个博客看到8我就照搬了--，没自己脑子）
• 各个文件的意义
  • ibdata1：保存表中元信息，mysql8把表中元信息整合到了.ibd中了
  • ib_logfile0/1：redo日志
  • ib_buffer_pool：缓冲池
  • auto.cnf：存储了server-uuid的值，集群模式下有用
  • mysql.ibd：存储着一些MySQL服务器内部的元数据信息，例如用户权限、存储引擎、字符集等等
  • .ibd：储存了表中的数据信息，B+树

其他

其实恢复还有几种方法，比如说：

• 通过innodb_force_recovery参数强制启动mysql服务后，对数据库数据进行转储sql（适用于无bin log的情况）
• 通过binlog进行数据恢复（没试过，下次试一下）
• 通过备份进行数据恢复（最差方法）

在数据恢复中犯的错误

照搬内容，不了解别人为什么这么做，比如说照搬第二次恢复数据中别人的操作步骤，导致把redolog二次迁移，而这次故障原因就是redolog的问题

参考资料

innodb_force_recovery