作者介紹

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

另外，通過此文，還可以發現劉老師的一大愛好，去GitHub查找資源，并加以利用。這一舉動不但體現了開源軟件的優勢，也體現了開源愛好者的理念。接下來，讓我們閱讀劉老師的原文。

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

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

系統環境信息如下：

• 操作系統：RHEL7.5

• 工作流平臺：開源activity

• 業務應用：調用activity，生成該應用的流程數據

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

• 23:05，開始介入數據丟失的故障

確認一個大概解決問題的思路：

1、找到是什么人在什么時間點做了什么操作？

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

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

4、在仿真環境復盤整個故障。

5、制定技術恢復方案，在仿真環境驗證數據恢復方案。

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

7、備份生產環境數據，應用數據恢復方案到生產環境。

8、生產環境綠燈測試，無誤后，恢復完成。

由于恢復生產數據是重大的數據調整，需要報請領導批準，需要有完備的數據回退方案。

用了5分鐘理清了處理這個問題思路，接下來就是考慮具體的數據恢復了。在處理這個問題過程中，有兩個難點需要解決。

1、確認要恢復的binlog的開始和結束。

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

首先解決第一個問題：

1、詢問開發人員，開發人員給出晚間大概20:20左右操作rest接口，調用了activity（以下簡稱工作流）平臺刪除流程模板的操作，導致該流程模板下所有的流程實例全部被刪除，在該流程模板下有5個在途的流程尚未處理完成。

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

3、將binlog拷貝到一個開發的服務器，通過mysqlbinlog進行解析。解析命令為：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分并未發現大量的刪除操作，確認開發人員的話不可信，做故障診斷的第一原則：任何人的話都不能全信，也不可能不信，帶著疑問來找到論據證明他的說法。

5、繼續翻看解析的binlog，20:30開始出現大量的delete和update等操作，開始懷疑這一點是不是有問題的時間段。

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

7、根據以前的經驗積累，github上有個開源項目binlog2sql，可以將binlog的event翻譯成sql語句，也可以翻譯成反向sql，頓時覺得這個問題應該很“容易”解決了。

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

9、在仿真環境里，恢復生產環境有問題的實例，同時在工作流平臺將應用的jdbc的url指向新的恢復好的實例。

以上幾個過程，已經解決了第一個問題，接下來我們要解決第二個問題。

1、在以上的步驟里，已經在仿真環境復盤了生產環境的故障，同時在也仿真環境里里安裝了binlog轉成sql的工具。

2、使用binlog2sql的工具，解析出來錯誤執行的sql，讓工作流的平臺的同時進行確認，同時讓工作流的同事，確認在這個時間段內沒有其他的應用也在操作這個數據庫。

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

• 在仿真環境模擬創建一個工作流模板。

• 在這個模板上創建幾個測試實例

• 通過接口去刪除這個工作流模板，觀察應用產生的sql，以此來確認本人提供的sql是否正確。

同時，工作流平臺確認在問題時間段內無其他應用操作，感覺勝利在望了，該問題可以輕松解決了。

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

表中有個字段為longblob字段，產生的insert的sql無法執行，這個問題該怎么處理？

5、這個問題到這里陷入了僵局，眼看馬上就能解決的問題，發現有一個表數據無法通過sql進行插入，詢問工作流平臺同事，這個表是否很重要，得到答復，沒有這個表的數據，系統無法運轉。

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

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

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

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

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

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

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

因為工作流平臺是一個開源的平臺，數據模型之間的關聯性特別強，如果基于表的恢復，容易導致數據的約束出現問題。

反思：

1、 為什么在生產環境出現丟失數據的情況？

開發人員在生產上線過程越過了仿真環境，直接上生產，對生產上線過程并不嚴謹，雖然有管理流程，但是對流程的過程執行不力。

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

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

1、發布流程自動化，應用代碼發布自動化發布，盡量避免人為參與。

2、應用發布流程標準化，所有的腳本和上線的新的應用的步驟必須經過驗證才能上線。