突然收到MySQL報警，從庫的數（shù）據庫掛了，一（yī）直在不停的重啟，打開錯誤日誌，發現有張表壞了。innodb表損壞不能通過repair table 等修複myisam的命令操作。現在記錄下解（jiě）決（jué）過程，下次遇到就不會（huì）這麽手忙腳亂（luàn）了。

處理過程：
 一遇到報警之後，直接打開錯誤日誌，裏麵（miàn）的信（xìn）息：

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'

從錯誤日誌裏麵很清楚的知道（dào）哪裏（lǐ）出現了問題，該怎麽處理。這（zhè）時候數據庫隔幾s就重啟，所以差（chà）不多可以說你是訪問不了數據庫的。所以馬上想到要修複innodb表了。
以（yǐ）前在Performance的blog上看過類似文章。

當時想（xiǎng）到（dào）的是在修（xiū）複之前保證數據庫正常，不是這麽異常的無休止的重啟。所以就修改了配置文件的一個參（cān）數：innodb_force_recovery

innodb_force_recovery影響整個（gè）InnoDB存儲引擎（qíng）的恢複狀（zhuàng）況。默認為（wéi）0，表示（shì）當需要恢複時執行（háng）所有的innodb_force_recovery可以設置為1-6,大的數字包含前麵所有數字的影（yǐng）響。當（dāng）設置參數值大於0後（hòu），可以對（duì）表進行select,create,drop操作,但insert,update或者delete這類操作（zuò）是不允（yǔn）許的。1(SRV_FORCE_IGNORE_CORRUPT):忽（hū）略檢查（chá）到的corrupt頁（yè）。
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程（chéng）需要（yào）執行full purge操作，會導致（zhì）crash。
3(SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作。
4(SRV_FORCE_NO_IBUF_MERGE):不執行插入緩衝的合並操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日（rì）誌，InnoDB存儲引擎會將未提交的事務視為（wéi）已提（tí）交。
6(SRV_FORCE_NO_LOG_REDO):不執行前滾的操（cāo）作。

因為錯誤日誌裏麵提示出現了壞頁（yè），導致數（shù）據庫崩潰（kuì），所以這裏把（bǎ）innodb_force_recovery 設置為1，忽（hū）略檢查到的壞（huài）頁（yè）。重啟數據庫之後，正常了，沒有出（chū）現上麵的錯誤信息。找到錯誤信息出現的表：
(index "PRIMARY" of table "maitem"."email_status")

數據頁麵的主鍵索引(clustered key index)被損壞。這種情況和（hé）數據的二級索引(secondary indexes)被損（sǔn）壞相比要糟很多，因為後（hòu）者可以通過使用OPTIMIZE TABLE命令來修複，但這（zhè）和更難以恢複的表（biǎo）格目（mù）錄(table dictionary)被破壞的情況來說要好一些。

操作步驟：
因為被破壞（huài）的地方（fāng）隻在（zài）索引的部分，所以（yǐ）當使用innodb_force_recovery = 1運行InnoDB時，操作如（rú）下：

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

建（jiàn）立一張表：
create table email_status_bak   #和原表結構一樣，隻是把INNODB改（gǎi）成（chéng）了（le）MYISAM。把數據導進（jìn）去
insert into email_status_bak select * from email_status;刪（shān）除（chú）掉原表：
drop table email_status;注釋掉innodb_force_recovery 之後，重啟。
重命名：
rename table edm_email_status_bak to email_status;最後該回存儲（chǔ）引擎
alter table edm_email_status engine = innodb

總結：
這裏的一（yī）個重要知識點就是 對（duì） innodb_force_recovery 參數的理解（jiě）了，要是遇到數（shù）據損（sǔn）壞（huài）甚至是其他的損壞。可能上麵的方法不行了，需要嚐試另一個方法：insert into tb select * from ta limit X；甚至是dump出去（qù），再load回來。