作者介紹

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

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

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

2月13日23:00接到微信通知，能否幫忙恢復數據。

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

• 操作系統：RHEL7.5

• 工作流平臺：開(kāi)源activity

• 業(yè)務(wù)應用：調用activity，生成該應用的流程數據

• 工作流使用的數據庫：MYSQL 5.7社區版，一主兩備

• 23:05，開(kāi)始介入數據丟失的故障

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

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

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

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

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

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

6、在仿真環(huán)境驗證數據恢復后應用是否正常。

7、備份生產(chǎn)環(huán)境數據，應用數據恢復方案到生產(chǎn)環(huán)境。

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

由于恢復生產(chǎn)數據是重大的數據調整，需要報請領(lǐng)導批準，需要有完備的數據回退方案。

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

1、確認要恢復的binlog的開(kāi)始和結束。

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

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

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

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

3、將binlog拷貝到一個(gè)開(kāi)發(fā)的服務(wù)器，通過(guò)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、觀(guān)察解析后的sql，在20:20分并未發(fā)現大量的刪除操作，確認開(kāi)發(fā)人員的話(huà)不可信，做故障診斷的第一原則：任何人的話(huà)都不能全信，也不可能不信，帶著(zhù)疑問(wèn)來(lái)找到論據證明他的說(shuō)法。

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

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

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

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

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

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

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

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

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

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

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

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

同時(shí)，工作流平臺確認在問(wèn)題時(shí)間段內無(wú)其他應用操作，感覺(jué)勝利在望了，該問(wèn)題可以輕松解決了。

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

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

5、這個(gè)問(wèn)題到這里陷入了僵局，眼看馬上就能解決的問(wèn)題，發(fā)現有一個(gè)表數據無(wú)法通過(guò)sql進(jìn)行插入，詢(xún)問(wèn)工作流平臺同事，這個(gè)表是否很重要，得到答復，沒(méi)有這個(gè)表的數據，系統無(wú)法運轉。

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

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

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

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

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

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

2、為什么不基于表的數據恢復？

因為工作流平臺是一個(gè)開(kāi)源的平臺，數據模型之間的關(guān)聯(lián)性特別強，如果基于表的恢復，容易導致數據的約束出現問(wèn)題。

反思：

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

開(kāi)發(fā)人員在生產(chǎn)上線(xiàn)過(guò)程越過(guò)了仿真環(huán)境，直接上生產(chǎn)，對生產(chǎn)上線(xiàn)過(guò)程并不嚴謹，雖然有管理流程，但是對流程的過(guò)程執行不力。

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

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

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

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