作者介紹

本文通過記錄真實(shí)案例的形式，對(duì)故障排除的過程進(jìn)行總結(jié)和反思。文中不但描述了劉老師解決問題的思路，還清晰的記載了解決問題的方法。仔細(xì)閱讀此文，你會(huì)發(fā)現(xiàn)劉老師對(duì)故障的排除和修復(fù)有著清晰的思路和嚴(yán)謹(jǐn)?shù)膱?zhí)行方法。

另外，通過此文，還可以發(fā)現(xiàn)劉老師的一大愛好，去GitHub查找資源，并加以利用。這一舉動(dòng)不但體現(xiàn)了開源軟件的優(yōu)勢(shì)，也體現(xiàn)了開源愛好者的理念。接下來，讓我們閱讀劉老師的原文。

2020年2月25日，微信的朋友圈大量轉(zhuǎn)載微盟遭遇了系統(tǒng)重大故障，36小時(shí)內(nèi)尚未恢復(fù)核心生產(chǎn)數(shù)據(jù)，從而想到本人在兩周前處理的一個(gè)案例，開發(fā)人員誤刪除了生產(chǎn)數(shù)據(jù)，本人恢復(fù)的一個(gè)過程，同時(shí)給這個(gè)故障的處理過程做一個(gè)總結(jié)，也對(duì)學(xué)過的知識(shí)做一個(gè)梳理，希望對(duì)運(yùn)維的同學(xué)們有一個(gè)警示作用。

2月13日23:00接到微信通知，能否幫忙恢復(fù)數(shù)據(jù)。

系統(tǒng)環(huán)境信息如下：

• 操作系統(tǒng)：RHEL7.5

• 工作流平臺(tái)：開源activity

• 業(yè)務(wù)應(yīng)用：調(diào)用activity，生成該應(yīng)用的流程數(shù)據(jù)

• 工作流使用的數(shù)據(jù)庫：MYSQL 5.7社區(qū)版，一主兩備

• 23:05，開始介入數(shù)據(jù)丟失的故障

確認(rèn)一個(gè)大概解決問題的思路：

1、找到是什么人在什么時(shí)間點(diǎn)做了什么操作？

2、這個(gè)操作對(duì)系統(tǒng)的影響有多大，是否對(duì)其他系統(tǒng)有影響？確認(rèn)這個(gè)操作是不是正常業(yè)務(wù)體現(xiàn)？

3、確認(rèn)數(shù)據(jù)庫里受到影響的日志的時(shí)間段。

4、在仿真環(huán)境復(fù)盤整個(gè)故障。

5、制定技術(shù)恢復(fù)方案，在仿真環(huán)境驗(yàn)證數(shù)據(jù)恢復(fù)方案。

6、在仿真環(huán)境驗(yàn)證數(shù)據(jù)恢復(fù)后應(yīng)用是否正常。

7、備份生產(chǎn)環(huán)境數(shù)據(jù)，應(yīng)用數(shù)據(jù)恢復(fù)方案到生產(chǎn)環(huán)境。

8、生產(chǎn)環(huán)境綠燈測(cè)試，無誤后，恢復(fù)完成。

由于恢復(fù)生產(chǎn)數(shù)據(jù)是重大的數(shù)據(jù)調(diào)整，需要報(bào)請(qǐng)領(lǐng)導(dǎo)批準(zhǔn)，需要有完備的數(shù)據(jù)回退方案。

用了5分鐘理清了處理這個(gè)問題思路，接下來就是考慮具體的數(shù)據(jù)恢復(fù)了。在處理這個(gè)問題過程中，有兩個(gè)難點(diǎn)需要解決。

1、確認(rèn)要恢復(fù)的binlog的開始和結(jié)束。

2、根據(jù)binlog的開始和結(jié)束，確認(rèn)數(shù)據(jù)恢復(fù)方案，以及是否需要需要排除在這個(gè)時(shí)間段發(fā)生的其他干擾數(shù)據(jù)。

首先解決第一個(gè)問題：

