记一次mysql断电后恢复

发布于 2019-12-29  283 次阅读


MySql版本为8.0.16,笔记本电池一天比如一天,这两天都是用到忽然断电关机,今天跑程序发现连不上MySql了,去服务里启动,也是一启动就挂掉,看日志才发现问题,文件损坏了,看日志记录里说官方建议使用 innodb_force_recovery 参数去强制恢复一下,如果用不超过4的选项值来恢复你的表,那么是比较安全的,只有一些在损坏的单独页面上的数据会丢失。如果为6的话可能出点问题,因为数据库页被留在一个陈旧的状态,这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。

解决方案我在网上查阅了大概就下面三种,我用的第3种,重新初始化mysql然后导入之前的数据

1.删除data目录的ib_logfile0,ib_logfile1,ib_logfile_XXXX这些日志文件,然后重启mysql服务,但是我这里不行.

2.innodb_force_recovery参数设置后(设置为=6),重启mysql服务,然后my.ini再把这个参数去掉,重启服务,我这也不行.....

3. (1)拿之前的数据库备份来恢复,新建个data目录,重新执行mysqld --initialize命令(数据库初始密码会记录在日志中),然后连接数据库,导入数据。(2)执行mysqldump -u用户名 -p密码 -A > database.sql 命令导出所有数据,然后和(1)步骤一样,执行initialize。

initialize后,查看日志中的初始密码,然后修改密码,mysql -uroot -p连接上mysql后执行

alter user root@'localhost' identified by 'your password';

日志关键代码如下

2019-12-29T12:04:57.733014Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2019-12-29T12:04:57.742475Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:3306:for_table || ref_table thread 824
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:04:57 UTC - mysqld got exception 0x80000003 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

我刚开始用的innodb_force_recovery=6这个参数,在my.ini中添加后重启服务即可连上,但是连上后数据库相当于是只读的了, 去掉参数再重启服务又还是出错,于是只能重新初始化mysql然后导入备份数据了,下面详细说下这个innodb_force_recovery这个参数.

innodb_force_recovery还可以设置为6个非零值:1~6。大的数字包含了前面所有小数字的影响,具体情况如下。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看撤销日志(Undo Log),InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
作为一个安全措施,InnoDB在innodb_force_recovery大于0时阻止INSERT,UPDATE或DELETE操作。对于MySQL5.6.15,将innodb_force_recovery设为4或更高会让InnoDB处于只读模式



LoneKing