摘要：
突然收到MySQL報警，從庫的數據庫掛了，一直在不停的重啟，打開錯誤日志，發現有張表壞了。innodb表損壞不能通過repair table 等修復myisam的命令操作。現在記錄下解決過程，下次遇到就不會這么手忙腳亂了。
處理過程：
一遇到報警之后，直接打開錯誤日志，里面的信息：
InnoDB: Database page corruption on disk or a failed InnoDB: 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 dump 130509 20:37:34 InnoDB: Page checksum 1958578898, prior-to-4.0.14-form checksum 3765017239 InnoDB: stored checksum 3904709694, prior-to-4.0.14-form stored checksum 3765017239 InnoDB: Page lsn 5 614270220, low 4 bytes of lsn at page end 614270220 InnoDB: Page number (if stored to page already) 30506, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 19 InnoDB: Page may be an index page where index id is 54 InnoDB: (index "PRIMARY" of table "maitem"."email_status") InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 30506. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. InnoDB: A new raw disk partition was initialized or InnoDB: innodb_force_recovery is on: we do not allow InnoDB: database modifications by the user. Shut down InnoDB: mysqld and edit my.cnf so that newraw is replaced InnoDB: 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。 把數據導進去:#寫不進去則需要把注釋掉innodb_force_recovery 之后，重啟 insert into email_status_bak select * from email_status; 刪除掉原表： drop table email_status;
注釋掉innodb_force_recovery 之后，重啟。上面做了，這里就不需要了。 重命名： rename table email_status_bak to email_status;
最后改回INNODB存儲引擎 alter table email_status engine = innodb
注意：
在MySQL 5.5可以修改 innodb_purge_threads 的版本中（5.1版本不能修改該參數），innodb_purge_threads 和 innodb_force_recovery一起設置會出現一種loop現象：
130510 18:13:23 InnoDB: Waiting for the background threads to start 130510 18:13:24 InnoDB: Waiting for the background threads to start 130510 18:13:25 InnoDB: Waiting for the background threads to start 130510 18:13:26 InnoDB: Waiting for the background threads to start 130510 18:13:27 InnoDB: Waiting for the background threads to start 130510 18:13:28 InnoDB: Waiting for the background threads to start 130510 18:13:29 InnoDB: Waiting for the background threads to start 130510 18:13:30 InnoDB: Waiting for the background threads to start 130510 18:13:31 InnoDB: Waiting for the background threads to start 130510 18:13:32 InnoDB: Waiting for the background threads to start 130510 18:13:33 InnoDB: Waiting for the background threads to start ………… …………
數據庫無法啟動，現象出現的條件是：mysql 版本 5.5
innodb_purge_threads =1，innodb_force_recovery >1 的情況（=1 沒有問題），所以當需要設置innodb_force_recovery>1的時候需要關閉 innodb_purge_threads，設置他=0（默認）。
原因是：
mysql 原代碼的腳本： 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 參數的理解了，要是遇到數據損壞甚至是其他的損壞。可能上面的方法不行了，需要嘗試另一個方法：insert into tb select * from ta limit X；甚至是dump出去，再load回來。更多的修復方法請看 ：
1: Recovering Innodb table Corruption
2:恢復損壞的InnoDB表格
3:MySQL Data Recovery