一、 前言

2018年5月28日，北京晴有輕度沙塵暴。 坐上公交車(chē)走在上班的路上，想起老羅經(jīng)常說(shuō)起的一句話(huà)：想成盛田昭夫時(shí)代的索尼，想成喬布斯時(shí)代的蘋(píng)果，于是繼續(xù)研讀著 《日本制造：盛田昭夫的日式經(jīng)營(yíng)學(xué)》。

到了人大西門(mén)在西區(qū)食堂吃了個(gè)早餐，穿過(guò)人民大學(xué)很快就來(lái)到了公司。坐在工位上打開(kāi)電腦登上QQ，不一會(huì)運(yùn)營(yíng)的CC的頭像就開(kāi)始閃動(dòng)，“mooc平臺(tái)登錄不了”，“你看看”。又一會(huì)領(lǐng)導(dǎo)的頭像開(kāi)始閃動(dòng)，“xxx說(shuō)慕課平臺(tái)不能登錄了”。 額… 這事都驚動(dòng)領(lǐng)導(dǎo)了？

二、 排查問(wèn)題

打開(kāi)chrome瀏覽器開(kāi)始預(yù)覽，等了好久代理服務(wù)器才反饋。

Time out！ 

使用 SecureCRT 連接了一下服務(wù)器，首先重新啟動(dòng)了一下Nginx代理服務(wù)器。 

service nignx stop // 關(guān)閉Nginx服務(wù)  
service nginx start // 開(kāi)啟Nginx服務(wù) 

去前臺(tái)刷新了幾下沒(méi)有恢復(fù)。 那就在重啟一下php吧，于是就： 

service php-fpm stop // 關(guān)閉PHP服務(wù)  
service php-fpm start // 開(kāi)啟PHP服務(wù) 

又去前臺(tái)試了試還是沒(méi)有恢復(fù)。（有人會(huì)問(wèn)為什么不直接用 service xxx restart 來(lái)重啟各服務(wù)呢？ 我也不知道為什么，個(gè)人愛(ài)好吧?。┠侵挥幸环N可能數(shù)據(jù)庫(kù)出問(wèn)題了。

打開(kāi) Navicat 連接了一下數(shù)據(jù)庫(kù)，發(fā)現(xiàn)可以正常連接而且可以看到所有的表，隨便打開(kāi)了一張表能看到里面的數(shù)據(jù)，但是彈出了一個(gè)錯(cuò)誤的提示。 

Got error 28 from storage engine 

大概是這個(gè)錯(cuò)誤提示，當(dāng)時(shí)也沒(méi)在意，心想反正提示錯(cuò)誤了那就重啟一下物理服務(wù)器吧，這里是物理服務(wù)器?。。‰S后執(zhí)行了這個(gè)命令（為什么不直接重啟MySQL服務(wù)呢？ 事后想了想我也不知道為什么。 而且如果當(dāng)時(shí)注意看看這個(gè)錯(cuò)誤，是因?yàn)榇疟P(pán)空間問(wèn)題引起的，也許后面就不會(huì)有那么多驚心動(dòng)魄了?。?nbsp;

reboot // 重啟物理服務(wù)器 

執(zhí)行完以后所有的服務(wù)都正常關(guān)閉了，只有Mysql數(shù)據(jù)庫(kù)服務(wù)。 

Shutdown MySQL ………………………………………………. 

引號(hào)已經(jīng)5排了，實(shí)在是等不下去了。 斷電?。。。∕ySQL沒(méi)有安全關(guān)閉，直接斷電會(huì)出問(wèn)題的?。。。?/p>

三、 恢復(fù)進(jìn)程

等了一會(huì)，物理服務(wù)器啟動(dòng)起來(lái)了。一切的應(yīng)用服務(wù)都正常啟動(dòng)了，只看到在啟動(dòng)MySQL數(shù)據(jù)庫(kù)的時(shí)候出現(xiàn)了。 

