數據庫恢復不了？ 不存在的！
工作中大家經常會用到存儲服務，比如mysql、mongo、redis等，有DBA的話還好，能幫我們管理維護，定期備份等，但是我們往往自己在開發工具平臺時自己來搞數據庫，就忽略了定時備份，留下了安全隱患。果不其然，最近收到了團隊小伙伴的求助，服務器掛了，重啟后mysql服務起不來了。關鍵是沒有備份??！
經過一番折騰后將處理過程和踩的坑總結出來，供大家參考。MySQL crash 或者 MySQL 數據庫服務器 crash 會導致各種各樣的問題 ，比如日志損壞、數據文件損壞等等，本案例就是其中的一種，細心從日志中找的相關錯誤提示，逐步解決即可。首先在出現問題的A機器啟動mysql，看下情況。
查看mysql錯誤日志，找找原因
從日志內容分析來看,數據庫在機器crash 導致文件損壞,重啟之后無法正?；謴?更無法正常對外提供服務。這里采用非常規手段,首先修改innodb_force_recovery參數，使mysqld跳過恢復步驟，再將mysqld 啟動,把數據導出來，然后重新創建數據庫。
先來普及一下知識點：
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年的數據。
***給大家提幾點建議：
1. 如果公司有DBA團隊，盡量使用DBA團隊的存儲服務，他們能夠提供專業的支持。
2. 數據庫要做定時備份，避免特殊情況發生導致文件損壞，數據丟失。
3. 導入數據時要查看編碼方式，保證數據庫、數據文件、編輯器等編碼方式統一。
