突然收到MySQL報(bào)警，從庫(kù)的數(shù)據(jù)庫(kù)掛了，一直在不停的重啟，打開(kāi)錯(cuò)誤日志，發(fā)現(xiàn)有張表壞了。innodb表?yè)p壞不能通過(guò)repair table 等修復(fù)myisam的命令操作。現(xiàn)在記錄下解決過(guò)程，下次遇到就不會(huì)這么手忙腳亂了。

處理過(guò)程：
 一遇到報(bào)警之后，直接打開(kāi)錯(cuò)誤日志，里面的信息：

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):##很多十六進(jìn)制的代碼…………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'

從錯(cuò)誤日志里面很清楚的知道哪里出現(xiàn)了問(wèn)題，該怎么處理。這時(shí)候數(shù)據(jù)庫(kù)隔幾s就重啟，所以差不多可以說(shuō)你是訪問(wèn)不了數(shù)據(jù)庫(kù)的。所以馬上想到要修復(fù)innodb表了。
以前在Performance的blog上看過(guò)類似文章。

當(dāng)時(shí)想到的是在修復(fù)之前保證數(shù)據(jù)庫(kù)正常，不是這么異常的無(wú)休止的重啟。所以就修改了配置文件的一個(gè)參數(shù)：innodb_force_recovery

innodb_force_recovery影響整個(gè)InnoDB存儲(chǔ)引擎的恢復(fù)狀況。默認(rèn)為0，表示當(dāng)需要恢復(fù)時(shí)執(zhí)行所有的innodb_force_recovery可以設(shè)置為1-6,大的數(shù)字包含前面所有數(shù)字的影響。當(dāng)設(shè)置參數(shù)值大于0后，可以對(duì)表進(jìn)行select,create,drop操作,但insert,update或者delete這類操作是不允許的。1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁(yè)。2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運(yùn)行，如主線程需要執(zhí)行full purge操作，會(huì)導(dǎo)致crash。3(SRV_FORCE_NO_TRX_UNDO):不執(zhí)行事務(wù)回滾操作。4(SRV_FORCE_NO_IBUF_MERGE):不執(zhí)行插入緩沖的合并操作。5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲(chǔ)引擎會(huì)將未提交的事務(wù)視為已提交。6(SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作。