通過Oracle來輔助MySQL資料問題的恢複

通過Oracle來輔助MySQL資料問題的恢複

今天琢磨一個問題，在平時的工作中如果碰到一些不規範的操作，drop,truncate,delete，恢複起來還是很困難的，drop操作在Oracle中如果開啟了recycle bin還是基本安全的，delete操作可以藉助flashback delete操作，可能有些更細微的操作update，insert等等操作導致了問題，需要做資料修複的時候，這個時候可以使用flashback query來輔助，如果來一個truncate，那就沒轍了，其實在truncate操作完成後，一般來說資料還都是在資料檔案裡的，這個時候可以藉助第三方的資料恢複工具來嘗試恢複，這個時候資料恢複就不是毫秒級了，容忍度在分鐘甚至小時都是沒有辦法的事情。

不過在Oracle中，如果你之前開啟了閃回資料庫功能，那truncate的資料就能找回來了。但是話說過來，整個系統都讓重啟給弄停了，這個影響可能更大。如果不使用flashback database，直接通過dataguard來做時間點恢複或者其它的標準恢複到資料刪除之前，也是一種方法。

所以說在Oracle中對於資料的恢複方法很多，使用情境也可以根據需要來選擇。

在MySQL中資料恢複可供選擇的方案相對就比較少了。不過有一個亮點就是MySQL中的redo日誌是可讀的，mysqlbinlog可以很輕鬆地解析出來裡面的內容。不過truncate,drop,一些DML失誤操作環境來說，對於MySQL來說就比較困難了。

一旦發生了問題，做資料的恢複就只能藉助於最近的備份了，需要相應的備份，然後在最近的備份基礎上通過解析相關的binlog，直到把資料變更時間點的資料恢複。

這個過程總體來說還是需要不少的時間的，首先就是判斷備份和binlog的時間點，可以在其它測試環境中完成，需要花費的時間應該不短。

我想了下面這個方案，把Oracle和mysql結合起來，充分利用Oracle的強大的閃回功能，可能這種方案對於很多資料恢複都有不少的亮點。

還沒有在本地測試，因為也需要一些額外的定製和資料類型映射，所以只是一個大概的思路。

首先還是保持MySQL原有的架構，一個主庫，兩個備庫。因為主庫中的binlog是做資料同步的關鍵，所以可以考慮設定一個路徑做sql解析，sql解析還是使用binlog，然後再做適當的變更。這個過程可以是一個非同步過程，然後和Oracle結合起來部署到Oracle中的schema中。

MySQL中的資料量相對來說還不是很大，所以可以考慮多個MySQL database和一個Oracle中的多個schema映射起來，資料類型可以適當做一些類型映射，比如，MySQL中的big int,small int等和Oracle中的number直接映射。varchar和varchar2映射等等。

資料到位之後，就可以考慮通過各種閃回特性來做資料的恢複了。發生了truncate之類的操作可以使用flashback database來恢複，drop操作可以通過recycle bin,flashback database或者基於時間點等來恢複。delete可以通過閃回刪除，閃回查詢等來恢複。update可以通過閃回查詢來恢複等等。得到了相應的技術局之後，可以直接匯出csv檔案，或者insert語句來。在MySQL中通過mysqlimport或者insert來完成資料的部署。

這個過程中可以使得MySQL端始終保持前行，可以打一個比方，比如一個部隊在行軍，結果突然某個軍官發現自己的地圖沒帶，落下半路上了，這個時候可以派一個士兵騎馬去取地圖。這個時候Oracle就是那個士兵，能夠完成這個艱巨的任務，部隊依舊行進，不會產生其他影響。