工作中大家經常會用到存儲服務，比如mysql、mongo、redis等，有DBA的話還好，能幫我們管理維護，定期備份等，但是我們往往自己在開發工具平臺時自己來搞數據庫，就忽略了定時備份，留下了安全隱患。果不其然，最近收到了團隊小伙伴的求助，服務器掛了，重啟后mysql服務起不來了。關鍵是沒有備份！！

[[234959]]

經過一番折騰后將處理過程和踩的坑總結出來，供大家參考。MySQL crash 或者 MySQL 數據庫服務器 crash 會導致各種各樣的問題 ，比如日志損壞、數據文件損壞等等，本案例就是其中的一種，細心從日志中找的相關錯誤提示，逐步解決即可。首先在出現問題的A機器啟動mysql，看下情況。

查看mysql錯誤日志，找找原因

從日志內容分析來看,數據庫在機器crash 導致文件損壞,重啟之后無法正常恢復,更無法正常對外提供服務。這里采用非常規手段,首先修改innodb_force_recovery參數，使mysqld跳過恢復步驟，再將mysqld 啟動,把數據導出來，然后重新創建數據庫。

先來普及一下知識點：

[[234960]]

innodb_force_recovery可以設置為1-6,默認是0，大的數字包含前面所有數字的影響。

  1. (SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的損壞頁。

  2. (SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。

  3. (SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作。

  4. (SRV_FORCE_NO_IBUF_MERGE):不執行插入緩沖的合并操作。

  5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。

  6. (SRV_FORCE_NO_LOG_REDO):不執行前滾的操作。

注意當設置參數值大于0后，可以對表進行select,create,drop操作,但insert,update、 delete這類操作是不允許的。

將/etc/my.cnf下innodb_force_recovery值修改為4后，啟動mysql成功

馬上導出數據

/usr/local/mysql/bin/mysqldump -uroot -h localhost -P 3306  -p --default-character-set=latin1 --add-drop-database --lock-tables --single-transaction -q --triggers -A --result-file=/home/fuhaitao/3306.sql 

導出成功后找一臺B機器，在mysql實例里導入這個sql文件。

mysql -uroot -p -S /tmp/mysql3333.sock --default-character-set=latin1 < 3306.sql 

大功告成，馬上去看下數據是否正常

悲催。。。亂碼，查看mysql編碼方式

編碼是utf8，可是我在A機器導出的時候指定了字符集為latin1，所以修改編碼為Latin1看下

在查看下數據還是亂碼么

不行，說明導入的數據編碼與數據庫的編碼不一致，而且發現由于機器使用人員較多，每個數據庫編碼都不一致，有utf8的有latin1的，那么只能挨個庫來導了。

回到A機器將剛才是亂碼的database指定utf8編碼導出

將sql文件傳到B機器

在B機器上進行導入

執行后在查看下數據是否正常

歐耶，成功。再將A機器mysql停掉，修改/etc/my.cnf 里的innodb_force_recovery值改為0。經過一番折騰，終于把問題解決了，恢復了5年的數據。

[[234963]]

***給大家提幾點建議：

1. 如果公司有DBA團隊，盡量使用DBA團隊的存儲服務，他們能夠提供專業的支持。

2. 數據庫要做定時備份，避免特殊情況發生導致文件損壞，數據丟失。

3. 導入數據時要查看編碼方式，保證數據庫、數據文件、編輯器等編碼方式統一。