MYSQL數(shù)據(jù)表損壞的原因分析和修復(fù)方法小結(jié)(轉(zhuǎn)載)

1.表損壞的原因分析 以下原因是導(dǎo)致mysql 表毀壞的常見原因： 1、 服務(wù)器突然斷電導(dǎo)致數(shù)據(jù)文件損壞。 2、 強(qiáng)制關(guān)機(jī)，沒有先關(guān)閉mysql 服務(wù)。 3、 mysqld 進(jìn)程在寫表時(shí)被殺掉。 4、 使用myisamchk 的同時(shí)，mysqld 也在操作表。 5、 磁盤故障。 6、 服務(wù)器死機(jī)

1.表損壞的原因分析
以下原因是導(dǎo)致mysql 表毀壞的常見原因：
1、 服務(wù)器突然斷電導(dǎo)致數(shù)據(jù)文件損壞。
2、 強(qiáng)制關(guān)機(jī)，沒有先關(guān)閉mysql 服務(wù)。
3、 mysqld 進(jìn)程在寫表時(shí)被殺掉。
4、 使用myisamchk 的同時(shí)，mysqld 也在操作表。
5、 磁盤故障。
6、 服務(wù)器死機(jī)。
7、 mysql 本身的bug 。

2.表損壞的癥狀
一個(gè)損壞的表的典型癥狀如下：
1 、當(dāng)在從表中選擇數(shù)據(jù)之時(shí)，你得到如下錯(cuò)誤：
Incorrect key file for table: ‘…’. Try to repair it
2 、查詢不能在表中找到行或返回不完全的數(shù)據(jù)。
3 、Error: Table ‘p’ is marked as crashed and should be repaired 。
4 、打開表失敗： Can’t open file: ‘×××.MYI’ (errno: 145) 。
5 、
3.預(yù)防 MySQL 表損壞
可以采用以下手段預(yù)防m(xù)ysql 表損壞：
1 、定期使用myisamchk 檢查MyISAM 表（注意要關(guān)閉mysqld ），推薦使用check table 來檢查表（不用關(guān)閉mysqld ）。
2 、在做過大量的更新或刪除操作后，推薦使用OPTIMIZE TABLE 來優(yōu)化表，這樣既減少了文件碎片，又減少了表損壞的概率。
3 、關(guān)閉服務(wù)器前，先關(guān)閉mysqld （正常關(guān)閉服務(wù)，不要使用kill -9 來殺進(jìn)程）。
4 、使用ups 電源，避免出現(xiàn)突然斷電的情況。
5 、使用最新的穩(wěn)定發(fā)布版mysql ，減少mysql 本身的bug 導(dǎo)致表損壞。
6 、對(duì)于InnoDB 引擎，你可以使用innodb_tablespace_monitor 來檢查表空間文件內(nèi)文件空間管理的完整性。
7 、對(duì)磁盤做raid ，減少磁盤出錯(cuò)并提高性能。
8 、數(shù)據(jù)庫服務(wù)器最好只跑mysqld 和必要的其他服務(wù)，不要跑其他業(yè)務(wù)服務(wù)，這樣減少死機(jī)導(dǎo)致表損壞的可能。
9 、不怕萬一，只怕意外，平時(shí)做好備份是預(yù)防表損壞的有效手段。
4.MySQL 表損壞的修復(fù)
MyISAM 表可以采用以下步驟進(jìn)行修復(fù) ：
1、 使用 reapair table 或myisamchk 來修復(fù)。
2、 如果上面的方法修復(fù)無效，采用備份恢復(fù)表。
具體可以參考如下做法：
階段1 ：檢查你的表
如果你有很多時(shí)間，運(yùn)行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）選項(xiàng)禁止不必要的信息。
如果mysqld 服務(wù)器處于宕機(jī)狀態(tài)，應(yīng)使用–update-state 選項(xiàng)來告訴myisamchk 將表標(biāo)記為’ 檢查過的’ 。
你必須只修復(fù)那些myisamchk 報(bào)告有錯(cuò)誤的表。對(duì)這樣的表，繼續(xù)到階段2 。
如果在檢查時(shí)，你得到奇怪的錯(cuò)誤( 例如out of memory 錯(cuò)誤) ，或如果myisamchk 崩潰，到階段3 。
階段2 ：簡單安全的修復(fù)
注釋：如果想更快地進(jìn)行修復(fù)，當(dāng)運(yùn)行myisamchk 時(shí)，你應(yīng)將sort_buffer_size 和Key_buffer_size 變量的值設(shè)置為可用內(nèi)存的大約25% 。
首先，試試myisamchk -r -q tbl_name(-r -q 意味著“ 快速恢復(fù)模式”) 。這將試圖不接觸數(shù)據(jù)文件來修復(fù)索引文件。如果數(shù)據(jù)文件包含它應(yīng)有的一切內(nèi)容和指向數(shù)據(jù)文件內(nèi)正確地點(diǎn)的刪除連接，這應(yīng)該管用并且表可被修復(fù)。開始修復(fù)下一張表。否則，執(zhí)行下列過程：
在繼續(xù)前對(duì)數(shù)據(jù)文件進(jìn)行備份。
使用myisamchk -r tbl_name(-r 意味著“ 恢復(fù)模式”) 。這將從數(shù)據(jù)文件中刪除不正確的記錄和已被刪除的記錄并重建索引文件。
如果前面的步驟失敗，使用myisamchk –safe-recover tbl_name 。安全恢復(fù)模式使用一個(gè)老的恢復(fù)方法，處理常規(guī)恢復(fù)模式不行的少數(shù)情況( 但是更慢) 。
如果在修復(fù)時(shí)，你得到奇怪的錯(cuò)誤( 例如out of memory 錯(cuò)誤) ，或如果myisamchk 崩潰，到階段3 。
階段3 ：困難的修復(fù)
只有在索引文件的第一個(gè)16K 塊被破壞，或包含不正確的信息，或如果索引文件丟失，你才應(yīng)該到這個(gè)階段。在這種情況下，需要?jiǎng)?chuàng)建一個(gè)新的索引文件。按如下步驟操做：
把數(shù)據(jù)文件移到安全的地方。
使用表描述文件創(chuàng)建新的( 空) 數(shù)據(jù)文件和索引文件：

shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit

如果你的MySQL 版本沒有TRUNCATE TABLE ，則使用DELETE FROM tbl_name 。
將老的數(shù)據(jù)文件拷貝到新創(chuàng)建的數(shù)據(jù)文件之中。（不要只是將老文件移回新文件之中；你要保留一個(gè)副本以防某些東西出錯(cuò)。）
回到階段2 。現(xiàn)在myisamchk -r -q 應(yīng)該工作了。（這不應(yīng)該是一個(gè)無限循環(huán)）。
你還可以使用REPAIR TABLE tbl_name USE_FRM ，將自動(dòng)執(zhí)行整個(gè)程序。
階段4 ：非常困難的修復(fù)
只有.frm 描述文件也破壞了，你才應(yīng)該到達(dá)這個(gè)階段。這應(yīng)該從未發(fā)生過，因?yàn)樵诒肀粍?chuàng)建以后，描述文件就不再改變了。
從一個(gè)備份恢復(fù)描述文件然后回到階段3 。你也可以恢復(fù)索引文件然后回到階段2 。對(duì)后者，你應(yīng)該用myisamchk -r 啟動(dòng)。
如果你沒有進(jìn)行備份但是確切地知道表是怎樣創(chuàng)建的，在另一個(gè)數(shù)據(jù)庫中創(chuàng)建表的一個(gè)拷貝。刪除新的數(shù)據(jù)文件，然后從其他數(shù)據(jù)庫將描述文件和索引文件移到破壞的數(shù)據(jù)庫中。這樣提供了新的描述和索引文件，但是讓.MYD 數(shù)據(jù)文件獨(dú)自留下來了。回到階段2 并且嘗試重建索引文件。
InnoDB 表可以采用下面的方法修復(fù)：
如果數(shù)據(jù)庫頁被破壞，你可能想要用SELECT INTO OUTFILE 從從數(shù)據(jù)庫轉(zhuǎn)儲(chǔ)你的表，通常以這種方法獲取的大多數(shù)數(shù)據(jù)是完好的。即使這樣，損壞可能導(dǎo)致SELECT * FROM tbl_name 或者InnoDB 后臺(tái)操作崩潰或斷言，或者甚至使得InnoDB 前滾恢復(fù)崩潰。 盡管如此，你可以用它來強(qiáng)制InnoDB 存儲(chǔ)引擎啟動(dòng)同時(shí)阻止后臺(tái)操作運(yùn)行，以便你能轉(zhuǎn)儲(chǔ)你的表。例如：你可以在重啟服務(wù)器之前，在選項(xiàng)文件的[mysqld] 節(jié)添加如下的行：
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允許的非零值如下。一個(gè)更大的數(shù)字包含所有更小數(shù)字的預(yù)防措施。如果你能夠用一個(gè)多數(shù)是4 的選項(xiàng)值來轉(zhuǎn)儲(chǔ)你的表，那么你是比較安全的，只有一些在損壞的單獨(dú)頁面上的數(shù)據(jù)會(huì)丟失。一個(gè)為6 的值更夸張，因?yàn)閿?shù)據(jù)庫頁被留在一個(gè)陳舊的狀態(tài)，這個(gè)狀態(tài)反過來可以引發(fā)對(duì)B 樹和其它數(shù)據(jù)庫結(jié)構(gòu)的更多破壞。
1 (SRV_FORCE_IGNORE_CORRUPT)
即使服務(wù)器檢測(cè)到一個(gè)損壞的頁，也讓服務(wù)器運(yùn)行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助于轉(zhuǎn)儲(chǔ)表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程運(yùn)行，如果崩潰可能在凈化操作過程中發(fā)生，這將阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢復(fù)后不運(yùn)行事務(wù)回滾。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入緩沖合并操作。如果你可能會(huì)導(dǎo)致一個(gè)崩潰。最好不要做這些操作，不要計(jì)算表統(tǒng)計(jì)表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動(dòng)數(shù)據(jù)庫之時(shí)不查看未完成日志：InnoDB 把未完成的事務(wù)視為已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢復(fù)連接中做日志前滾。
數(shù)據(jù)庫不能另外地帶著這些選項(xiàng)中被允許的選項(xiàng)來使用。作為一個(gè)安全措施，當(dāng)innodb_force_recovery 被設(shè)置為大于0 的值時(shí)，InnoDB 阻止用戶執(zhí)行INSERT, UPDATE 或DELETE 操作.
即使強(qiáng)制恢復(fù)被使用，你也可以DROP 或CREATE 表。如果你知道一個(gè)給定的表正在導(dǎo)致回滾崩潰，你可以移除它。你也可以用這個(gè)來停止由失敗的大宗導(dǎo)入或失敗的ALTER TABLE 導(dǎo)致的失控回滾。你可以殺掉mysqld 進(jìn)程，然后設(shè)置innodb_force_recovery 為3 ，使得數(shù)據(jù)庫被掛起而不需要回滾，然后舍棄導(dǎo)致失控回滾的表。

原文地址：MYSQL數(shù)據(jù)表損壞的原因分析和修復(fù)方法小結(jié)(轉(zhuǎn)載), 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com