通過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就是那個士兵，能夠完成這個艱鉅的任務，部隊依舊行進，不會產生其他影響。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1631615/，如需轉載，請註明出處，否則將追究法律責任。