系統環境資訊如下：
23:05 開始介入資料丟失的故障。確認乙個大概解決問題的思路：
找到是什麼人在什麼時間點做了什麼操作？
這個操作對系統的影響有多大，是否對其他系統有影響？確認這個操作是不是正常業務體現？
確認資料庫裡受到影響的日誌的時間段
在**環境覆盤整個故障
制定技術恢復方案，在**環境驗證資料恢復方案
在**環境驗證資料恢復後應用是否正常
備份生產環境資料，應用資料恢復方案到生產環境
生產環境綠燈測試，無誤後，恢復完成
由於恢復生產資料是重大的資料調整，需要報請領導批准，需要有完備的資料回退方案。
用了 5 分鐘理清了處理這個問題思路，接下來就是考慮具體的資料恢復了。在處理這個問題過程中，有兩個難點需要解決。
確認要恢復的 binlog 的開始和結束。
根據 binlog 的開始和結束，確認資料恢復方案，以及是否需要需要排除在這個時間段發生的其他干擾資料。
首先解決第乙個問題。
詢問開發人員，開發人員給出晚間大概 20:20 左右操作 rest 介面，呼叫了 activity（以下簡稱工作流）平台刪除流程模板的操作，導致該流程模板下所有的流程例項全部被刪除，在該流程模板下有 5 個在途的流程尚未處理完成。
根據開發人員的描述，登入到工作流平台的資料庫，檢視資料庫在 20:20 左右的 binlog 檔案，並對 11 號 binlog 檔案進行備份。
將 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
繼續翻看解析的 binlog，20:30 開始出現大量的 delete 和 update 等操作，開始懷疑這一點是不是有問題的時間段。
將這一段的 sql 進行歸納總結，歸納需要操作幾個表，對這個幾個表的操作型別，以及操作的資料的類別（業務 id）。同工作流平台的同事進行確認，刪除乙個工作流的模板，是不是涉及到這些表的變更，工作流平台的同事確認是這個過程，資料恢復的希望誕生了！
根據以前的經驗積累，github 上有個開源專案 binlog2sql，可以將 binlog 的 event 翻譯成 sql 語句，也可以翻譯成反向 sql，頓時覺得這個問題應該很「容易」解決了。
根據以上思考，開始在**環境裡安裝 binlog2sql 工具，該工具就是乙個 python 的程式，需要安裝好 python 環境以及需要的三方庫即可，具體的使用方式請參考：同時也再次感謝工具的作者曹老師。
在**環境裡，恢復生產環境有問題的例項，同時在工作流平台將應用的 jdbc 的 url 指向新的恢復好的例項。
以上幾個過程，已經解決了第乙個問題，接下來我們要解決第二個問題。
在以上的步驟裡，已經在**環境覆盤了生產環境的故障，同時在也**環境裡裡安裝了 binlog 轉成 sql 的工具。
使用 binlog2sql 的工具，解析出來錯誤執行的 sql，讓工作流的平台的同時進行確認，同時讓工作流的同事，確認在這個時間段內沒有其他的應用也在操作這個資料庫。
工作流的同事確認 sql 全部為誤操作產生的 sql。
具體的確認方式如下：
1）在**環境模擬建立乙個工作流模板。
2）在這個模板上建立幾個測試例項
3）通過介面去刪除這個工作流模板，觀察應用產生的 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 並不熟悉，對於修改流程模板的流程也不熟悉，提高研發人員的技術能力必須要提上日程。
結合以上分析過程，需要指定一些輔助策略來完善發布流程。
發布流程自動化，應用**發布自動化發布，盡量避免人為參與。
應用發布流程標準化，所有的指令碼和上線的新的應用的步驟必須經過驗證才能上線。
丟失 移動 資料檔案後的故障表現
不管在開啟還是關閉資料庫，丟失 移動 資料檔案後啟動都是會報錯的，找不到檔案 丟失的資料檔案offline以後，是可以開啟資料庫的 sql shutdown immediate database closed.database dismounted.oracle instance shut down...
HBase在系統重啟後丟失資料
最近在學習 hbase 的一些東西，發現了一些奇怪的現象，我的 hbase 下的表建好後，重啟 linux，再啟動 hbase 相關服務後，奇怪的事情發生了。重啟之前我建了一張有數個列族的blogtable表，現在我用list命令檢視，發現表還在的。但是當我scan blogtable 的時候發現提...
取sql資料亂碼 生產系統資料丟失恢復案例
今天發一篇與以往不同的內容，這是一篇來自生產實踐的記錄。我只是做了一下編輯和修訂的工作。劉老師通過記錄真實的案例的形式，對故障排除的過程進行總結和反思。文中不但描述了劉老師解決問題的思路，還清晰的記載了解決問題的方法。仔細閱讀此文，你會發現劉老師對故障的排除和修復有著清晰的思路和嚴謹的執行方法。另外...