1、詢問開發(fā)人員，開發(fā)人員給出晚間大概20:20左右操作rest接口，調(diào)用了activity（以下簡(jiǎn)稱工作流）平臺(tái)刪除流程模板的操作，導(dǎo)致該流程模板下所有的流程實(shí)例全部被刪除，在該流程模板下有5個(gè)在途的流程尚未處理完成。

2、根據(jù)開發(fā)人員的描述，登錄到工作流平臺(tái)的數(shù)據(jù)庫，查看數(shù)據(jù)庫在20:20左右的binlog 文件，并對(duì)11號(hào)binlog文件進(jìn)行備份。

3、將binlog拷貝到一個(gè)開發(fā)的服務(wù)器，通過mysqlbinlog進(jìn)行解析。解析命令為：mysqlbinlog -v --base64-output=decode-rows --skip-gtids=true --start-datetime='2020-02-13 20:10:00' --stop-datetime='2020-02-13 21:30:00' -d {$DBNAME} mysql-bin.000011 >>aa.log dbname做了脫敏處理。

4、觀察解析后的sql，在20:20分并未發(fā)現(xiàn)大量的刪除操作，確認(rèn)開發(fā)人員的話不可信，做故障診斷的第一原則：任何人的話都不能全信，也不可能不信，帶著疑問來找到論據(jù)證明他的說法。

5、繼續(xù)翻看解析的binlog，20:30開始出現(xiàn)大量的delete和update等操作，開始懷疑這一點(diǎn)是不是有問題的時(shí)間段。

6、將這一段的sql進(jìn)行歸納總結(jié)，歸納需要操作幾個(gè)表，對(duì)這個(gè)幾個(gè)表的操作類型，以及操作的數(shù)據(jù)的類別（業(yè)務(wù)ID）。同工作流平臺(tái)的同事進(jìn)行確認(rèn)，刪除一個(gè)工作流的模板，是不是涉及到這些表的變更，工作流平臺(tái)的同事確認(rèn)是這個(gè)過程，數(shù)據(jù)恢復(fù)的希望誕生了！

7、根據(jù)以前的經(jīng)驗(yàn)積累，github上有個(gè)開源項(xiàng)目binlog2sql，可以將binlog的event翻譯成sql語句，也可以翻譯成反向sql，頓時(shí)覺得這個(gè)問題應(yīng)該很“容易”解決了。

8、根據(jù)以上思考，開始在仿真環(huán)境里安裝binlog2sql工具，該工具就是一個(gè)python的程序，需要安裝好python環(huán)境以及需要的三方庫即可，具體的使用方式請(qǐng)參考：https://github.com/danfengcao/binlog2sql，同時(shí)也再次感謝工具的作者曹老師。

9、在仿真環(huán)境里，恢復(fù)生產(chǎn)環(huán)境有問題的實(shí)例，同時(shí)在工作流平臺(tái)將應(yīng)用的jdbc的url指向新的恢復(fù)好的實(shí)例。

以上幾個(gè)過程，已經(jīng)解決了第一個(gè)問題，接下來我們要解決第二個(gè)問題。

1、在以上的步驟里，已經(jīng)在仿真環(huán)境復(fù)盤了生產(chǎn)環(huán)境的故障，同時(shí)在也仿真環(huán)境里里安裝了binlog轉(zhuǎn)成sql的工具。

2、使用binlog2sql的工具，解析出來錯(cuò)誤執(zhí)行的sql，讓工作流的平臺(tái)的同時(shí)進(jìn)行確認(rèn)，同時(shí)讓工作流的同事，確認(rèn)在這個(gè)時(shí)間段內(nèi)沒有其他的應(yīng)用也在操作這個(gè)數(shù)據(jù)庫。

3、工作流的同事確認(rèn)sql全部為誤操作產(chǎn)生的sql。具體的確認(rèn)方式如下：

• 在仿真環(huán)境模擬創(chuàng)建一個(gè)工作流模板。

• 在這個(gè)模板上創(chuàng)建幾個(gè)測(cè)試實(shí)例

• 通過接口去刪除這個(gè)工作流模板，觀察應(yīng)用產(chǎn)生的sql，以此來確認(rèn)本人提供的sql是否正確。

