使用innodb_force_recovery解決MySQL崩潰無法重啟問題

更新時間：2015年05月29日 10:40:02 投稿：junjie

這篇文章主要介紹了使用innodb_force_recovery解決MySQL崩潰無法重啟問題,這只一個成功案例,并不是萬能的解決方法,需要酌情考慮,需要的朋友可以參考下

一背景

某一創(chuàng)業(yè)的朋友的主機因為磁盤陣列損壞機器crash,重啟MySQL服務時報如下錯誤:

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Restoring possible half-written data pages from the doublewrite

InnoDB: buffer...

InnoDB: Doing recovery: scanned up to log sequence number 9120034833

150125 16:12:51 InnoDB: Starting an apply batch of log records to the database...

InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 150125 16:12:51 [ERROR] mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed, 

something is definitely wrong and this may fail.

Server version: 5.5.37-MariaDB-log

key_buffer_size=268435456

read_buffer_size=1048576

max_used_connections=0

max_threads=1002

thread_count=0

It is possible that mysqld could use up to 

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2332093 K bytes of memory

41 Hope that.

二分析

主要關注 mysqld got signal 11 的問題,從日志內(nèi)容分析來看,數(shù)據(jù)庫在機器crash 導致日志文件損壞,重啟之后無法正?；謴?更無法正常對外提供服務。

三解決

因為日志已經(jīng)損壞，這里采用非常規(guī)手段,首先修改innodb_force_recovery參數(shù)，使mysqld跳過恢復步驟，將mysqld 啟動,將數(shù)據(jù)導出來然后重建數(shù)據(jù)庫。

innodb_force_recovery可以設置為1-6,大的數(shù)字包含前面所有數(shù)字的影響。

