Mysql資料庫意外崩潰導致表資料檔案損壞無法啟動的問題解決

問題故障：
Mysql資料庫意外崩潰，一直無法啟動資料庫，
報錯日志：

啟動報錯：service mysqld restart
ERROR! MySQL server PID file could not be found!
Starting MySQL. ERROR! The server quit without updating PID file (/www/wdlinux/mysql/var/iZ2358oz5deZ.pid).

資料庫error日志:
200719 22:07:43 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: trying to add tablespace 840 of name './ob_wp/ob_termmeta.ibd'
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 840 of name './dev_nss/dg_queue.ibd' already exists in the tablespace
InnoDB: memory cache!
200719 22:07:43 mysqld_safe mysqld from pid file /www/wdlinux/mysql/var/iZ2358oz5deZ.pid ended

提示：資料庫啟動時讀取表空間資訊時，ob-wp庫中的表ob_users.ibd表資料檔案已存在于表空間中，

拓展：
存盤引擎是myisam, 在資料庫目錄下會看到3類檔案：.frm、.myi、.myd
      (a) *.frm--表定義，是描述表結構的檔案，
      (b) *.MYD--"D"資料資訊檔案，是表的資料檔案，
      (c) *.MYI--"I"索引資訊檔案，是表資料檔案中任何索引的資料樹
存盤引擎是InnoDB, 在data目錄下會看到2類檔案：.frm、.ibd
     (a) *.frm--表結構的檔案，
     (b) *.ibd--表資料檔案

出處：https://www.cnblogs.com/liucx/

方法一：
根據提示資訊判定該InnoDB表損壞，于是嘗試將dev_nss庫目錄中的表結構和表資料檔案備份
mv ob_termmeta.ibd ob_termmeta.ibd,bak
mv ob_termmeta.frm ob_termmeta.frm.bak
然后重啟了下mysql，發現還是無法啟動，提示其他表資料檔案已存在，連續3次將已損壞的檔案備份，還是無法啟動，故放棄此方法，

方法二：
1.查閱官網檔案，在mysql組態檔中/etc/my.cnf添加配置，成功啟動
[mysqld]
innodb_force_recovery = 1

2.備份資料庫
mysqldump -h172.168.2.100 -uroot -p -A > mysql_all_bak.sql
如遇報表不存在，mysqldump可以添加引數：--force ，跳過錯誤

3.洗掉資料庫
drop database hxdb; 或者將資料庫資料庫目錄 mv hxdb hxdb_bak （保險）

4.去掉引數 innodb_force_recovery
將之前設定的引數去掉后，重新啟動資料庫

5.匯入資料
mysql -uroot -p < mysql_all_bak.sql
Warning: Using a password on the command line interface can be insecure.
ERROR 1050 (42S01) at line 25: Table '`hxdb`.`tb_info`' already exists

如果提示表已經存在，這是因為將innodb_force_recovery引數去掉后，資料庫會進行回滾操作，會生成相應的ibd檔案，所以需要將該檔案洗掉掉，洗掉后重新匯入
mysql -uroot -p < mysql_all_bak.sql

注：
innodb_force_recovery引數解釋：崩潰恢復模式，通常只有在嚴重故障排除情況下才會改變，可以的值是從0到6，

只有在緊急情況下才將這個變數設定為大于0的值，這樣你才能啟動InnoDB并轉儲你的表，作為一種安全措施，當innodb_force_recovery大于0時，InnoDB可以防止插入、更新或洗掉操作，
在5.6.15,innodb_force_recovery設定為4或更大，將InnoDB設定為只讀模式，由于relay_log_info_repository=TABLE和master_info_repository=TABLE在InnoDB表中存盤資訊，這些限制可能導致復制管理命令失敗并出現錯誤，

innodb_force_recovery默認情況下為0（正常啟動而不強制恢復），允許的非零值 innodb_force_recovery是1到6，較大的值包括較小值的功能，例如，值3包含值1和2的所有功能，
如果能夠轉儲 innodb_force_recovery值為3或更小的表，則相對安全的是，僅丟失損壞的單個頁面上的某些資料，4或更大的值被認為是危險的，因為資料檔案可能會永久損壞，值6被認為是過分的，因為資料庫頁面處于過時狀態，這反過來可能會使B樹 和其他資料庫結構遭受更多破壞，

為了安全起見，請InnoDB防止 INSERT， UPDATE或 DELETE在innodb_force_recovery大于0 時進行操作 ，從MySQL 5.6.15開始， 在只讀模式下innodb_force_recovery設定4個或更多位置InnoDB，
1 (SRV_FORCE_IGNORE_CORRUPT)
讓服務器運行，即使它檢測到一個損壞的頁面，嘗試讓SELECT * FROM tbl_name跳過損壞的索引記錄和頁面，這有助于轉儲表，
2 (SRV_FORCE_NO_BACKGROUND)
阻止主執行緒和任何清除執行緒運行，如果在清除操作期間發生崩潰，則此恢復值將防止崩潰，
3 (SRV_FORCE_NO_TRX_UNDO)
在崩潰恢復后不運行事務回滾，
4 (SRV_FORCE_NO_IBUF_MERGE)
防止插入緩沖區合并操作，如果它們會導致崩潰，就不要做，不計算表統計資訊，此值可能永久損壞資料檔案，使用此值后，準備洗掉并重新創建所有二級索引，在MySQL 5.6.15中，將InnoDB設定為只讀，
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動資料庫時不要查看撤銷日志:InnoDB甚至會將未完成的事務視為已提交，此值可能永久損壞資料檔案，在MySQL 5.6.15中，將InnoDB設定為只讀，
6 (SRV_FORCE_NO_LOG_REDO)
在恢復時不執行重做日志前滾，此值可能永久損壞資料檔案，使資料庫頁面處于過時狀態，這反過來可能會給b -樹和其他資料庫結構帶來更多損壞，在MySQL 5.6.15中，將InnoDB設定為只讀，

出處：https://www.cnblogs.com/liucx/

參閱官網：
https://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_force_load_corrupted

希望能幫到你

標籤：MySQL

上一篇：MySQL多表查詢

下一篇：MySQL