同時(shí)，工作流平臺(tái)確認(rèn)在問題時(shí)間段內(nèi)無其他應(yīng)用操作，感覺勝利在望了，該問題可以輕松解決了。

4、通過binlog2sql生產(chǎn)反向sql，把sql應(yīng)用于仿真環(huán)境，問題就能解決了，仔細(xì)觀察反向sql文件，發(fā)現(xiàn)里面有一些亂碼，查看亂碼字段所在的表，發(fā)現(xiàn)表的定義是這樣的：

表中有個(gè)字段為longblob字段，產(chǎn)生的insert的sql無法執(zhí)行，這個(gè)問題該怎么處理？

5、這個(gè)問題到這里陷入了僵局，眼看馬上就能解決的問題，發(fā)現(xiàn)有一個(gè)表數(shù)據(jù)無法通過sql進(jìn)行插入，詢問工作流平臺(tái)同事，這個(gè)表是否很重要，得到答復(fù)，沒有這個(gè)表的數(shù)據(jù)，系統(tǒng)無法運(yùn)轉(zhuǎn)。

6、換個(gè)思路考慮一下，既然sql是通過二進(jìn)制的binlog生成的，可以考慮生成反向的二進(jìn)制binlog，然后把這一段反向的binlog應(yīng)用到數(shù)據(jù)庫，這個(gè)問題就解決了。

7、帶著這個(gè)思路，去github里翻看了項(xiàng)目。果然還真有一個(gè)：https://github.com/Meituan-Dianping/MyFlash 再次非常感謝美團(tuán)點(diǎn)評(píng)開源的myflash項(xiàng)目。

8、利用myflash生成了反向二進(jìn)制文件，把文件應(yīng)用到數(shù)據(jù)庫，工作流平臺(tái)在仿真環(huán)境測(cè)試，數(shù)據(jù)完美再現(xiàn)。

通過以上分析，基本上就可以輕松解決這個(gè)問題。對(duì)自己提出幾個(gè)問題：

1、為什么不用備份恢復(fù)的方式進(jìn)行數(shù)據(jù)庫恢復(fù)？

在這個(gè)系統(tǒng)上，數(shù)據(jù)已經(jīng)備份了，每天都有全備，不能使用這個(gè)恢復(fù)的原因，工作流平臺(tái)里有很多應(yīng)用的流程引擎，一旦做了基于時(shí)間點(diǎn)恢復(fù)，別的應(yīng)用的系統(tǒng)數(shù)據(jù)一塊被恢復(fù)了，將會(huì)導(dǎo)致別的系統(tǒng)會(huì)丟失一部分?jǐn)?shù)據(jù)。

2、為什么不基于表的數(shù)據(jù)恢復(fù)？

因?yàn)楣ぷ髁髌脚_(tái)是一個(gè)開源的平臺(tái)，數(shù)據(jù)模型之間的關(guān)聯(lián)性特別強(qiáng)，如果基于表的恢復(fù)，容易導(dǎo)致數(shù)據(jù)的約束出現(xiàn)問題。

反思：

1、 為什么在生產(chǎn)環(huán)境出現(xiàn)丟失數(shù)據(jù)的情況？

開發(fā)人員在生產(chǎn)上線過程越過了仿真環(huán)境，直接上生產(chǎn)，對(duì)生產(chǎn)上線過程并不嚴(yán)謹(jǐn)，雖然有管理流程，但是對(duì)流程的過程執(zhí)行不力。

2、研發(fā)人員的技術(shù)能力，研發(fā)人員對(duì)activity并不熟悉，對(duì)于修改流程模板的流程也不熟悉，提高研發(fā)人員的技術(shù)能力必須要提上日程。

結(jié)合以上分析過程，需要指定一些輔助策略來完善發(fā)布流程。

1、發(fā)布流程自動(dòng)化，應(yīng)用代碼發(fā)布自動(dòng)化發(fā)布，盡量避免人為參與。

2、應(yīng)用發(fā)布流程標(biāo)準(zhǔn)化，所有的腳本和上線的新的應(yīng)用的步驟必須經(jīng)過驗(yàn)證才能上線。