针对 1亿级数据量的MySQL到OB数据库不停机迁移，需结合全量迁移+增量同步+最终校验的三段式方案，以下是基于 OB Data Copy 和 DataX 的详细实现路径（含工具选型对比、操作步骤、风险控制）。

一、方案核心设计原则

1. 零业务中断：迁移过程中MySQL持续提供读写，仅在最终同步阶段暂停写入（建议控制在5分钟内）。
2. 数据一致性：通过全量快照+增量日志确保迁移前后数据一致。
3. 性能隔离：避免迁移任务对生产库造成IO/CPU压力。
4. 可回滚：保留迁移过程中的备份，支持异常时快速恢复。

二、OB Data Copy 不停机迁移方案（推荐OB生态）

1. 全量迁移（离线阶段）

• 操作：

# 导出MySQL全量数据（业务低峰期执行）
obdcp export mysql \
--host=mysql-host \
--port=3306 \
--user=xxx \
--password=xxx \
--database=source_db \
--tables="table1,table2" \
--output-dir=/data/export  # 压缩格式为OB专用格式

# 导入OB数据库（并行导入提升速度）
obdcp import oceanbase \
--oceanbase-config=ob_cluster.conf \
--input-dir=/data/export \
--parallel=16  # 根据OB集群性能调整

• 优化点：
• 对大表做分块导出（--split-size=10GB），避免单文件过大。
• 关闭OB目标表的索引和约束（导入后重建），提升写入速度。
• 监控MySQL的慢查询，确保导出不影响业务。

2. 增量同步（在线阶段）

• 原理：通过OB Data Copy的Binlog订阅功能捕获MySQL变更（需开启MySQL Binlog，格式ROW）。
• 操作：

# 启动增量同步（全量完成后立即执行）
obdcp sync mysql2ob \
--source-binlog-file=mysql-bin.000001 \  # 全量导出时的Binlog位点
--source-binlog-pos=12345 \
--ob-config=ob_cluster.conf \
--database=source_db \
--tables="table1,table2" \
--check-interval=60s  # 每60秒校验数据一致性

• 关键监控：
• 延迟监控：obdcp status 查看增量同步延迟（需＜500ms）。
• 冲突处理：对唯一键冲突表，配置--on-duplicate=update自动处理。

3. 最终切换（分钟级停机）

• 步骤：

1. 暂停业务写入（如电商凌晨2:00-2:05）。
2. 捕获最后一批增量：等待OB Data Copy同步完所有Binlog（show sync status确认无延迟）。
3. 数据校验：

obdcp check data \
--source-dsn="mysql://xxx:xxx@mysql-host:3306/source_db" \
--target-dsn="obclient://xxx:xxx@ob-cluster/source_db" \
--tables="table1,table2" \
--mode=full  # 逐行对比

4. 业务切流：修改连接配置指向OB数据库，验证读写。
5. 回滚准备：保留MySQL Binlog至迁移后72小时，以防异常。

三、DataX 不停机迁移方案（通用场景）

1. 全量迁移（DataX+分库分表）

• 配置示例（datax/job/mysql2ob.json）：

{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "splitPk": "id",  # 按ID分块，避免锁表
            "connection": [{
              "table": ["user"],
              "jdbcUrl": ["jdbc:mysql://mysql-host:3306/source_db"]
            }]
          }
        },
        "writer": {
          "name": "oceanbasewriter",
          "parameter": {
            "batchSize": 10000,  # 批量提交减少网络IO
            "preSql": ["delete from user"]  # 全量模式先清空目标表
          }
        }
      }
    ]
  }
}

• 优化：对1亿级表采用多任务并行（如拆分为100个分片同时导出），控制单任务数据量＜100万。

2. 增量同步（DataX+Canal）

• 架构：

MySQL Binlog → Canal（监听） → RocketMQ（队列） → DataX（消费消息写入OB）

• 操作：

1. 部署Canal解析MySQL Binlog，过滤DDL只同步DML。
2. DataX通过自定义Reader从消息队列拉取增量数据（示例：CanalJSON格式解析）。
3. 对OB目标表开启临时索引（仅在同步阶段加速写入）。

3. 最终切换（同OB Data Copy方案，但需额外处理）

• 数据校验：使用DataX的DataXCheck工具对比行数+MD5（大表抽样对比）。
• 冲突处理：对时间戳字段，优先以OB的sysdate()为准（需业务兼容）。

四、通用风险控制策略

1. 流量控制：

• OB Data Copy：设置--max-rate=200MB/s（避免占满MySQL带宽）。
• DataX：配置"speed": {"byte": 104857600}（限制100MB/s）。

• 影子库测试：
• 迁移期间将1%业务流量路由到OB（需应用支持AB测试），提前发现兼容性问题。
• 异常回滚：
• 每小时备份MySQL全量数据+Binlog位点，通过obdcp rollback或DataX重跑任务恢复。
• 监控指标：

指标	阈值	工具
全量迁移速度	≥5000行/秒	obdcp stats / DataX日志
增量延迟	＜1秒	Canal/OB监控
MySQL CPU利用率	＜70%	Prometheus
OB写入TPS	＜集群峰值80%	OB控制台

五、方案对比与选择建议

维度	OB Data Copy方案	DataX方案
迁移速度	快（OB原生协议，并行度高）	中（通用接口，需额外优化）
一致性	强（Binlog位点精准同步）	中（依赖Canal解析准确性）
复杂度	低（单工具完成全量+增量）	高（需集成Canal、消息队列）
适用场景	OceanBase用户，追求极简操作	多源异构迁移，需兼容非OB数据库

推荐：优先选择OB Data Copy方案（尤其适合纯OB生态），若涉及多数据源或复杂数据转换，使用DataX+Canal方案。

六、典型时间轴（1亿数据）

阶段	操作内容	耗时	业务影响
全量迁移	导出+导入（夜间低峰）	6-8小时	读性能轻微下降
增量同步	Binlog实时同步	持续运行	无
最终切换	暂停写入+校验+切流	3-5分钟	短时间停机
验证期	影子库监控+全量校验	24小时	无

通过此方案，可将总停机时间压缩至5分钟以内，满足绝大多数业务的不停机迁移需求。

优网科技秉承"专业团队、品质服务" 的经营理念，诚信务实的服务了近万家客户，成为众多世界500强、集团和上市公司的长期合作伙伴！

优网科技成立于2001年，擅长网站建设、网站与各类业务系统深度整合，致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设（品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、DIY体验、720全景展厅及3D虚拟仿真）、移动端应用（手机站、APP开发）、微信定制开发（微信官网、微信商城、企业微信）、微信小程序定制开发等一系列互联网应用服务。