今天發一篇與以往不同的內容，這是一篇來自生產實踐的記錄。我只是做了一下編輯和修訂的工作。
劉老師通過記錄真實的案例的形式，對故障排除的過程進行總結和反思。文中不但描述了劉老師解決問題的思路，還清晰的記載了解決問題的方法。仔細閱讀此文，你會發現劉老師對故障的排除和修復有著清晰的思路和嚴謹的執行方法。另外，通過此文，還可以發現劉老師的一大愛好，去github查詢資源，並加以利用。這一舉動不但體現了開源軟體的優勢，也體現了開源愛好者的理念。接下來，讓我們閱讀劉老師的原文。
崗位：架構師，目前就職於大型資產管理公司的科技子公司，擁有多年的大型私有雲的規劃和設計工作經驗，熟悉軟體的開發流程，目前醉心於研究基於ddd和敏捷的軟體的開發模式，對分布式架構有深入的理解，同時也希望同各位朋友交流軟體架構和雲計算架構的經驗，在此也感謝徐老師對於本文的審核和修訂。
生產系統資料丟失後的恢復
一、背景和大概的思路
系統環境資訊如下：
作業系統：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 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環境以及需要的三方庫即可，具體的使用方式請參考：同時也再次感謝工具的作者曹老師。
9. 在**環境裡，恢復生產環境有問題的例項，同時在工作流平台將應用的jdbc的url指向新的恢復好的例項。
以上幾個過程，已經解決了第乙個問題，接下來我們要解決第二個問題。
1. 在以上的步驟裡，已經在**環境覆盤了生產環境的故障，同時在也**環境裡裡安裝了binlog轉成sql的工具。
2. 使用binlog2sql的工具，解析出來錯誤執行的sql，讓工作流的平台的同時進行確認，同時讓工作流的同事，確認在這個時間段內沒有其他的應用也在操作這個資料庫。
3. 工作流的同事確認sql全部為誤操作產生的sql。具體的確認方式如下：
(a) 在**環境模擬建立乙個工作流模板。
(b) 在這個模板上建立幾個測試例項
(c) 通過介面去刪除這個工作流模板，觀察應用產生的sql，以此來確認本人提供的sql是否正確。
同時，工作流平台確認在問題時間段內無其他應用操作，感覺勝利在望了，該問題可以輕鬆解決了。
4. 通過binlog2sql生產反向sql，把sql應用於**環境，問題就能解決了，仔細觀察反向sql檔案，發現裡面有一些亂碼，檢視亂碼字段所在的表，發現表的定義是這樣的。
表中有個字段為longblob欄位，產生的insert的sql無法執行，這個問題該怎麼處理？
5. 這個問題到這裡陷入了僵局，眼看馬上就能解決的問題，發現有乙個表資料無法通過sql進行插入，詢問工作流平台同事，這個表是否很重要，得到答覆，沒有這個表的資料，系統無法運轉。
6. 換個思路考慮一下，既然sql是通過二進位制的binlog生成的，可以考慮生成反向的二進位制binlog，然後把這一段反向的binlog應用到資料庫，這個問題就解決了。
7. 帶著這個思路，去github裡翻看了專案。果然還真有乙個： 再次非常感謝美團點評開源的myflash專案。
8. 利用myflash生成了反向二進位制檔案，把檔案應用到資料庫，工作流平台在**環境測試，資料完美再現。
三、問題的反思
通過以上分析，基本上就可以輕鬆解決這個問題。對自己提出幾個問題：
1. 為什麼不用備份恢復的方式進行資料庫恢復？
在這個系統上，資料已經備份了，每天都有全備，不能使用這個恢復的原因，工作流平台裡有很多應用的流程引擎，一旦做了基於時間點恢復，別的應用的系統資料一塊被恢復了，將會導致別的系統會丟失一部分資料。
2. 為什麼不基於表的資料恢復？
因為工作流平台是乙個開源的平台，資料模型之間的關聯性特別強，如果基於表的恢復，容易導致資料的約束出現問題。
反思：1. 為什麼在生產環境出現丟失資料的情況？
開發人員在生產上線過程越過了**環境，直接上生產，對生產上線過程並不嚴謹，雖然有管理流程，但是對流程的過程執行不力。
2. 研發人員的技術能力，研發人員對activity並不熟悉，對於修改流程模板的流程也不熟悉，提高研發人員的技術能力必須要提上日程。
四、後續問題
結合以上分析過程，需要指定一些輔助策略來完善發布流程。
1. 發布流程自動化，應用**發布自動化發布，盡量避免人為參與。
2. 應用發布流程標準化，所有的指令碼和上線的新的應用的步驟必須經過驗證才能上線。
全文至此結束。
歡迎
SQL取資料表主鍵
1 select table name,column name from information schema.key column usage where table name dtproperties 2 exec sp pkeys table name 表名 3 select o.name a...
SQL2005資料庫遠端用DTS導資料，丟失主鍵
不同伺服器資料庫之間的資料操作 建立鏈結伺服器 exec sp addlinkedserver itsv sqloledb 遠端伺服器名或ip位址 exec sp addlinkedsrvlogin itsv false null,使用者名稱 密碼 查詢示例 select from itsv.資料庫...
SQL系統資料庫
sql系統資料庫主要有以下資料庫組成 master model tempdb pbus msdb master master資料庫是sqlserver系統最重要的資料庫，它記錄了sqlserver系統的所有系統資訊，這些系統資訊包括所有的登入資訊 系統設定資訊 sqlserver的初始化資訊和其它系...