事情起因
在做docker作业的时候，把卷映射到了宿主机原来的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
