OceanBase迁移服务（OceanBaseMigration Service，OMS）是蚂蚁OceanBase提供的一种支持同构或异构RDBMS与OceanBase之间进行数据交互的服务，它提供了数据在线迁移和实时增量同步的数据复制能力。
小伙伴们应该还记得上次分享了OMS迁移过程中增量同步因为白名单被截断而导致的问题吧，通过更新OMS补丁后已经解决。但一套完整的割接上线方案不仅能够满足正向同步机制，反向同步也是割接回退方案中不可缺少的步骤。因此，这几天集中火力对反向同步测试进行了炮火攻击，在即将大战告捷之时突然发现反向增量同步因白名单配置表太多出现Bug导致同步失败。
通过对日志分析及与阿里工程师交涉得知反向白名单配置超过3200张表时会报错，解决该问题需要更新OMS补丁。解决方案:配置黑名单减少同步对象数量，这种方式不符合实现需求。另一种方式就是创建多条链路进行反向同步，链路增加会增加后续维护难度，但是在出现同步异常时只需要修复故障链路即可，下面就带领大家一起体会下整个反向同步过程。
场景环境信息:430张配置表数据从oracle端实时同步到ob端，其他约3600张业务数据表需要从ob端实时同步到oracle端。根据报错场景将业务用户下的表都进行反向同步。
场景配置
需要配置反向链路，反向链路配置方式是通过正向链路方式先将表结构迁移，在ob端去掉oms创建的隐藏约束，跳过一部分迁移任务，然后切换为反向链路，在这里我先不详细讲解了，后续我会在单独章节为大家介绍配置过程。
配置单独迁移任务迁移表结构，如果已经存在表迁移表结构过程中会报错并跳过
图1：配置迁移表结构的迁移任务的数据源
图2：配置需要迁移表结构的表
图3：运行迁移任务的检查和结构迁移
图4：查看结构迁移的表结构迁移子任务
图5：在OB端检查失败任务表是以前存在的表
2.结构迁移完检查链路没有发起可以直接删除这个临时任务
图6：检查监控没有发起链路
图7：检查没有链路之后可以直接删除这个迁移任务
3.ob端删除需要反向同步的表的隐藏约束
图8：需要删除的是oms迁移过程中创建的UK隐藏约束
图9：删除隐藏约束语句
4.创建正向迁移任务，在配置白名单的时候因为表数量太多不好勾选，可以随便选择两张表创建上任务，后续修改参数
图10：创建迁移任务，配置数据源
图11：白名单随便选择两个表，后续修改参数
5.需要在迁移任务开始之前修改三个参数，配置白名单
图12：执行迁移任务之前修改参数
图13：需要修改3个参数之二，dest_drc_wlist、forward_white_list
图14：需要修改3个参数之一，source_drc_wlist
问题复现
问题重现点：按照反向链路配置方法执行迁移任务（需要手工跳过很多正向迁移中的任务），会在DRC进程处报错
图15：报错现象
问题定位分析
日志查看：
图16：前台日志显示
图17：前台日志并不能分析出原因，查看后台日志
可以看出因为白名单太长导致。
先清理报错任务，检查链路情况，执行清理任务，复检链路清理成功
图18:查看监控链路情况
图19:执行清理任务
图20:再检查下链路被清理了
清理干净后重置迁移任务，然后再创建一个迁移任务，将白名单分成两部分创建两条链路，修改参数
图21:如果不新建任务可以重置当前的迁移任务
图22:查看迁移任务状态已经清空
图23:重新修改参数，将表数量分成两批，每批不超过3200张，以下展示的是配置的第一批，第二批与第一批操作一致就不单独展示
图24:重新执行任务正常执行
按照反向链路配置方法配置，执行切换作业之后，反向同步链路就创建完成了
图25:发起切换任务
验证同步
查看OB端（目标端）与Oracle端（源端）的OGG_TEST表数据量（不一定一致，可以ob没数据，oracle有数据，ob新增数据实时同步回oracle，我这里ogg_test数据前期同步过）
图26:ob侧检查测试表数据量
图27:oracle侧检查测试表数据量
图28：在OB端（目标端）的OGG_TEST表中插入数据，并提交
图29：查看oracle端
反向实时同步已经发起
在OB推行数据库商业化的过程中会存在各种各样的问题，需要我们大家协同发现问题，分析问题，解决问题。只有这样才能打造一款坚实的国产化产品。国产化必将是未来几年国内各行各业经济和技术革新的一个趋势。因此，基于近一段时间的问题及时反馈、及时分析、及时修复，OMS已经更加趋于完善和健壮了。这样，也使得我们使用人员对于OB产品更加有信心，生态圈的完善本身也是在不断碰撞、不停的修缮中完善的。希望今天我们踩过的坑都将成为OB产品演进过程中的宝贵知识财富，后续的同仁在推行OB国产化道路上也可以尽可能的少走一些弯路。这次的分享到此结束，希望这次分享能帮助到大家。
