Innodb 表修復(fù)

摘要：
突然收到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 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'

從錯(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í)行前滾的操作。

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

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

操作步驟：
因?yàn)楸黄茐牡牡胤街辉谒饕牟糠郑援?dāng)使用innodb_force_recovery = 1運(yùn)行InnoDB時(shí)，操作如下：

執(zhí)行check，repair table 都無(wú)效
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)

建立一張表：
create table email_status_bak   #和原表結(jié)構(gòu)一樣，只是把INNODB改成了MYISAM。

把數(shù)據(jù)導(dǎo)進(jìn)去:#寫(xiě)不進(jìn)去則需要把注釋掉innodb_force_recovery 之后，重啟
insert into email_status_bak select * from email_status;

刪除掉原表：
drop table email_status;

注釋掉innodb_force_recovery 之后，重啟。上面做了，這里就不需要了。
重命名：
rename table email_status_bak to email_status;

最后改回INNODB存儲(chǔ)引擎
alter table email_status engine = innodb

注意：
在MySQL 5.5可以修改 innodb_purge_threads 的版本中（5.1版本不能修改該參數(shù)），innodb_purge_threads 和 innodb_force_recovery一起設(shè)置會(huì)出現(xiàn)一種loop現(xiàn)象：

130510 18:13:23  InnoDB: Waiting for the background threads to start
130510 18:13:24  InnoDB: Waiting for the background threads to start
130510 18:13:25  InnoDB: Waiting for the background threads to start
130510 18:13:26  InnoDB: Waiting for the background threads to start
130510 18:13:27  InnoDB: Waiting for the background threads to start
130510 18:13:28  InnoDB: Waiting for the background threads to start
130510 18:13:29  InnoDB: Waiting for the background threads to start
130510 18:13:30  InnoDB: Waiting for the background threads to start
130510 18:13:31  InnoDB: Waiting for the background threads to start
130510 18:13:32  InnoDB: Waiting for the background threads to start
130510 18:13:33  InnoDB: Waiting for the background threads to start
…………
…………

數(shù)據(jù)庫(kù)無(wú)法啟動(dòng)，現(xiàn)象出現(xiàn)的條件是：mysql 版本 5.5
innodb_purge_threads =1，innodb_force_recovery >1 的情況（=1 沒(méi)有問(wèn)題），所以當(dāng)需要設(shè)置innodb_force_recovery>1的時(shí)候需要關(guān)閉 innodb_purge_threads，設(shè)置他=0（默認(rèn)）。

原因是：

mysql 原代碼的腳本：
  while (srv_shutdown_state == SRV_SHUTDOWN_NONE) { 
      if (srv_thread_has_reserved_slot(SRV_MASTER) == ULINT_UNDEFINED 
          || (srv_n_purge_threads == 1 
          && srv_thread_has_reserved_slot(SRV_WORKER) 
          == ULINT_UNDEFINED)) { 

          ut_print_timestamp(stderr); 
          fprintf(stderr, "  InnoDB: " 
              "Waiting for the background threads to " 
              "start\n"); 
          os_thread_sleep(1000000); 
      } else { 
          break; 
      } 
  }

總結(jié)：

這里的一個(gè)重要知識(shí)點(diǎn)就是對(duì) innodb_force_recovery 參數(shù)的理解了，要是遇到數(shù)據(jù)損壞甚至是其他的損壞?？赡苌厦娴姆椒ú恍辛?，需要嘗試另一個(gè)方法：insert into tb select * from ta limit X；甚至是dump出去，再load回來(lái)。更多的修復(fù)方法請(qǐng)看：
1: Recovering Innodb table Corruption
2:恢復(fù)損壞的InnoDB表格
3:MySQL Data Recovery

posted @ 2013-05-10 11:52 jyzhou 閱讀(6122) 評(píng)論(0) 收藏舉報(bào)

刷新頁(yè)面返回頂部

DBA's Record

Innodb 表修復(fù)

公告