前段时间测试了一下GoldenGate,结合我之前的一些尝试,对于小机环境的迁移,思路是逐步清晰了起来。

需求的核心是跨平台迁移数据库,最好能够升级到新的版本,对于一个核心系统的一主两备,需要保证数据完整性的前提,同时能够尽可能保持在一个较短的维护时间,对此自己也琢磨了很多方案。

Oracle跨平台迁移的简单总结(r10笔记第91天)_MySQL

想了NFS的方案,在备库端建立一个NFS挂载点,源端指向Linux环境,然后直接Failover,这样数据就能够直接到Linux端,然后做一个跨平台的convert操作

Oracle跨平台迁移的简单总结(r10笔记第91天)_MySQL_02
这样就可以尽可能快的切换数据到了Linux端,然后在Linux端转换文件后直接利用TTS的方式导入,如果准备充分,这个过程应该不超过半个小时。

自己还为这种方案而沾沾自喜,最后试了一遍,发现其实不是那么回事。问题的瓶颈在哪里呢,就是跨平台的系统调用接口。

如果在Solaris端使用NFS共享的文件,尝试启动数据库,那么就会没有响应,会抛出一个比较奇怪的问题。

Oracle跨平台迁移的简单总结(r10笔记第91天)_MySQL_03
当然自己也坚持不懈查了一些资料,发现真不能这么玩,同时Solaris还可以,跨平台的情况下,还是有很多大大的不同。所以NFS这个方案就点到为止,pass了。

而对于大数据量的数据库做跨平台迁移,还有什么其他的思路吗,XTTS是一种方式,但是这种方案就比较纠结了,几乎是不可实现的,源端的数据库的网卡过旧,IO能力不足,拷贝基本上就是7M每秒的速度,对于一个近1T数据量的数据库做文件拷贝,简直不敢想象。方案虽然可行,但是不可接受。

那么使用Datapump呢,这个方案想比XTTS就更纠结了,传输,导入都更加耗时。如果保守估计,导出,传输,导入,整个过程估计得10多个小时,那我就可以直接下班回家了。

还有什么方案呢,其实还有不少,如果里面的表不多的话,可以直接使用物化视图的增量刷新来玩等。

最后到了我不大擅长的GoldenGate了,最后发现还是这种方式是一种可持续性的,维护时间最短的方案。

首先是全量同步,这个过程可以通过Datapump来完成,为什么选择Datapump呢,就因为是逻辑的,而物理的方式有一定的局限性,可以很轻松实现数据的跨版本导入。

那么问题来了,备库怎么datapump导出,这个不可行啊,我如果直接Failover了,备库就不可用了,还得重搭,这个还是有风险的。

如果你这么想,那就对了,其实可以充分利用闪回数据库的原理,先Failover,然后Datapump导出,完成这个工作之后,闪回继续接受归档,就是这个套路。

Oracle跨平台迁移的简单总结(r10笔记第91天)_MySQL_04
这个导入的过程持续10个小时,还是5个小时,都影响不大,因为都是新主库的操作。

而接下来的事情就需要注意了,那就是主库端的增量同步。

使用GoldenGate的意义就在于此。

Oracle跨平台迁移的简单总结(r10笔记第91天)_MySQL_05
怎么做增量同步呢,我们在备库端全量同步的时候需要标记一个检查点SCN,后续做增量同步就可以基于这个点来做了。

比如在目标端使用OGG同步,指定基于SCN 1887488就可以选择性同步了。

GGSCI (newtest.oracle.com) 3> start rep_tlbb, aftercsn 1887488

整个过程会保证数据的一致性,而且是一个持续性的同步过程,如果说夸张一些,是零维护时间的迁移式升级。总之,维护时间很短,对于业务端来说是透明的而且完全无感知。