[[205074]]

今天有個網(wǎng)友問我一個MySQL的恢復(fù)問題。提供的截圖如下。

對于這個問題，在一些斷電的場景下還是可能出現(xiàn)的。我首先是要確認是否為線上業(yè)務(wù)還是測試環(huán)境，線上業(yè)務(wù)來說這個影響還是很大的。如果數(shù)據(jù)庫無法啟動，首要任務(wù)還是把數(shù)據(jù)庫啟動，然后在這個基礎(chǔ)上查看丟失的數(shù)據(jù)程度，安排數(shù)據(jù)修復(fù)的事宜。

當(dāng)然從我的角度來說，怎么去快速復(fù)現(xiàn)這個問題呢。我用自己寫的快速搭建測試主從環(huán)境的腳本(https://github.com/jeanron100/mysql_slaves，后期有一位大牛建議用Python來做，最近在考慮)，分分鐘即可搞定。

我們創(chuàng)建一個表test,指定id,name兩個字段。然后開啟顯式事務(wù)。

create table test(id int primary key,name varchar(30) not null); 

顯式開啟一個事務(wù)：

begin; 
insert into test values(1,'a'); 
insert into test values(2,'b'); 
insert into test values(3,'c');  

不提交，我們直接查看mysql的服務(wù)進程，直接Kill掉。默認情況下雙1指標是開啟的，我們直接模擬斷電重啟，看看后臺的處理情況：

2017-09-13 15:05:11 35556 [Note] InnoDB: Highest supported file format is Barracuda. 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: The log sequence numbers 1625987 and 1625987 in ibdata files do not match the log sequence number 1640654 in the ib_logfiles! 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: Database was not shutdown 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 from the .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: from the doublewrite buffer... 
 
InnoDB: 1 transaction(s) which must be rolled back or cleaned up 
 
InnoDB: in total 3 row operations to undo 
 
InnoDB: Trx id counter is 2304 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: 128 rollback segment(s) are active. 
 
InnoDB: Starting in background the rollback of uncommitted transactions 
 
2017-09-13 15:05:11 7f5ccc3d1700 InnoDB: Rolling back trx with id 1806, 3 rows to undo 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: Rollback of trx with id 1806 completed 
 
2017-09-13 15:05:11 7f5ccc3d1700 InnoDB: Rollback of non-prepared transactions completed 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: Waiting for purge to start 
 
2017-09-13 15:05:11 35556 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.14-rel62.0 started; log sequence number 1640654 
 
2017-09-13 15:05:11 35556 [Note] Recovering after a 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.  

可以看到后臺檢測到了上次的異常宕機，然后開啟崩潰恢復(fù)，InnoDB檢測到日志LSN是1625987 而系統(tǒng)數(shù)據(jù)文件ibd的LSN為1625987 ，和ib_logfiles里面的LSN不匹配。后面就是一系列的恢復(fù)，前滾，恢復(fù)，回滾。***表里的數(shù)據(jù)為空，證明之前的事務(wù)都已經(jīng)回滾了。

所以基于上面的情況，我們明白開啟了事務(wù)，基本情況下這個問題是不會出現(xiàn)的，什么時候會拋出開始的錯誤呢。

我們繼續(xù)測試，開啟一個顯式事務(wù)，不提交。

begin; 
 
insert into test values(1,'a'); 
 
insert into test values(2,'b'); 
 
insert into test values(3,'c');  

然后殺掉mysql的服務(wù)進程，找到mysql的數(shù)據(jù)目錄下，刪除redo文件。完成后我們重啟數(shù)據(jù)庫。

這個時候就拋出了和截圖類似的錯誤。

2017-09-13 16:05:14 36896 [Note] InnoDB: Highest supported file format is Barracuda. 
 
2017-09-13 16:05:14 7f73450a97e0 InnoDB: Error: page 7 log sequence number 1627722 
 
InnoDB: is in the future! Current system log sequence number 1626124. 
 
InnoDB: Your database may be corrupt or you may have copied the InnoDB 
 
InnoDB: tablespace but not the InnoDB log files. See 
 
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html 
 
InnoDB: for more information.  

這個問題目前的影響范圍其實還不明顯，因為盡管如此，我們還是能夠?qū)懭霐?shù)據(jù)的。 

mysql> insert into test values(1,'a'); 
 
Query OK, 1 row affected (0.04 sec) 
 
mysql> select *from test; 
 
+----+------+ 
 
| id | name | 
 
+----+------+ 
 
| 1 | a | 
 
+----+------+ 
 
1 row in set (0.00 sec)  

關(guān)于崩潰恢復(fù)，有一個數(shù)據(jù)參數(shù)尤其需要注意，那就是innodb_force_recovery，這個參數(shù)默認值為0，如果為非0的值(范圍為1-6)，會有下面的影響范圍。

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的corrupt頁。

2 (SRV_FORCE_NO_BACKGROUND): 阻止主線程的運行，如主線程需要執(zhí)行full purge操作，會導(dǎo)致crash。

3 (SRV_FORCE_NO_TRX_UNDO): 不執(zhí)行事務(wù)回滾操作。

4 (SRV_FORCE_NO_IBUF_MERGE): 不執(zhí)行插入緩沖的合并操作。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務(wù)視為已提交。

6 (SRV_FORCE_NO_LOG_REDO): 不執(zhí)行前滾的操作。

當(dāng)然這個參數(shù)的設(shè)置修改是需要重啟MySQL服務(wù)的。

mysql> set global innodb_force_recovery=2; 
 
ERROR 1238 (HY000): Variable 'innodb_force_recovery' is a read only variable  

在此假設(shè)我們設(shè)置為2，再次復(fù)現(xiàn)這個問題問題，你就會發(fā)現(xiàn)，數(shù)據(jù)庫暫時是可以啟動的，但是數(shù)據(jù)只能查詢，DML操作都會拋錯。

mysql> select *from test; 
 
Empty set (0.00 sec) 
 
mysql> 
 
mysql> insert into test values(1,'a'); 
 
ERROR 1030 (HY000): Got error -1 from storage engine  

按照這個影響的范圍來評估force_recovery的值，我們就可以做相應(yīng)的取舍了。如果MySQL服務(wù)無法正常啟動，就可以修改這個參數(shù)值來調(diào)整，先滿足服務(wù)可持續(xù)性的基本問題。然后評估后導(dǎo)出重要的數(shù)據(jù)來。