mysql断电修复_MySQL断电恢复的一点简单分析

蔚落 2023-01-11 03:57 117阅读 0赞

![d91061355e7a9cc864da305e722f07f0.png][]

今天有个网友问我一个MySQL的恢复问题。提供的截图如下。

![cd969d30aa4512ea2d254ea4ef306c74.png][]

对于这个问题，在一些断电的场景下还是可能出现的。我首先是要确认是否为线上业务还是测试环境，线上业务来说这个影响还是很大的。如果数据库无法启动，首要任务还是把数据库启动，然后在这个基础上查看丢失的数据程度，安排数据修复的事宜。

当然从我的角度来说，怎么去快速复现这个问题呢。我用自己写的快速搭建测试主从环境的脚本(https://github.com/jeanron100/mysql\_slaves，后期有一位大牛建议用Python来做，最近在考虑)，分分钟即可搞定。

我们创建一个表test,指定id,name两个字段。然后开启显式事务。

createtabletest(idintprimarykey,namevarchar(30)notnull);

显式开启一个事务：

begin;

insertintotestvalues(1,'a');

insertintotestvalues(2,'b');

insertintotestvalues(3,'c');

不提交，我们直接查看mysql的服务进程，直接Kill掉。默认情况下双1指标是开启的，我们直接模拟断电重启，看看后台的处理情况：

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Highest supported file formatisBarracuda.

2017-09-13 15:05:11 35556 \[Note\] InnoDB: The log sequencenumbers 1625987and1625987inibdata files donotmatch the logsequencenumber 1640654inthe ib\_logfiles!

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Databasewasnotshutdown normally!

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Starting crash recovery.

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Reading tablespace information fromthe .ibd files...

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Restoring possible half-written data pages

2017-09-13 15:05:11 35556 \[Note\] InnoDB: fromthe doublewrite buffer...

InnoDB: 1 transaction(s) which must be rolled backorcleaned up

InnoDB: intotal 3 row operationstoundo

InnoDB: Trx id counter is2304

2017-09-13 15:05:11 35556 \[Note\] InnoDB: 128 rollbacksegment(s) are active.

InnoDB: Starting inbackground therollbackofuncommittedtransactions

2017-09-13 15:05:11 7f5ccc3d1700 InnoDB: Rolling back trx withid 1806, 3rowstoundo

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Rollbackoftrxwithid 1806 completed

2017-09-13 15:05:11 7f5ccc3d1700 InnoDB: Rollbackofnon-prepared transactions completed

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Waiting forpurgetostart

2017-09-13 15:05:11 35556 \[Note\] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.14-rel62.0 started; log sequencenumber 1640654

2017-09-13 15:05:11 35556 \[Note\] Recovering aftera crash using binlog

2017-09-13 15:05:11 35556 \[Note\] Starting crash recovery...

2017-09-13 15:05:11 35556 \[Note\] Crash recovery finished.

可以看到后台检测到了上次的异常宕机，然后开启崩溃恢复，InnoDB检测到日志LSN是1625987 而系统数据文件ibd的LSN为1625987 ，和ib\_logfiles里面的LSN不匹配。后面就是一系列的恢复，前滚，恢复，回滚。\*\*\*表里的数据为空，证明之前的事务都已经回滚了。

所以基于上面的情况，我们明白开启了事务，基本情况下这个问题是不会出现的，什么时候会抛出开始的错误呢。

我们继续测试，开启一个显式事务，不提交。

begin;

insertintotestvalues(1,'a');

insertintotestvalues(2,'b');

insertintotestvalues(3,'c');

然后杀掉mysql的服务进程，找到mysql的数据目录下，删除redo文件。完成后我们重启数据库。

这个时候就抛出了和截图类似的错误。

2017-09-13 16:05:14 36896 \[Note\] InnoDB: Highest supported file formatisBarracuda.

2017-09-13 16:05:14 7f73450a97e0 InnoDB: Error: page 7 log sequencenumber 1627722

InnoDB: isinthe future!Currentsystem logsequencenumber 1626124.

InnoDB: Your databasemay be corruptoryou may have copied the InnoDB

InnoDB: tablespace but notthe InnoDB log files. See

InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

InnoDB: formore information.

这个问题目前的影响范围其实还不明显，因为尽管如此，我们还是能够写入数据的。

mysql>insertintotestvalues(1,'a');

Query OK, 1 row affected (0.04 sec)

mysql> select\*fromtest;

\+----+------+

| id | name|

\+----+------+

| 1 | a |

\+----+------+

1 row inset(0.00 sec)

关于崩溃恢复，有一个数据参数尤其需要注意，那就是innodb\_force\_recovery，这个参数默认值为0，如果为非0的值(范围为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):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。

6 (SRV\_FORCE\_NO\_LOG\_REDO): 不执行前滚的操作。

当然这个参数的设置修改是需要重启MySQL服务的。

mysql>setglobalinnodb\_force\_recovery=2;

ERROR 1238 (HY000): Variable 'innodb\_force\_recovery'isareadonlyvariable

在此假设我们设置为2，再次复现这个问题问题，你就会发现，数据库暂时是可以启动的，但是数据只能查询，DML操作都会抛错。

mysql>select\*fromtest;

Empty set(0.00 sec)

mysql>

mysql> insertintotestvalues(1,'a');

ERROR 1030 (HY000): Got error -1 fromstorage engine

按照这个影响的范围来评估force\_recovery的值，我们就可以做相应的取舍了。如果MySQL服务无法正常启动，就可以修改这个参数值来调整，先满足服务可持续性的基本问题。然后评估后导出重要的数据来。

【编辑推荐】

【责任编辑：庞桂玉 TEL：(010)68476606】

[d91061355e7a9cc864da305e722f07f0.png]: /images/20221119/e0b9e460c65c401eae4c4a689fc042c0.png
[cd969d30aa4512ea2d254ea4ef306c74.png]: /images/20221119/b924b0ad59da42569a42e877d841a0fd.png