問題故障：Mysql資料庫意外崩潰，一直無法啟動資料庫。報錯日誌： 啟動報錯：service mysqld restartERROR! MySQL server PID file could not be found!Starting MySQL. ERROR! The server quit wi ...
問題故障：
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
希望能幫到你
