本文介绍如何在两朵阿里云之间进行OceanBase数据库迁移。
客户需求
某客户使用阿里云3.14底座，目前部署所在的机房是临时租借的，客户计划自建新机房，部署全新的3.16阿里云底座，并将底层架构系统整体迁移到新的阿里云底上。
OceanBase作为数据库底层核心组件，支持上百个应用系统，环境复杂，上游有30+个Oracle 到OceanBase 数据迁移任务，下游有100+条到大数据datahbu的大数据同步任务。我们在两朵阿里云之间进行数据迁移，必须做到可验证、可回滚、数据一致、 平滑迁移。
解决方案
方案一、物理迁移方案
物理迁移方案：借助OCP管控平台，通过加zone减zone方式，在目标机房增加OB物理副本，进行跨机房数据搬迁，在业务低峰期业务停写进行整体切换，将OB集群从原机房管控OCP1上面卸载，然后加载到目标机房新的OCP2管控上，从而实现跨云迁移。
具体迁移步骤如下：
1、打通新老机房之间网络，将目标新机房里面的observer 注册到老机房的OCP1 管控下。
2、在老的OCP1 管控下，增加新机房 2个zone，添加全功能副本。此时多数派还在老机房，业务无感知。
3、在目标机房增加一个zone，此时完成多数派同步需要跨机房，事务提交增加5ms左右（视原机房和目标机房网络延迟情况而定）.
4、原机房减少一个zone，下副本。
5、OB集群切换leader 到目标机房。
6、业务停写，OB集群从原机房OCP1管控里面卸载。
7、OB集群在目标机房OCP2管控里面加载。
8、应用在目标机房启动APP，验证业务是否正常。
具体流程图如下
图3-OB跨云迁移—加减zone 物理副本迁移方案1-2步骤
图4-OB跨云迁移—加减zone 物理副本迁移方案3-4步骤
图5-OB跨云迁移—加减zone 物理副本迁移方案5-7步骤
图6-OB跨云迁移—加减zone 物理副本迁移方案8步骤
方案二、逻辑迁移方案
逻辑迁移方案：借助OMS平台（OMS元数据跟OCP绑定），将数据从老的OB集群中分批分片导出，并写入到目标OB集群，支持全量迁移+增量迁移+数据校验，同时为了避免切换出现异常，可以在切换前可以建立反向同步链路，以防回滚。
具体迁移步骤如下：
1、在新的阿里云底座上面，按照单机房3副本，对等部署OB相应的新集群并建立对应的OB租户。（集群名+租户名+数据库名保持不变）
2、专门启用2台OMS 机器，进行OMS 逻辑数据迁移，按租户维度创建数据迁移任务（全量+增量+数据校验+反向回流）
3、待数据增量追上后，在新的阿里云底座上面，参照老机房已有任务新建对应数据迁移和数据同步链路。
4、新机房阿里云底座，应用部署APP，全链路测试验证。注意：新机房OB数据源跟老机房不一样，域名不同。
5、应用验证ok后，新的阿里云，OB新集群租户数据清除，按照2-4步骤重新迁移数据+搭建数据迁移和数据同步链路。
6、确定正式切换时间点， 具体按OceanBase 数据库标准切割方案进行操作。
图7-OB跨云迁移—OMS逻辑迁移方案
图8-OMS数据库迁移架构
图8-OceanBase数据库切割实现方案
两种方案对比
迁移方案 |
物理迁移方案 |
OMS逻辑迁移方案 |
迁移难度 |
适中 |
适中 |
迁移时间 |
短（小时） |
长（天） |
割接时间 |
短（分钟） |
长（小时） |
数据影响 |
无需数据校验 |
需要校验 |
应用影响 |
需要修改连接串 |
需要修改连接串 |
是否可以灰度 |
整体一次性切换 |
可以按租户维度进行灰度切换 |
是否可以提前验证 |
整体切换前，不支持在新底座进行上下游做全链路验证 |
可以提前配置好上下游同步链路，做全链路压测验证 |
是否可以回滚 |
可以 |
可以 |
物理迁移和逻辑迁移方案对比
最终方案
鉴于OB上下游链路众多，为了方便应用在新的阿里云底座上面进行全链路测试验证，客户选择使用OMS进行逻辑数据迁移。此方案满足变更三板斧，可以做到可灰度、可验证、可回滚，满足客户需求。
