《Mysql入門MySQL數(shù)據(jù)庫INNODB表損壞修復(fù)處理過程分享》要點(diǎn)：
本文介紹了Mysql入門MySQL數(shù)據(jù)庫INNODB表損壞修復(fù)處理過程分享，希望對您有用。如果有疑問，可以聯(lián)系我們。

MYSQL學(xué)習(xí)突然收到MySQL報(bào)警,從庫的數(shù)據(jù)庫掛了,一直在不停的重啟,打開錯(cuò)誤日志,發(fā)現(xiàn)有張表壞了.innodb表損壞不能通過repair table 等修復(fù)myisam的命令操作.現(xiàn)在記錄下解決過程,下次遇到就不會這么手忙腳亂了.

MYSQL學(xué)習(xí)處理過程：
?一遇到報(bào)警之后,直接打開錯(cuò)誤日志,里面的信息：

MYSQL學(xué)習(xí)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):
##很多十六進(jìn)制的代碼
……
……
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'

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

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

MYSQL學(xué)習(xí)innodb_force_recovery影響整個(gè)InnoDB存儲引擎的恢復(fù)狀況.默認(rèn)為0,表示當(dāng)需要恢復(fù)時(shí)執(zhí)行所有的
innodb_force_recovery可以設(shè)置為1-6,大的數(shù)字包含前面所有數(shù)字的影響.當(dāng)設(shè)置參數(shù)值大于0后,可以對表進(jìn)行select,create,drop操作,但insert,update或者delete這類操作是不允許的.
1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁.
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運(yùn)行,如主線程需要執(zhí)行full purge操作,會導(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存儲引擎會將未提交的事務(wù)視為已提交.
6(SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作.

MYSQL學(xué)習(xí)因?yàn)殄e(cuò)誤日志里面提示出現(xiàn)了壞頁,導(dǎo)致數(shù)據(jù)庫崩潰,所以這里把innodb_force_recovery 設(shè)置為1,忽略檢查到的壞頁.重啟數(shù)據(jù)庫之后,正常了,沒有出現(xiàn)上面的錯(cuò)誤信息.找到錯(cuò)誤信息出現(xiàn)的表：
(index?"PRIMARY"?of table?"maitem"."email_status")

MYSQL學(xué)習(xí)數(shù)據(jù)頁面的主鍵索引(clustered key index)被損壞.這種情況和數(shù)據(jù)的二級索引(secondary indexes)被損壞相比要糟很多,因?yàn)楹笳呖梢酝ㄟ^使用OPTIMIZE TABLE命令來修復(fù),但這和更難以恢復(fù)的表格目錄(table dictionary)被破壞的情況來說要好一些.

MYSQL學(xué)習(xí)操作步驟：
因?yàn)楸黄茐牡牡胤街辉谒饕牟糠?所以當(dāng)使用innodb_force_recovery = 1運(yùn)行InnoDB時(shí),操作如下：

MYSQL學(xué)習(xí)執(zhí)行check,repair table 都無效
alter table email_status engine =myisam; #也報(bào)錯(cuò)了,因?yàn)槟Ｊ绞莍nnodb_force_recovery =1.
ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)

MYSQL學(xué)習(xí)建立一張表：
create table email_status_bak  #和原表結(jié)構(gòu)一樣,只是把INNODB改成了MYISAM.
把數(shù)據(jù)導(dǎo)進(jìn)去
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

MYSQL學(xué)習(xí)總結(jié)：
這里的一個(gè)重要知識點(diǎn)就是 對?innodb_force_recovery?參數(shù)的理解了,要是遇到數(shù)據(jù)損壞甚至是其他的損壞.可能上面的方法不行了,需要嘗試另一個(gè)方法：insert into tb select * from ta limit X；甚至是dump出去,再load回來.

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/1147.html