今天發(fā)一篇與以往不同的內(nèi)容，這是一篇來自生產(chǎn)實踐的記錄。我只是做了一下編輯和修訂的工作。

劉老師通過記錄真實的案例的形式，對故障排除的過程進行總結(jié)和反思。文中不但描述了劉老師解決問題的思路，還清晰的記載了解決問題的方法。仔細閱讀此文，你會發(fā)現(xiàn)劉老師對故障的排除和修復(fù)有著清晰的思路和嚴謹?shù)膱?zhí)行方法。另外，通過此文，還可以發(fā)現(xiàn)劉老師的一大愛好，去GitHub查找資源，并加以利用。這一舉動不但體現(xiàn)了開源軟件的優(yōu)勢，也體現(xiàn)了開源愛好者的理念。接下來，讓我們閱讀劉老師的原文。

作者：劉寶珍  

崗位：架構(gòu)師，目前就職于大型資產(chǎn)管理公司的科技子公司，擁有多年的大型私有云的規(guī)劃和設(shè)計工作經(jīng)驗，熟悉軟件的開發(fā)流程，目前醉心于研究基于DDD和敏捷的軟件的開發(fā)模式，對分布式架構(gòu)有深入的理解，同時也希望同各位朋友交流軟件架構(gòu)和云計算架構(gòu)的經(jīng)驗，在此也感謝徐老師對于本文的審核和修訂。

生產(chǎn)系統(tǒng)數(shù)據(jù)丟失后的恢復(fù)

一、背景和大概的思路

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

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

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

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

工作流平臺：開源activity

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

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

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

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

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

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

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

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

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

     6. 在仿真環(huá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)境綠燈測試，無誤后，恢復(fù)完成。

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

二、數(shù)據(jù)恢復(fù)過程以及技術(shù)分析

泰州數(shù)據(jù)恢復(fù)

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

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

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

首先解決第一個問題：

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

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

3. 將binlog拷貝到一個開發(fā)的服務(wù)器，通過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分并未發(fā)現(xiàn)大量的刪除操作，確認開發(fā)人員的話不可信，做故障診斷的第一原則：任何人的話都不能全信，也不可能不信，帶著疑問來找到論據(jù)證明他的說法。

5. 繼續(xù)翻看解析的binlog，20:30開始出現(xiàn)大量的delete和update等操作，開始懷疑這一點是不是有問題的時間段。常州數(shù)據(jù)恢復(fù)

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

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

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

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

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

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

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

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

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

(b)   在這個模板上創(chuàng)建幾個測試實例

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

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

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

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

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

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

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

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

三、問題的反思

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

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

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

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

因為工作流平臺是一個開源的平臺，數(shù)據(jù)模型之間的關(guān)聯(lián)性特別強，如果基于表的恢復(fù)，容易導(dǎo)致數(shù)據(jù)的約束出現(xiàn)問題。

反思：

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

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

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

四、后續(xù)問題

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

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

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

全文至此結(jié)束。