1. (SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2. (SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執(zhí)行full purge操作，會導致crash。
3. (SRV_FORCE_NO_TRX_UNDO):不執(zhí)行事務回滾操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不執(zhí)行插入緩沖的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。
6. (SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作。

注意

a 當設置參數(shù)值大于0后，可以對表進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
b 當innodb_purge_threads 和 innodb_force_recovery一起設置會出現(xiàn)一種loop現(xiàn)象:

復制代碼代碼如下:

150125 17:07:42 InnoDB: Waiting for the background threads to start

150125 17:07:43 InnoDB: Waiting for the background threads to start

150125 17:07:44 InnoDB: Waiting for the background threads to start

150125 17:07:45 InnoDB: Waiting for the background threads to start

150125 17:07:46 InnoDB: Waiting for the background threads to start

150125 17:07:47 InnoDB: Waiting for the background threads to start

在my.cnf中修改以下兩個參數(shù)

復制代碼代碼如下:

innodb_force_recovery=6

innodb_purge_thread=0

重啟MySQL

復制代碼代碼如下:

150125 17:10:47 [Note] Crash recovery finished.

150125 17:10:47 [Note] Server socket created on IP: '0.0.0.0'.

150125 17:10:47 [Note] Event Scheduler: Loaded 0 events

150125 17:10:47 [Note] /vdata/webserver/mysql/bin/mysqld: ready for connections.

Version: '5.5.37-MariaDB-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution

立即對數(shù)據(jù)庫做邏輯導出，完成之后將innodb_force_recovery設置為0 ，innodb_purge_thread=1 ,然后重建數(shù)據(jù)庫。
另外 MySQL 版本 5.5以及之前 ,當innodb_purge_threads =1，innodb_force_recovery >1 的情況會出現(xiàn)上文提到的循環(huán)報warning 問題（=1 沒有問題），

原因：

MySQL 的源代碼中顯示當innodb_purge_threads 和 innodb_force_recovery一起設置會出現(xiàn)loop循環(huán)

復制代碼代碼如下:

while (srv_shutdown_state == SRV_SHUTDOWN_NONE) { 

      if (srv_thread_has_reserved_slot(SRV_MASTER) == ULINT_UNDEFINED 

          || (srv_n_purge_threads == 1 

          && srv_thread_has_reserved_slot(SRV_WORKER) 

          == ULINT_UNDEFINED)) { 

          ut_print_timestamp(stderr); 

          fprintf(stderr, " InnoDB: Waiting for the background threads to start\n");

          os_thread_sleep(1000000); 

      } else { 

          break; 

      } 

  }

所以當需要設置innodb_force_recovery>1的時候需要關閉 innodb_purge_threads，設置為0（默認）。

四小結

MySQL crash 或者 MySQL 數(shù)據(jù)庫服務器 crash 會導致各種各樣的問題，比如主備之間的error 1594 (5.6 版本開啟crash-safe ，會最大程度上避免 error 1594的問題，以后會寫5.6新特性介紹該功能 )，error 1236，日志損壞，數(shù)據(jù)文件損壞，等等，本案例只是其中的一種，細心從日志中找的相關錯誤提示，逐步解決即可。

您可能感興趣的文章:

MySQL參數(shù)innodb_force_recovery詳解

Mysql8.4數(shù)據(jù)庫安裝新建用戶和庫表
MySQL是最常用的數(shù)據(jù)庫,本文主要介紹了Mysql8.4數(shù)據(jù)庫安裝新建用戶和庫表,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
2024-07-07
解析mysql不重復字段值求和
本篇文章是對關于mysql不重復字段值求和進行了詳細的分析介紹，需要的朋友參考下
2013-06-06
MySQL CHAR和VARCHAR該如何選擇
MySQL 支持字符串的數(shù)據(jù)類型并不多，但是卻有多種變化形式。MySQL 5.0以后更是支持每一列字符串可以有自己的字符集以及排序規(guī)則，這使得數(shù)據(jù)表設計更為復雜。本篇介紹字符類型的數(shù)據(jù)表字段 CHAR 和 VARCHAR 該如何選擇。
2021-05-05
Linux虛擬機下mysql 5.7安裝配置方法圖文教程
這篇文章主要為大家詳細介紹了Linux虛擬機下mysql 5.7安裝配置方法圖文教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下
2017-01-01
基于Linux的mysql主從配置全過程記錄
這篇文章主要給大家介紹了基于Linux的mysql主從配置的相關資料，文中通過示例代碼介紹的非常詳細，對大家學習或者使用mysql具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧
2019-04-04
初探SQL語句復合主鍵與聯(lián)合主鍵
這篇文章主要介紹了初探SQL語句復合主鍵與聯(lián)合主鍵的相關內(nèi)容，具有一定參考價值，這里給大家分享下，需要的朋友可以參考。
2017-10-10
MySQL數(shù)據(jù)庫連接查詢?join原理
這篇文章主要介紹了MySQL數(shù)據(jù)庫連接查詢?join原理，文章首先通過將多張表連到一起查詢?導致記錄行數(shù)和字段列發(fā)生變化，利用一對一、一對多和多對多關系保證數(shù)據(jù)完整性展開主題內(nèi)容，需要的小伙伴可以參考一下
2022-06-06
PHP連接MySql閃斷自動重連的方法
當mysql連接閃斷時，之后循環(huán)的執(zhí)行將會失敗。這篇文章主要介紹了PHP連接MySql閃斷自動重連的方法，非常不錯，具有參考借鑒價值，感興趣的朋友一起學習吧
2016-08-08
Mysql更換MyISAM存儲引擎為Innodb的操作記錄總結
下面小編就為大家?guī)硪黄狹ysql更換MyISAM存儲引擎為Innodb的操作記錄總結。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
2017-03-03
Mysql觸發(fā)器在PHP項目中用來做信息備份、恢復和清空
這篇文章主要介紹了Mysql觸發(fā)器在PHP項目中用來做信息備份、恢復和清空的相關資料,需要的朋友可以參考下
2017-11-11