Oracle GoldenGate软件因其不受限于平台和版本甚至不同数据库的特性，所以在有跨库同步的需求时，是很好用的工具，被广泛应用。
不过随着业务增长，数据量膨胀，源端数据库可能面临迁移的需求，本文就介绍一种O->O情况下目标端数据库需要更换源端时的简单方法。
在使用OGG迁移数据库时，得益于OGG进程参数配置的便捷，实际上我们可以复用同一个源端抽取进程，然后拆分出两个投递进程，分别投递到不同的目标端。如下图所示：
这样的情形下，可以保证两个目标端得到的队列文件是完全一致的，仅前缀做区分。在待迁移数据库迁移之前，我们就可以很方便得将老目标端的源端修改为新库，并保证数据的一致性。方法为：
停掉待迁移数据库的源端抽取进程，保证投递进程投递的队列文件最后的CSN一致
观察源端抽取进程的RBA不再变化后，停掉两个源端投递进程，保证新库和老目标端数据均暂不变化
观察两个投递进程的RBA均不再变化后，启动源端抽取进程，并观察是否再次抽取到DML操作，确认进程正常（源端重启抽取进程后确认进程正常非常重要，整个数据库迁移过程中最不能出问题的就是源端抽取进程）
启用新库的抽取进程、投递进程，时间为当前时间（此时新库和老目标端数据一致，且暂不变化）
观察新库抽取进程是否未抽取到数据（因新库数据暂不变化，此时应抽取不到）
确认新库抽取进程未抽取到数据后，启动源端投递进程B，使新库继续同步待迁移数据库的数据
新库复制进程组B再次同步数据后，观察新库抽取、投递进程是否正常抽取到数据变化（此时即可保证变化的数据在a中的CSN之后，相当于数据是连续的）
删除掉老目标端的复制进程组A，并复用为新库到老目标端的复制进程组C（进程名、参数配置等均不变，仅重新添加时更换队列文件）
启动老目标端的复制进程组C，同步来自新库的数据，观察是否同步正常（基本上同步不会有异常，个别表可以多带带处理）
确认同步无误后，删除源端投递进程A，完成整个切换（此时新库到老目标端的同步完全独立，不受割接当晚操作的影响，也不需要额外的操作）
完成切换后，整个配置如下图所示：
可以看到，整个同步变成了类似“级联”的方式，老目标端依然可以保持与待迁移数据的数据一致，不影响现有的应用。
以下为整个OGG源端切换过程中部分操作的截图：
停止源端抽取进程
停止源端两个投递进程
启动源端投递进程
启动新库抽取进程
重新添加复制进程组C
因为OGG进程的灵活性，所以在整个源端更换的过程中，我们是有多次回旋的余地的，基本上在启动复制进程C之前，都可以根据当时具体的情况，决定是否继续进行更换的操作。所以，这种方式的风险性很小，不存在一锤子买卖，剩下的看老天的情况。当然了，在切换之前，我们尽可能得做一次完整的数据校验，处理掉同步过程中产生异常的表，后续的操作就会更加得平滑，安全。在我的迁移经历中，使用OGG迁移已经多次被证明是行之有效，安全且操作当晚压力较小的方式，推荐大家研究使用。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130080.html
OGG Integrated Native DDL简单测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%;...
摘要：年月日，迁移服务解决方案在城市峰会中正式发布。迁移服务向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案迁移服务，简称。 2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践...
摘要：年月日，迁移服务解决方案在城市峰会中正式发布。迁移服务向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案迁移服务，简称。 2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4100·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3597·2023-01-11 13:20
