我的码头太小了，你无法靠岸
今天琢磨一个问题在平时的工作中如果碰到一些不规范的操作drop,truncate,delete恢复起来还是很困难的drop操作在Oracle中如果开启了recycle bin还是基本安全的delete操作可以借助flashback delete操作可能有些更细微的操作updateinsert等等操作导致了问题需要做数据修复的时候这个时候可以使用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就是那个士兵能够完成这个艰巨的任务部队依旧行进不会产生其他影响
