|
問題故障：
Mysql數(shù)據(jù)庫意外崩潰，一直無法啟動數(shù)據(jù)庫,。
報錯日志：
啟動報錯：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).
數(shù)據(jù)庫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
提示：數(shù)據(jù)庫啟動時讀取表空間信息時,，ob-wp庫中的表ob_users.ibd表數(shù)據(jù)文件已存在于表空間中。
拓展：
存儲引擎是myisam, 在數(shù)據(jù)庫目錄下會看到3類文件：.frm,、.myi,、.myd
(a) *.frm--表定義，是描述表結(jié)構(gòu)的文件,。
(b) *.MYD--"D"數(shù)據(jù)信息文件,，是表的數(shù)據(jù)文件。
(c) *.MYI--"I"索引信息文件,，是表數(shù)據(jù)文件中任何索引的數(shù)據(jù)樹
存儲引擎是InnoDB, 在data目錄下會看到2類文件：.frm,、.ibd
(a) *.frm--表結(jié)構(gòu)的文件。
(b) *.ibd--表數(shù)據(jù)文件
出處：https://www.cnblogs.com/liucx/
方法一：
根據(jù)提示信息判定該InnoDB表損壞,，于是嘗試將dev_nss庫目錄中的表結(jié)構(gòu)和表數(shù)據(jù)文件備份
mv ob_termmeta.ibd ob_termmeta.ibd,bak
mv ob_termmeta.frm ob_termmeta.frm.bak
然后重啟了下mysql,，發(fā)現(xiàn)還是無法啟動，提示其他表數(shù)據(jù)文件已存在,，連續(xù)3次將已損壞的文件備份,，還是無法啟動。故放棄此方法,。
方法二：
1.查閱官網(wǎng)文檔,，在mysql配置文件中/etc/my.cnf添加配置，成功啟動
[mysqld]
innodb_force_recovery = 1
2.備份數(shù)據(jù)庫
mysqldump -h172.168.2.100 -uroot -p -A > mysql_all_bak.sql
如遇報表不存在，mysqldump可以添加參數(shù)：--force ,，跳過錯誤
3.刪除數(shù)據(jù)庫
drop database hxdb; 或者將數(shù)據(jù)庫數(shù)據(jù)庫目錄 mv hxdb hxdb_bak （保險）
4.去掉參數(shù) innodb_force_recovery
將之前設(shè)置的參數(shù)去掉后,，重新啟動數(shù)據(jù)庫
5.導(dǎo)入數(shù)據(jù)
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
如果提示表已經(jīng)存在，這是因為將innodb_force_recovery參數(shù)去掉后,，數(shù)據(jù)庫會進行回滾操作,，會生成相應(yīng)的ibd文件，所以需要將該文件刪除掉,，刪除后重新導(dǎo)入
mysql -uroot -p < mysql_all_bak.sql
注：
innodb_force_recovery參數(shù)解釋：崩潰恢復(fù)模式,，通常只有在嚴重故障排除情況下才會改變?？梢缘闹凳菑?到6,。
只有在緊急情況下才將這個變量設(shè)置為大于0的值，這樣你才能啟動InnoDB并轉(zhuǎn)儲你的表,。作為一種安全措施,，當innodb_force_recovery大于0時，InnoDB可以防止插入,、更新或刪除操作,。
在5.6.15,innodb_force_recovery設(shè)置為4或更大，將InnoDB設(shè)置為只讀模式,。由于relay_log_info_repository=TABLE和master_info_repository=TABLE在InnoDB表中存儲信息,，這些限制可能導(dǎo)致復(fù)制管理命令失敗并出現(xiàn)錯誤。
innodb_force_recovery默認情況下為0（正常啟動而不強制恢復(fù)）,。允許的非零值 innodb_force_recovery是1到6,。較大的值包括較小值的功能。例如,，值3包含值1和2的所有功能,。
如果能夠轉(zhuǎn)儲 innodb_force_recovery值為3或更小的表，則相對安全的是,，僅丟失損壞的單個頁面上的某些數(shù)據(jù),。4或更大的值被認為是危險的，因為數(shù)據(jù)文件可能會永久損壞,。值6被認為是過分的,，因為數(shù)據(jù)庫頁面處于過時狀態(tài)，這反過來可能會使B樹 和其他數(shù)據(jù)庫結(jié)構(gòu)遭受更多破壞,。
為了安全起見,，請InnoDB防止 INSERT， UPDATE或 DELETE在innodb_force_recovery大于0 時進行操作 ,。從MySQL 5.6.15開始,， 在只讀模式下innodb_force_recovery設(shè)置4個或更多位置InnoDB,。
1 (SRV_FORCE_IGNORE_CORRUPT)
讓服務(wù)器運行，即使它檢測到一個損壞的頁面,。嘗試讓SELECT * FROM tbl_name跳過損壞的索引記錄和頁面,，這有助于轉(zhuǎn)儲表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程和任何清除線程運行,。如果在清除操作期間發(fā)生崩潰,，則此恢復(fù)值將防止崩潰,。
3 (SRV_FORCE_NO_TRX_UNDO)
在崩潰恢復(fù)后不運行事務(wù)回滾,。
4 (SRV_FORCE_NO_IBUF_MERGE)
防止插入緩沖區(qū)合并操作。如果它們會導(dǎo)致崩潰,，就不要做,。不計算表統(tǒng)計信息。此值可能永久損壞數(shù)據(jù)文件,。使用此值后,，準備刪除并重新創(chuàng)建所有二級索引。在MySQL 5.6.15中,，將InnoDB設(shè)置為只讀,。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動數(shù)據(jù)庫時不要查看撤銷日志:InnoDB甚至?xí)⑽赐瓿傻氖聞?wù)視為已提交。此值可能永久損壞數(shù)據(jù)文件,。在MySQL 5.6.15中,，將InnoDB設(shè)置為只讀。
6 (SRV_FORCE_NO_LOG_REDO)
在恢復(fù)時不執(zhí)行重做日志前滾,。此值可能永久損壞數(shù)據(jù)文件,。使數(shù)據(jù)庫頁面處于過時狀態(tài)，這反過來可能會給b -樹和其他數(shù)據(jù)庫結(jié)構(gòu)帶來更多損壞,。在MySQL 5.6.15中,，將InnoDB設(shè)置為只讀。
出處：https://www.cnblogs.com/liucx/
參閱官網(wǎng)：
https://dev./doc/refman/5.6/en/forcing-innodb-recovery.html
https://dev./doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_force_load_corrupted
希望能幫到你
|
