事情起因
在做docker作业的时候,把卷映射到了宿主机原来的mysql数据库目录上,宿主机原来的mysql版本为8.0,docker容器版本为5.6,导致翻车。
具体操作
备份目录
将/var/lib/mysql备份到~/mysql_backup:cp /var/lib/mysql ~/mysql_backup -r
重装mysql
第一次恢复数据
尝试根据备份文件进行恢复。
把备份的数据库guess_word_game
拷贝到新的数据库文件目录中:
bash
# 关闭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到数据目录中:
bash
# 关闭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的问题