Mysql Forcing InnoDB Recovery

最近在開發過程中,由于電腦突然死機需要重啟,重啟后導致mysql啟動不了,因為電腦崩潰時mysql數據文件錯誤,此時可以使用innodb_force_recovery選項來恢復。

下面是對官方的innodb_force_recovery文檔翻譯
Mysql版本:5.5

為了驗證數據庫頁面是否損壞,可以使用SELECT ... INTO OUTFILE從數據庫導出數據表。一般情況下以這種方式獲得的數據大多數是完整的。但如果是損壞嚴重的數據可能導致SELECT * FROM tbl_name語句或InnoDB后臺操作崩潰或斷言,甚至導致InnoDB回滾恢復崩潰。在這種情況下,可以使用innodb_force_recovery選項讓InnoDB存儲引擎強制啟動,同時防止后臺操作運行,這樣可以轉儲表了。例如,您可以在重新啟動服務器之前將以下行添加到mysql配置文件的[mysqld]下面:

[mysqld]
innodb_force_recovery = 1

注意
在進行這個操作之前,務必備份數據庫。
在緊急情況下,為了可以啟動InnoDB并轉儲表,必須將innodb_force_recovery設置為大于0的值。
4或更高的值可能會永久損壞數據文件。在測試數據庫的單獨物理副本上操作成功后,才能在生產服務器使用4或更高版本的innodb_force_recovery設置。當InnoDB強制恢復時,應該始終以innodb_force_recovery = 1開始,并根據需要逐漸增加值。為什么從1開始呢,因為1是最保險的,可以看后面對不同值的解釋。

innodb_force_recovery默認為0(正常啟動)。 innodb_force_recovery的非零值是從1到6。較大的值包括較小值的功能。例如,3包括1和2的所有功能。

innodb_force_recovery值為3或更小時,只有損壞的單個頁面上的某些數據丟失。 4或更高的值是危險的,因為數據文件可能永久損壞。6不建議使用,因為數據庫頁面處于過時狀態,這陸續可能在B樹和其他數據庫結構中引入更多的損壞。

為了安全起見,InnoDB在innodb_force_recovery大于0時會阻止INSERT,UPDATE或DELETE操作。

【Mysql 5.7】
在innodb只讀模式下innodb_force_recovery可以設置為4或更大值

1 (SRV_FORCE_IGNORE_CORRUPT)
當檢測到損壞的頁面時繼續讓服務器運行。 導出表時嘗試SELECT * FROM tbl_name跳過損壞的索引記錄和頁面。

2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程和任何廢止線程運行。 設置為2可以在廢止操作期間阻止崩潰。

3 (SRV_FORCE_NO_TRX_UNDO)
崩潰后恢復時不執行事務回滾

4 (SRV_FORCE_NO_IBUF_MERGE)
阻止寫入緩沖區合并操作。 如果會造成事故,不做寫入,不計算表統計。 此類型可能會永久損壞數據文件。 需要刪除并重新創建所有輔助索引。innoDB設置為只讀模式【Mysql 5.7】

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動數據庫時不查看undo日志:InnoDB會將不完整的事務視為已提交。 設置為此值可能會永久損壞數據文件。innoDB設置為只讀模式【Mysql 5.7】

6 (SRV_FORCE_NO_LOG_REDO)
無法將與恢復相關聯的重做日志恢復。設置此值可能會永久損壞數據文件。讓數據庫頁面處于過時狀態,從而可能會在B樹和其他數據庫結構中引入更多的損壞。innoDB設置為只讀模式【Mysql 5.7】

即使開啟了innodb_force_recovery設置也可以使用SELECT from tables導出表數據或者刪除、創建表。如果知道在回滾時會引起崩潰,可以直接刪除這個表。

【Mysql 5.7】
可以使用 SELECT from tables來導出表數據。innodb_force_recovery設置為3及以下時可以創建和刪除表。當然如果mysql版本低于5.7.18,innodb_force_recovery設置為3以上也是可以刪除表的,從5.7.18起被禁止了。

您還可以使用它來停止由大量導入失敗導致的失控回滾或ALTER TABLE操作:
殺掉mysql進程并將innodb_force_recovery設置為3,讓數據庫升級而不進行回滾,然后刪除導致失控回滾的表。

如果表數據中的損壞而導出不了,可以使用ORDER BY primary_key DESC子句的查詢將損壞部分后的數據導出來。

如果innodb_force_recovery必須要設置很大的值才能啟動innodb,這可能會導致復雜查詢(包含WHERE,ORDER BY或其他子句的查詢)失敗。這時候只能運行基本的SELECT * FROM t查詢。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,363評論 6 532
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,497評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,305評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,962評論 1 311
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,727評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,193評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,257評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,411評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,945評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,777評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,978評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,519評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,216評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,642評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,878評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,657評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,960評論 2 373

推薦閱讀更多精彩內容