誤刪系統(tǒng)怎么辦(誤刪系統(tǒng)軟件怎么辦)

前沿拓展：

---

MySQL解決方案工程師

由MySQL解決方案工程師來介紹您所關(guān)心的MySQL

作者介紹

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

注：本文轉(zhuǎn)載自訂閱號MySQL解決方案工程師，由徐軼韜編輯修訂。

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

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

一、背景和思路

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

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

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

操作系統(tǒng)：RHEL7.5工作流平臺：開源activity業(yè)務應用：調(diào)用activity，生成該應用的流程數(shù)據(jù)工作流使用的數(shù)據(jù)庫：MYSQL 5.7社區(qū)版，一主兩備23:05，開始介入數(shù)據(jù)丟失的故障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先解決第一個問題：

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

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

3、將binlog拷貝到一個開發(fā)的服務器，通過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等操作，開始懷疑這一點是不是有問題的時間段。

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

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

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

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

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

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

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

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

在仿真環(huán)境模擬創(chuàng)建一個工作流模板。在這個模板上創(chuàng)建幾個測試實例通過接口去刪除這個工作流模板，觀察應用產(chǎn)生的sql，以此來確認本人提供的sql是否正確。

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

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

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

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

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

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

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

三、問題的反思

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

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

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

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

因為工作流平臺是一個開源的平臺，數(shù)據(jù)模型之間的關(guān)聯(lián)性特別強，如果基于表的恢復，容易導致數(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ā)布流程自動化，應用代碼發(fā)布自動化發(fā)布，盡量避免人為參與。

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

作者丨劉寶珍 編輯修訂丨徐軼韜

來源丨MySQL解決方案工程師（ID：mysqlse）

dbaplus社群歡迎廣大技術(shù)人員投稿，投稿郵箱：editor@dbaplus.cn

拓展知識：