记一次mysql断电后恢复 | 我的个人技术分享

type

status

date

slug

summary

category

icon

password

ext

order

comment

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处于只读模式

🗒️docker yml 配置文件编写

🗒️Linux下远程桌面连接Xrdp+vnc+xfce4以及黑屏等问题