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

處理過（guò）程（chéng）：
 一遇到報警之後，直接打開錯誤日誌，裏麵的（de）信息：

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):
##很（hěn）多十六進製（zhì）的代碼
……
……
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'

從（cóng）錯誤日（rì）誌裏麵（miàn）很（hěn）清（qīng）楚（chǔ）的知道哪裏（lǐ）出現了問題，該怎麽處理。這（zhè）時候數據庫隔（gé）幾s就重啟，所以差不多可以（yǐ）說你是訪問（wèn）不了數（shù）據庫的。所以馬上想到要修複innodb表了。
以（yǐ）前在Performance的blog上（shàng）看（kàn）過類似文章。

當時想到的是在修複之（zhī）前保證數據庫正常，不（bú）是這麽異常的無休止的重啟。所（suǒ）以就修改了（le）配置文件的一（yī）個參數：innodb_force_recovery

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

因為（wéi）錯誤日誌裏（lǐ）麵提示出現了壞頁，導致數據庫（kù）崩潰，所（suǒ）以這（zhè）裏把innodb_force_recovery 設置為1，忽略檢查到的壞頁。重啟數據庫（kù）之後，正常了，沒有出現上麵（miàn）的錯誤信息。找到錯誤信息出現（xiàn）的（de）表：
(index "PRIMARY" of table "maitem"."email_status")

數據頁（yè）麵的主鍵索（suǒ）引(clustered key index)被（bèi）損壞。這種（zhǒng）情況和數據的二級索（suǒ）引(secondary indexes)被損（sǔn）壞相比（bǐ）要糟很多，因為後者可以通過使用OPTIMIZE TABLE命（mìng）令來（lái）修複，但（dàn）這和更難以恢複的表格目錄（lù）(table dictionary)被（bèi）破壞的情況來說要好一些。

操作（zuò）步驟：
因為被破壞的地方隻在索引的部（bù）分，所（suǒ）以當使（shǐ）用innodb_force_recovery = 1運行InnoDB時，操作如（rú）下：

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

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

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