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

MySQL數據庫INNODB 表損壞修復過程

編輯:MySQL綜合教程

   突然收到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