The server quit without updating pid file (/var/lib/mysql/localhost.localdomain.pid) 

等到全部服務(wù)加載完成以后手動(dòng)又進(jìn)行了一次MySQL數(shù)據(jù)庫(kù)啟動(dòng)： 

service mysql start 

依然報(bào)前面那樣的錯(cuò)誤，此時(shí)心里開(kāi)始緊張了起來(lái)。 Google了一下這個(gè)錯(cuò)誤，網(wǎng)上提供了幾種解決的方案：

1、 Mysql權(quán)限問(wèn)題 

chown -R mysql:mysql /var/lib/mysql/*  
chmod -R 660 /var/lib/mysql/* 

2、 Mysql 服務(wù)已開(kāi)啟 

ps -ef|grep mysqld // 查看是否有mysqld進(jìn)程  
kill -9 進(jìn)程號(hào) // 強(qiáng)制殺死進(jìn)程 

3、 殘余數(shù)據(jù)影響了Mysql服務(wù)的啟動(dòng)

    刪除數(shù)據(jù)庫(kù)目錄(我的數(shù)據(jù)庫(kù)目錄為rpm安裝默認(rèn)目錄：/var/lib/mysql)下的 mysql-bin.index 文件

4、 Mysql配置文件(默認(rèn)為：/etc/my.cnf)

    配置文件里面沒(méi)有配置數(shù)據(jù)庫(kù)目錄，這個(gè)問(wèn)題一般在剛安裝MySQL時(shí)候會(huì)出現(xiàn)

5、 skip-federated字段問(wèn)題

    MySQL配置文件注釋掉skip-federated字段

6、 selinux的問(wèn)題

    centos6.8以上默認(rèn)會(huì)開(kāi)啟selinux服務(wù)，加強(qiáng)版軍用級(jí)防火墻。為了查問(wèn)題可以直接關(guān)掉

/usr/sbin/setenforce 0 

以上解決方案全部都已經(jīng)使用過(guò)了，都沒(méi)有解決問(wèn)題，依然開(kāi)啟服務(wù)會(huì)報(bào)錯(cuò)。 此時(shí)的心開(kāi)始涼了。

回頭看了看往期的備份，xxxx_20171208.sql。 都快2018年6月份了，我的上次備份竟然是17年12月份的，半年了！都半年沒(méi)備份過(guò)了！ （我視乎隱約的感覺(jué)前段時(shí)間是有備份的，備份的服務(wù)器硬盤(pán)好像被我清理了）。

進(jìn)入到數(shù)據(jù)庫(kù)目錄下，看到了除了上述說(shuō)的 mysql-bin.index 文件以外還有其他的幾個(gè)文件：mysql-bin.~rec~ 、 ib_logfile1、 ib_logfile0、 ibdata1 想了想是不是這幾個(gè)也是一些殘余文件，全部刪了試試。 嘗試把這幾個(gè)文件轉(zhuǎn)移到了其他的目錄（使用的mv命令）模擬刪除效果，同時(shí)還相當(dāng)于備份。 

service mysql start 

竟然MySQL數(shù)據(jù)庫(kù)服務(wù)正常啟動(dòng)了！ 心里的喜悅涌了上來(lái)，趕緊使用Navicat連接一下看看，能夠正常連接，看到了數(shù)據(jù)庫(kù)。 打開(kāi)數(shù)據(jù)庫(kù)以后所有的表都沒(méi)有了！ 此時(shí)心又酸了起來(lái)。 一轉(zhuǎn)眼11:30了，時(shí)間過(guò)的可真快啊，同事叫著一起吃飯，此時(shí)的我已經(jīng)全無(wú)吃飯的心情了。

恢復(fù)表結(jié)構(gòu)

把剛才移走的幾個(gè)文件又恢復(fù)到了原目錄里，既然恢復(fù)MySQL進(jìn)程現(xiàn)在沒(méi)什么希望了，那就想辦法恢復(fù)數(shù)據(jù)吧。 進(jìn)入到數(shù)據(jù)庫(kù)目錄（/var/lib/mysql）下找到了我的數(shù)據(jù)庫(kù)名字以目錄的形式存放。 進(jìn)去該目錄以后發(fā)現(xiàn)里面都是以擴(kuò)展名為：xxxx表.frm文件，這些不都是我的數(shù)據(jù)庫(kù)表嗎？ 里面是不是就存放了所有的數(shù)據(jù)？ 是不是直接拿這些文件就可以恢復(fù)數(shù)據(jù)呢？Google了一下，果然有這方面的文章，大致說(shuō)： “frm可以恢復(fù)表結(jié)構(gòu)，同時(shí)InnoDB數(shù)據(jù)庫(kù)引擎和MyISAM數(shù)據(jù)庫(kù)引擎恢復(fù)的方式不一樣”。

1、 InnoDB數(shù)據(jù)庫(kù)引擎

1. 在一個(gè)正常的MySQL數(shù)據(jù)庫(kù)服務(wù)器（new_server）下建立數(shù)據(jù)庫(kù)（new_db），該數(shù)據(jù)庫(kù)的名稱(chēng)和異常服務(wù)器（old_server）數(shù)據(jù)庫(kù)(old_db)保持一致。
2. 在new_db數(shù)據(jù)庫(kù)中建立一張表與old_db的表名稱(chēng)（t_user）一致。
3. 將new_server服務(wù)器的MySQL數(shù)據(jù)庫(kù)服務(wù)關(guān)閉。
4. 從old_server服務(wù)器下old_db的數(shù)據(jù)庫(kù)目錄下復(fù)制t_user.frm文件到new_server服務(wù)器下new_db的數(shù)據(jù)庫(kù)目錄下替換t_user.frm文件。
5. 開(kāi)啟new_server服務(wù)器的MySQL數(shù)據(jù)庫(kù)服務(wù)。
6. 使用連接工具連接new_server就可以看到new_db下的表及表結(jié)構(gòu)。

2、 MyISAM數(shù)據(jù)庫(kù)引擎

    其他和InnoDB數(shù)據(jù)庫(kù)引擎操作基本一致，只是在new_server服務(wù)器下new_db的數(shù)據(jù)庫(kù)目錄下創(chuàng)建兩個(gè)空的文件：t_user.MYD 和 t_user.MYI。

我使用的數(shù)據(jù)庫(kù)為InnoDB引擎，無(wú)奈的我以上兩種方法都使用了，沒(méi)有恢復(fù)任何表結(jié)構(gòu)更沒(méi)有數(shù)據(jù)，也許可能是我操作有問(wèn)題吧。 此時(shí)看到了目錄下有一個(gè)文件： ibdata1 Google了一下，可以和xxx.frm配合使用，又一次將new_server服務(wù)器的MySQL數(shù)據(jù)庫(kù)服務(wù)關(guān)閉。 直接把old_server服務(wù)器下old_db的數(shù)據(jù)庫(kù)目錄下復(fù)制ibdata1文件到new_server服務(wù)器下new_db的數(shù)據(jù)庫(kù)目錄下替換ibdata1文件。 

service mysql start 

新的服務(wù)器也出現(xiàn)了這樣的錯(cuò)誤，導(dǎo)致錯(cuò)誤的很大原因可能是ibdata1文件損壞引起的。

今天北京的天氣已經(jīng)達(dá)到了35攝氏度，但此時(shí)我的心已經(jīng)涼了一半了，雖然沒(méi)有按時(shí)備份數(shù)據(jù)及服務(wù)器異常崩潰造成數(shù)據(jù)丟失比直接刪庫(kù)的責(zé)任小了點(diǎn)，但是也辦法向公司交代，真的需要開(kāi)始準(zhǔn)備 “離職申請(qǐng)” 了嗎？

binlog日志

打開(kāi)微信

    我：你們公司用的是什么數(shù)據(jù)庫(kù)，是MySQL嗎

    好友LZ：是的

    我：公司的MySQL壞了，啟動(dòng)不了了； 數(shù)據(jù)沒(méi)有備份； 有什么好辦法把數(shù)據(jù)拿回來(lái)嗎

    好友LZ：你們之前數(shù)據(jù)的binlog還有嗎；通過(guò)這個(gè)應(yīng)該可以恢復(fù)

    我：都有

    好友LZ：我也沒(méi)弄過(guò)數(shù)據(jù)恢復(fù)，都是DBA搞，感覺(jué)應(yīng)該可以的；你先查查看網(wǎng)上有沒(méi)有解決方案，我這會(huì)在上線(xiàn)。

    我：嗯

本來(lái)想說(shuō)：“你能不能問(wèn)問(wèn)好友LZ你們DBA遇到過(guò)這種情況嗎，幫忙給個(gè)方案”；最后還是沒(méi)有好意思開(kāi)出口。 不過(guò)binlog這個(gè)名字讓我突然想起了數(shù)據(jù)庫(kù)目錄（/var/lib/mysql）下面幾個(gè)較大的文件。

這十幾個(gè)文件就是binlog日志文件，每臺(tái)服務(wù)器上面的個(gè)數(shù)應(yīng)該不一樣，這個(gè)文件只有每次重啟MySQL服務(wù)或者刷新日志（MySQL命令：show master logs）的時(shí)候才會(huì)新增一個(gè)?？戳艘幌挛易罱膸讉€(gè)文件，2018年1月16、 2018年3月18、 2018年4月18、 2018年5月28這幾個(gè)時(shí)間點(diǎn)產(chǎn)生了新的文件，說(shuō)明MySQL服務(wù)器這幾個(gè)日期都進(jìn)行過(guò)關(guān)閉又開(kāi)啟的操作。

binlog使用：

    binlog文件簡(jiǎn)介（網(wǎng)上摘抄）

    MySQL的二進(jìn)制日志可以說(shuō)是MySQL最重要的日志了，它記錄了所有的DDL和DML(除了數(shù)據(jù)查詢(xún)語(yǔ)句)語(yǔ)句，以事件形式記錄，還包含語(yǔ)句所執(zhí)行的消耗的時(shí)間，MySQL的二進(jìn)制日志是事務(wù)安全型的。

    binlog作用（網(wǎng)上摘抄）

    MySQL Replication在Master端開(kāi)啟binlog，Mster把它的二進(jìn)制日志傳遞給slaves來(lái)達(dá)到master-slave數(shù)據(jù)一致的目的。

    數(shù)據(jù)恢復(fù)，通過(guò)使用mysqlbinlog工具來(lái)使恢復(fù)數(shù)據(jù)。

使用binlog恢復(fù)數(shù)據(jù)之前需要確定MySQL是否開(kāi)啟binlog日志：

show variables like 'log_%'; 

狀態(tài) OFF 為未開(kāi)啟，狀態(tài) ON 表示已開(kāi)啟。

可以通過(guò)MySQL配置文件（默認(rèn)路徑：/etc/my.cnf）開(kāi)啟或關(guān)閉binlog日志。 

vi /etc/my.cnf 

使用加上#可以關(guān)閉，去掉開(kāi)啟。 修改后需要重啟MySQL服務(wù)（service mysql restart）才可以生效。

恢復(fù)數(shù)據(jù)（binlog日志方式）

初試mysqlbinlog工具

看到上面的那么多mysql-bin文件，很顯然使用centos6.5下rpm方式安裝的MySQL默認(rèn)是打開(kāi)binlog日志的。 這時(shí)我們就需要用到MySQL的 mysqlbinlog 工具，想使用它首先需要確保已經(jīng)安裝MySQL服務(wù)，然后我們需要找到它的位置。

find / -name mysql 

    2 表示為MySQL可執(zhí)行文件的目錄

    3 表示為MySQL的數(shù)據(jù)庫(kù)目錄

那我們先簡(jiǎn)單的使用一下：

cd /var/lib/mysql  
mysqlbinlog mysql-bin.000001 > mysql-bin.000001.sql 

很顯然我在使用mysqlbinlog的時(shí)候是，直接執(zhí)行的mysqlbinlog命令，前面并沒(méi)有增加任何路徑。 因?yàn)槟J(rèn)centos系統(tǒng)會(huì)將/usr/bin這個(gè)目錄配置到環(huán)境標(biāo)量中，若我們使用的是rpm方式安裝的MySQL，默認(rèn)是安裝到/usr/bin目錄下的。 可以直接在任何路徑下使用/usr/bin目錄里的文件。 執(zhí)行完上面的語(yǔ)句后會(huì)發(fā)現(xiàn)在當(dāng)前目錄生成一個(gè)mysql-bin.000001.sql的文件， 打開(kāi)文件可以看到很多sql語(yǔ)句。

對(duì)于我當(dāng)前的情況來(lái)看并不需要把所有的binlog都處理一遍，上面提到我上次的備份是在2017年12月8日的時(shí)候（xxxx_20171208.sql）因此我只需要從 mysql-bin.000009 這個(gè)binlog文件開(kāi)始就可以了。

首先我在另外一臺(tái)服務(wù)器上面重新搭建了一個(gè)MySQL服務(wù)，把mysql-bin.000009以后的幾個(gè)binlog都拷貝到了這臺(tái)新的服務(wù)器上面去。（服務(wù)器出現(xiàn)任何問(wèn)題，建議不要對(duì)該服務(wù)器做任何操作，換一臺(tái)新的電腦或服務(wù)來(lái)處理，為了保護(hù)數(shù)據(jù)的完整性?。?/p>

使用備份文件恢復(fù)數(shù)據(jù)

在新的MySQL上面建了一個(gè)和以前一樣名稱(chēng)的數(shù)據(jù)庫(kù)。

    mysql -u數(shù)據(jù)庫(kù)用戶(hù)名 -p數(shù)據(jù)庫(kù)密碼 數(shù)據(jù)庫(kù)名稱(chēng) --default-character-set=utf8 < xxxx_20171208.sql

    例：mysql -uroot -proot xxxx --default-character-set=utf8 < xxxx_20171208.sql

使用binlog恢復(fù)數(shù)據(jù)

這時(shí)數(shù)據(jù)庫(kù)有了，數(shù)據(jù)表及表結(jié)構(gòu)也有了，那就開(kāi)始恢復(fù)數(shù)據(jù)吧。   

mysqlbinlog mysql-bin.000009 | mysql -uroot -proot 

回車(chē)馬上就出錯(cuò)了，遇到了兩種錯(cuò)誤，一種是PRIMARY的錯(cuò)誤，一種是找不到記錄的錯(cuò)誤。 mysqlbinlog在執(zhí)行mysql-bin.000009文件里的插入語(yǔ)句時(shí)出錯(cuò)了。 看了一下mysql-bin.000009文件的創(chuàng)建時(shí)間是2017年11月12日，我的備份文件是2017年12月8日，他們兩個(gè)時(shí)間差了二十幾天，執(zhí)行上面恢復(fù)語(yǔ)句肯定會(huì)出現(xiàn)重復(fù)插入的問(wèn)題，數(shù)據(jù)庫(kù)里的某些表是由PRIMARY KEY的約束的，所以會(huì)導(dǎo)致PRIMARY錯(cuò)誤。 這時(shí)我們需要用到mysqlbinlog的參數(shù)： start-datetime 和 end-datetime，顧名思義一個(gè)是開(kāi)始時(shí)間一個(gè)是結(jié)束時(shí)間。

mysqlbinlog --start-datetime="2017-12-08 10:00:00" mysql-bin.000009 | mysql -uroot -proot 

看了一下我備份的xxxx_20171208.sql大致是2017年12月8日的10左右，沒(méi)有添加 end-datetime 參數(shù)的話(huà)默認(rèn)為該binglog文件下的最后一個(gè)時(shí)間點(diǎn)。 執(zhí)行了以后報(bào)了一個(gè)找不到記錄的異常。 應(yīng)該是執(zhí)行刪除或更新語(yǔ)句的時(shí)候沒(méi)有找到某條記錄，時(shí)間還是不對(duì)。 于是我就查看了數(shù)據(jù)庫(kù)的日志表，最后的時(shí)間是2017年12月8日9點(diǎn)32分41秒，又執(zhí)行了一次。 

mysqlbinlog --start-datetime="2017-12-08 09:32:41" mysql-bin.000009 | mysql -uroot -proot 

依然報(bào)錯(cuò)，那怎么辦呢，難道這個(gè)方法不行？ 

mysqlbinlog mysql-bin.000009 > mysql-bin.000009.sql 

此時(shí)打開(kāi)mysql-bin.000009.sql里面擁有大量的sql語(yǔ)句，發(fā)現(xiàn)好多條sql語(yǔ)句在這個(gè)時(shí)間點(diǎn)下。 看來(lái)使用參數(shù)來(lái)控制行不通。 還好mysqlbinlog工具給我們提供了另外兩個(gè)參數(shù)start-position 和 end-position

修改了一下命令： 

mysqlbinlog --start-position="123456" mysql-bin.000009 | mysql -uroot -proot 

果然一切都正常了，執(zhí)行這個(gè)命令需要很久，它要把你這段時(shí)間所有的增加、刪除、更新都執(zhí)行一遍。 這里可能還會(huì)遇到一個(gè)問(wèn)題，我的這個(gè)MySQL服務(wù)器里面這有一個(gè)數(shù)據(jù)庫(kù)，MySQL的binlog文件記錄的是所有數(shù)據(jù)庫(kù)的增加、刪除、更新記錄，那怎樣只針對(duì)某個(gè)數(shù)據(jù)庫(kù)來(lái)操作呢？ 這時(shí)我們需要用到mysqlbinlog的database參數(shù)。

mysqlbinlog --database=xxxx --start-position="123456" mysql-bin.000009 | mysql -uroot -proot 

半年的數(shù)據(jù)，就這么一個(gè)一個(gè)的binlog文件進(jìn)行處理的，從晚上6點(diǎn)到夜里的12點(diǎn)完成所有文件的恢復(fù)，數(shù)據(jù)量不是很大，服務(wù)器的性能也不是太高，中間出了點(diǎn)問(wèn)題，不過(guò)都是服務(wù)器中斷的問(wèn)題。 最后把所有的數(shù)據(jù)全部恢復(fù)了回來(lái)，這心驚肉跳的一天！

這是工作7年來(lái)出的最大一次事故，去年給自己定的一個(gè)目標(biāo)今年寫(xiě)12篇有質(zhì)量的文章反饋給互聯(lián)網(wǎng)，都快過(guò)半年了一篇還沒(méi)有寫(xiě)，沒(méi)想到第一篇竟然是以這種方式書(shū)寫(xiě)的。 不知道這篇算不算是有質(zhì)量，希望能幫到更多的人。

總結(jié)

遇到問(wèn)題不要盲目，保持清醒的頭腦，找清問(wèn)題，整理好思路才能更有效的解決問(wèn)題。 對(duì)于數(shù)據(jù)平時(shí)不要怕麻煩，注意備份。

備注

我的服務(wù)器及各軟件的版本

• 操作系統(tǒng)：** centos6.5
• MySQL：** 5.5.49
• 安裝MySQL方式：** rpm