MySQL資料庫INNODB表損壞修復處理過程分享

突然收到MySQL報警，從庫的資料庫掛了，一直在不停的重啟，開啟錯誤日誌，發現有張表壞了。innodb表損壞不能透過repair table 等修復myisam的命令操作。現在記錄下解決過程，下次遇到就不會這麼手忙腳亂了。

處理過程：
 一遇到報警之後，直接開啟錯誤日誌，裡面的資訊：

InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.130509 20:33:48 InnoDB: Page dump in ascii and hex (16384 bytes):##很多十六進位制的程式碼…………InnoDB: End of page dump130509 20:37:34 InnoDB: Page checksum 1958578898, prior-to-4.0.14-form checksum 3765017239InnoDB: stored checksum 3904709694, prior-to-4.0.14-form stored checksum 3765017239InnoDB: Page lsn 5 614270220, low 4 bytes of lsn at page end 614270220InnoDB: Page number (if stored to page already) 30506,InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 19InnoDB: Page may be an index page where index id is 54InnoDB: (index "PRIMARY" of table "maitem"."email_status")InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.InnoDB: It is also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: and rebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB: you can also try to fix the corruptionInnoDB: by dumping, dropping, and reimportingInnoDB: the corrupt table. You can use CHECKInnoDB: TABLE to scan your table for corruption.InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.InnoDB: A new raw disk partition was initialized orInnoDB: innodb_force_recovery is on: we do not allowInnoDB: database modifications by the user. Shut downInnoDB: mysqld and edit my.cnf so that newraw is replacedInnoDB: with raw, and innodb_force_... is removed.130509 20:39:35 [Warning] Invalid (old?) table or database name '#sql2-19c4-5'

從錯誤日誌裡面很清楚的知道哪裡出現了問題，該怎麼處理。這時候資料庫隔幾s就重啟，所以差不多可以說你是訪問不了資料庫的。所以馬上想到要修復innodb表了。
以前在Performance的blog上看過類似文章。

當時想到的是在修復之前保證資料庫正常，不是這麼異常的無休止的重啟。所以就修改了配置檔案的一個引數：innodb_force_recovery

innodb_force_recovery影響整個InnoDB儲存引擎的恢復狀況。預設為0，表示當需要恢復時執行所有的innodb_force_recovery可以設定為1-6,大的數字包含前面所有數字的影響。當設定引數值大於0後，可以對錶進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。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):不執行前滾的操作。

因為錯誤日誌裡面提示出現了壞頁，導致資料庫崩潰，所以這裡把innodb_force_recovery 設定為1，忽略檢查到的壞頁。重啟資料庫之後，正常了，沒有出現上面的錯誤資訊。找到錯誤資訊出現的表：
(index "PRIMARY" of table "maitem"."email_status")

資料頁面的主鍵索引(clustered key index)被損壞。這種情況和資料的二級索引(secondary indexes)被損壞相比要糟很多，因為後者可以透過使用OPTIMIZE TABLE命令來修復，但這和更難以恢復的表格目錄(table dictionary)被破壞的情況來說要好一些。

操作步驟：
因為被破壞的地方只在索引的部分，所以當使用innodb_force_recovery = 1執行InnoDB時，操作如下：

執行check，repair table 都無效alter table email_status engine =myisam; #也報錯了，因為模式是innodb_force_recovery =1。ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)

建立一張表：create table email_status_bak  #和原表結構一樣，只是把INNODB改成了MYISAM。把資料導進去insert into email_status_bak select * from email_status;刪除掉原表：drop table email_status;註釋掉innodb_force_recovery 之後，重啟。重新命名：rename table edm_email_status_bak to email_status;最後該回儲存引擎alter table edm_email_status engine = innodb

總結：
這裡的一個重要知識點就是 對 innodb_force_recovery 引數的理解了，要是遇到資料損壞甚至是其他的損壞。可能上面的方法不行了，需要嘗試另一個方法：insert into tb select * from ta limit X；甚至是dump出去，再load回來。