程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL數據庫INNODB表破壞修復處置進程分享

MySQL數據庫INNODB表破壞修復處置進程分享

編輯:MySQL綜合教程

MySQL數據庫INNODB表破壞修復處置進程分享。本站提示廣大學習愛好者:(MySQL數據庫INNODB表破壞修復處置進程分享)文章只能為提供參考,不一定能成為您想要的結果。以下是MySQL數據庫INNODB表破壞修復處置進程分享正文


忽然收到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。

把數據導出來
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

總結:
這裡的一個主要常識點就是 對 innodb_force_recovery 參數的懂得了,如果碰到數據破壞乃至是其他的破壞。能夠下面的辦法不可了,須要測驗考試另外一個辦法:insert into tb select * from ta limit X;乃至是dump出去,再load回來。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved