MySQL 迁移到 OceanBase，生产实施需要解决三个问题：如何搬迁存量数据，如何同步迁移期间的业务变化，以及如何在应用切换前验证数据正确性。
NineData 提供 MySQL→OceanBase MySQL 数据复制链路，支持结构复制、全量复制、CDC 增量复制和数据对比。通过组合这些能力，可以在存量迁移期间保持 MySQL 业务运行，再通过停写、增量追平、最终校验和应用切换完成低停机迁移。
本文以 MySQL 单向迁移到 OceanBase MySQL 模式为范围，介绍版本准备、任务配置、数据校验及生产割接。文中的资源监控、业务验证和回退步骤，是我们建议采用的迁移实施方法。
一、 低停机迁移如何组织
NineData 将迁移分为三个阶段：
新建目标环境选择"结构复制＋全量复制＋增量复制"。
目标表已经完成建表和兼容性改造时，选择"全量复制＋增量复制"，并配置源端与目标端的对象映射。
完整实施流程为：
|------------------------------------------------------------------------------------------------------|
| Plain Text 兼容性检查与环境准备 ↓ 创建数据源和复制任务 ↓ 结构复制、全量迁移、CDC 同步 ↓ 数据对比与业务验证 ↓ 源端停写、增量追平、最终校验 ↓ 应用切换到 OceanBase |
二、迁移前准备
1. 创建两端数据源
进入 NineData 控制台「数据源管理 > 数据源」，分别添加 MySQL 和 OceanBase MySQL 数据源。
填写连接地址、端口、账号、密码、接入地域和加密选项，完成连接测试。
使用 NineData 云服务接入数据库时，将创建数据源页面显示的服务 IP 加入数据库白名单。生产环境使用专用迁移账号，并限制网络来源。
连接成功与权限满足是两个检查阶段。 连接测试确认数据库可访问；复制任务的权限预检查确认账号具备执行所选复制阶段所需的权限。
2. 检查 MySQL Binlog
MySQL CDC 从 Binlog 获取数据变化。迁移前执行：
|------------------------------------------------------------------------------------------------------|
| Plain Text SHOW VARIABLES WHERE Variable_name IN ( 'log_bin', 'binlog_format', 'binlog_row_image' ); |
本文采用以下行日志配置作为实施基线：
|---------------------------------------------------------------------|
| Plain Text log_bin = ON binlog_format = ROW binlog_row_image = FULL |
ROW 记录行级变化，FULL 保留完整行镜像。参数修改由 DBA 按 MySQL 版本和部署方式执行，并确认修改已经生效。
如果从 MySQL 从库读取变化，还应确认上游复制产生的变化已写入该节点自身的 Binlog。
日志保留时间需要覆盖：
|-------------------------------|
| Plain Text 全量迁移耗时＋故障处理时间＋安全余量 |
同时检查日志增长速度、磁盘容量和清理策略。缺失的历史 Binlog 不能靠重新启动任务自动补回。
3. 盘点高风险表和对象
迁移前建立以下清单：
- 无主键、无唯一键的表；
- 大表、热点表和高频更新表；
- 大字段、生成列、自增列；
- 长事务和集中批处理；
- 分区、索引及约束；
- 视图、触发器、事件、函数和存储过程。
需要持续更新和删除的业务表，应优先采用稳定主键定位记录。无主键表单独验证更新、删除、任务重试和重复数据风险。
4. 验证应用兼容性
|-------|----------------------|
| 检查方向 | 验证内容 |
| 数据类型 | 无符号数、金额精度、时间精度、大字段 |
| 字符串 | 字符集、排序规则、大小写、特殊字符 |
| 表结构 | 默认值、自增列、生成列、索引、分区 |
| SQL | 分页、批量写入、函数、Hint、保留字 |
| 应用连接 | 驱动、连接池、超时、重连 |
| 事务与性能 | 隔离级别、锁等待、死锁重试、高频 SQL |
使用真实业务 SQL 和具有代表性的数据规模执行测试。结构复制成功不能替代应用兼容性和性能验收。
三、创建 NineData 迁移任务
进入「数据复制 > 数据复制」，单击「创建复制」。
1. 选择源端、目标端和复制类型
源数据源选择 MySQL，目标数据源选择 OceanBase for MySQL，复制方式选择单向复制。
空目标环境选择结构、全量和增量复制。目标表已建好时，不选择结构复制，在映射阶段指定已有对象。
对象命名规则支持全部转小写、保持与源一致和全部转大写。命名规则应与应用 SQL 及目标端大小写策略一致。
MySQL 迁移到 OceanBase该链路，目前NineData支持双向复制，双向复制链路仅正向侧支持 DDL 同步，适用于 MySQL 迁移至 OceanBase 时以正向增量复制（含 DDL）实时追平数据、反向增量复制仅作回退兜底且需冻结结构变更的业务不停机迁移场景；其业务价值在于：迁移期间业务无需停机，结构变更可随正向链路自动同步，保留反向回退通道，大幅降低割接风险与回退成本，保障迁移过程业务连续性与数据一致性。
2. 明确增量起点
仅增量复制任务需要选择增量开始时间：
- 从启动时间开始；
- 自定义历史时间及对应时区。
仅增量任务要求目标端已经具备与起点匹配的数据基线。导入旧数据后直接从当前时间同步，会遗漏两个时间点之间的变化。
组合全量和增量复制时，使用 NineData 的任务流程完成阶段衔接。
历史增量起点还要求相关日志仍然存在。起点早于任务启动时间、且期间发生 DDL 时，任务会失败。本文采用迁移期间冻结所选对象 DDL 的实施方式。
3. 配置增量操作类型
NineData 支持配置增量操作类型。取消某类操作后，对应变化会被忽略。
例如，忽略 DELETE 会使目标端保留源端已删除的记录。完整迁移应保留业务使用的 INSERT、UPDATE 和 DELETE，不通过忽略操作掩盖错误。
4. 设置目标端处理策略
同名对象
跳过结构复制前，逐列核对目标表。删除重建前，确认目标对象没有需要保留的数据。
全量存量数据
|---------------|-------------|
| 策略 | 行为 |
| 预检查报错并停止任务 | 发现目标已有数据后停止 |
| 忽略目标存量数据，追加写入 | 保留已有数据并继续写入 |
| 清空目标存量数据，重新写入 | 清空后重新装载 |
追加写入不会自动消除重复数据。目标端有历史迁移数据时，应先确认其来源和范围。
增量冲突
|---------|-------------|
| 策略 | 行为 |
| 运行时报错 | 冲突后等待处理 |
| 不更新目标数据 | 保留冲突目标记录并继续 |
| 更新目标数据 | 覆盖写入冲突目标记录 |
单向迁移期间，避免应用向 OceanBase 同一批业务表额外写入。冲突策略不能代替双写一致性设计。
5. 配置映射、过滤与模板导入
在「选择复制对象」中确定迁移范围，在「配置映射」中核对源库表、目标库表、字段、类型和过滤条件。
NineData 支持表名和字段名映射、行级过滤及批量命名配置。
需要复用大量对象配置时，在创建任务的「选择复制对象」页执行：
- 单击右上角「导入配置」。
- 单击「下载模板」。
- 保留模板列名，填写源库表、目标库表、字段列表等信息。
- 在 extra_configuration 单元格填写字段规则和过滤条件的 JSON 字符串。
- 单击「上传文件」完成导入。
- 继续到映射页审核结果。
这里上传的是下载后填写的 Excel 模板，不是把文档中的 JSON 示例直接保存为文件上传。
模板导入用于批量录入对象配置，特别适合创建多条具有相同复制对象的链路；它不会替代版本检查、权限检查和目标对象审核。
6. 执行预检查
本链路预检查覆盖：
- 两端连接；
- 两端账号权限；
- 版本兼容性；
- 目标已有数据；
- 目标同名对象；
- 循环链路；
- 源端联邦表可用性。
失败时打开「详情」定位原因，修复后重新检查。每个警告项都应记录处理结论。
通过后，从任务列表打开任务详情并启动复制。
五、运行期间的资源与进度检查
以下是我们建议实施团队配合数据库监控系统执行的检查，迁移监控分为复制任务和数据库运行状态两部分。 在 NineData 复制任务中检查任务状态、同步延迟、复制进度及错误信息；同时结合数据库监控系统，检查 MySQL CPU、磁盘 I/O、OceanBase 租户资源、存储空间和网络状况。两部分联合判断，确认源端读取、网络传输和目标写入瓶颈的一致性确认。
全量阶段重点观察：
- MySQL CPU、磁盘 I/O 和业务响应时间；
- OceanBase 写入响应、租户资源及存储空间；
- 网络吞吐；
- 全量进度和任务错误。
建议低峰启动，并单独跟踪大表和大字段表。表数量完成比例不能完整反映数据迁移进度，少数大表往往决定总耗时。
增量阶段重点检查任务状态、同步延迟和错误。延迟持续增长时，排查大事务、集中批处理、网络异常，以及目标端约束冲突、锁等待和资源瓶颈。
同步延迟为 0 秒是追平信号。
六、使用 NineData 验证数据一致性
1. 开启数据对比
在任务预检查阶段勾选「开启数据一致性对比」。
- 仅全量或结构加全量任务，在全量完成后启动对比；
- 本文采用的结构、全量、增量组合任务，在增量首次追平、延迟为 0 秒后启动相应对比。
发现差异后，先确认复制进度、过滤规则、类型转换和目标端额外写入，再审核修复 SQL，执行后重新验证。
2. 结构和增量校验边界
MySQL→OceanBase MySQL 不支持结构对比，因此字段、精度、默认值、主键、索引和分区需要人工审核。
MySQL→OceanBase MySQL 链路同时支持全量对比，增量对比不能单独开启，需与全量或快速对比同时启用；开启后，NineData 会对增量复制捕获的变更记录进行持续校验，而非只能做一次性的全量数据核对。
3. 补充业务校验
最终割接前，建议同时核对行数、金额汇总、状态分布、关键主键和最近变更记录。
|------------------------------------------------------------------------------------|
| Plain Text SELECT COUNT(*) AS row_count, SUM(amount) AS total_amount FROM orders; |
|-------------------------------------------------------------------------------|
| Plain Text SELECT status, COUNT(*) AS row_count FROM orders GROUP BY status; |
两端查询采用相同业务范围。大表按主键或时间区间分批执行。
金额汇总一致不能排除明细相互抵消的错误，因此关键业务应结合记录级对比和明细抽查。
源端持续写入时，两次查询的读取时间不同会形成暂时差异。最终验收应在停写、CDC 追平后执行。
七、生产割接与回退建议
以下流程用于组织项目实施，具体停写窗口和验收标准由业务团队在演练后确定。
割接前
- 完成目标 DDL 和非表对象核对；
- 确认全量完成、CDC 正常；
- 处理数据对比差异；
- 完成应用兼容性和性能测试；
- 准备连接切换、业务验收和回退步骤。
割接窗口
- 停止 MySQL 应用、定时任务及外部程序写入。
- 等待 NineData 增量追平。
- 检查日志，完成最终数据与业务校验。
- 将应用连接切换到 OceanBase。
- 验证查询、写入、事务和核心接口。
- 观察业务错误率、响应时间及数据库资源。
回退必须处理切换后的新数据
应用切换后，OceanBase 会产生新增、更新和删除变化。直接把连接改回 MySQL，会造成数据遗漏或业务分叉。
回退方案必须明确：
- 触发条件及停写方式；
- OceanBase 新变化的回补方法；
- 反向链路或补偿程序的演练结果；
- 回补后的数据校验；
- 恢复业务的批准和执行责任人。
保留原 MySQL 只是回退准备的一部分。完成新数据处理和一致性验证，才能恢复原库写入。
八、上线验收清单
NineData 将 MySQL→OceanBase MySQL 的结构、全量、增量复制和数据对比组织在统一任务中，减少迁移工具之间的衔接工作。生产切换以全量完成、增量追平、数据校验和应用验收为依据，同时保留经过演练的回退路径。需注意，社区版用户需使用 V4.7.0 及以上版本。
在此基础上，NineData 的可视化操作界面是其区别于命令行工具和脚本拼装方案的核心优势之一。建任务、选对象、配映射、设过滤条件均在控制台内完成，无需编写脚本或依赖个人经验。迁移过程中，复制延迟、任务状态、吞吐量等指标在同一界面实时呈现，异常时触发告警，减少在多个监控工具之间切换的成本。数据对比结果也直接回写到任务视图中，验收阶段无需额外搭建校验流程，对比报告本身即可作为切换决策的书面依据。简言之，可视化的价值不在于"好看"，而在于把迁移链路中原本分散的配置、监控、验证动作收拢到一个可操作、可追溯的界面里，降低团队协作中的信息损耗和操作风险。