Apache ShardingSphere 的核心能力：数据迁移

Apache ShardingSphere 的核心能力：数据迁移（特别是从单机数据库到分片集群的迁移）是分布式数据库改造中最关键且最具挑战性的环节之一。ShardingSphere 的「数据迁移」模块（scaling）正是为解决这一痛点而设计。

我们来深入解析这份文档的核心要点：

🎯 目标场景：无缝、安全的数据库水平扩展

• 核心需求：将单实例数据库中的数据迁移到 ShardingSphere 管理的分片集群中，并确保业务平滑过渡。
• 典型场景：
  • 业务增长导致单库性能/容量瓶颈，需水平拆分（分库分表）。
  • 现有非分片应用要接入 ShardingSphere 分片生态。
  • 分片集群需要调整分片策略（如增加分片数、修改分片键）。
• 核心挑战：迁移过程中如何保证数据一致性？如何最小化甚至消除业务停机时间？

🚀 ShardingSphere-Scaling 的核心能力

1. 全量迁移：将源库中的历史数据完整迁移到目标分片集群。
2. 增量迁移 (CDC)：在全量迁移过程中及之后，实时捕获源库的变更数据 (Change Data Capture)，并同步到目标集群，确保数据实时一致。
3. 数据一致性校验：迁移完成后，提供工具验证源库和目标集群的数据是否完全一致（支持行数对比、内容校验）。
4. 灵活启停 & 进度监控：允许暂停、恢复迁移任务，并提供详细的进度和指标监控。
5. 自动化 & 集成化：与 ShardingSphere-Proxy/JDBC 紧密集成，提供 CLI、DistSQL 等管理接口。

🔧 迁移核心组件

1. 迁移任务 (Job): 用户发起的一个迁移操作单元。
2. 任务进度 (Inventory / Incremental): 跟踪全量迁移(inventory)和增量迁移(incremental)的完成情况。
3. 数据通道 (Channel): 负责源库到目标库的数据传输（全量 + 增量）。
4. CDC 组件: 捕获源库的 binlog (MySQL) 或 WAL (PostgreSQL) 等变更日志。
5. 数据一致性校验器 (DataConsistencyChecker): 执行校验逻辑。

📌 两种迁移模式

ShardingSphere 支持两种迁移策略，适应不同业务容忍度：

1. 停机迁移 (适合容忍分钟级中断)

• 流程：
  1. 业务停机，停止写入源库。
  2. 执行全量迁移（源库 -> 目标分片库）。
  3. 执行增量迁移（迁移期间源库产生的变更）。
  4. 数据一致性校验。
  5. 切换应用连接：指向 ShardingSphere-Proxy/JDBC。
  6. 业务恢复。
• 优点：逻辑简单，保证强一致性。
• 缺点：有业务停机时间。

2. 不停机迁移 (适合要求 7x24 运行)

• 流程：
  1. 启动全量迁移：后台开始拷贝历史数据。
  2. 启动增量迁移：实时捕获并同步全量迁移开始后源库的所有变更。
  3. 业务双写 (可选但推荐)：在某个时间点，应用开始同时写入源库和 ShardingSphere 管理的目标库。这是一个关键的安全网，确保即使切换失败也能回滚。
  4. 数据追平 & 校验：
     • 等待全量迁移完成。
     • 持续增量同步，直到增量同步延迟接近 0。
     • 执行最终数据一致性校验。
  5. 流量切换：
     • 短暂暂停对源库的写入（秒级）。
     • 确认增量队列完全消费完毕（确保最后一点变更同步完成）。
     • 将应用读写流量完全切换到 ShardingSphere-Proxy/JDBC。
     • 停止增量同步任务。
  6. 清理双写 (如果启用了)：停止应用对源库的写入。
• 优点：业务几乎无感知（仅在最终切换时有秒级写停顿）。
• 缺点：流程更复杂，需要处理双写、数据冲突等问题（ShardingSphere 通过精确的 CDC 顺序同步来避免逻辑冲突）。

📐 关键配置项 (以 Proxy 的 server.yaml 为例)

rules:
  - !MIGRATION
    dataSources:
      source_ds: # 源数据库配置 (单机库)
        url: jdbc:mysql://source_host:3306/source_db?serverTimezone=UTC
        username: root
        password: source_pwd
        ...
      target_ds: # 目标数据库配置 (通常是 ShardingSphere 管理的逻辑数据源名)
        url: jdbc:mysql://proxy_host:3307/sharding_db?serverTimezone=UTC
        username: proxy_user
        password: proxy_pwd
        ...
    target: target_ds # 默认目标数据源
    blockQueueSize: 10000 # 迁移通道队列大小 (影响吞吐)
    workerThread: 40 # 迁移工作线程数
    clusterAutoSwitch: true # 是否在集群模式下自动切换任务协调节点 (高可用)

🔍 使用 DistSQL 管理迁移 (核心操作)

迁移任务主要通过 DistSQL (分布式 SQL) 进行管理，非常直观：

1. 准备迁移源配置 (REGISTER STORAGE UNIT / CREATE DATA SOURCE):

   REGISTER STORAGE UNIT source_ds (
       URL="jdbc:mysql://source_host:3306/source_db",
       USER="root",
       PASSWORD="source_pwd",
       PROPERTIES("maxPoolSize"=50)
   );
   

2. 创建迁移任务 (MIGRATE TABLE):

   MIGRATE TABLE source_db.t_order INTO sharding_db.t_order; -- 简单迁移单表
   -- 或带分片规则迁移 (推荐)
   MIGRATE TABLE source_db.t_order (id BIGINT, user_id INT, ...) INTO sharding_db.t_order_$->{0..1} (id, user_id, ...) SHARDING BY (user_id MOD 2);
   

3. 查看任务列表 (SHOW MIGRATION LIST):

   SHOW MIGRATION LIST;
   

4. 查看任务状态/进度 (SHOW MIGRATION STATUS 'jobId'):

   SHOW MIGRATION STATUS 'j01010e501b498ed1bdb2c11d5d2530c0';
   

5. 启停任务 (START/STOP MIGRATION 'jobId'):

   STOP MIGRATION 'j01010e501b498ed1bdb2c11d5d2530c0'; -- 暂停
   START MIGRATION 'j01010e501b498ed1bdb2c11d5d2530c0'; -- 恢复
   

6. 数据一致性校验 (CHECK MIGRATION 'jobId' BY TYPE (name='CRC32_MATCH')):

   CHECK MIGRATION 'j01010e501b498ed1bdb2c11d5d2530c0' BY TYPE (name='CRC32_MATCH');
   -- 查看校验结果
   SHOW MIGRATION CHECK STATUS 'jobId';
   

7. 完成任务 (切换) (COMMIT MIGRATION 'jobId'):

   COMMIT MIGRATION 'j01010e501b498ed1bdb2c11d5d2530c0'; -- 确认迁移完成，切换完成
   

8. 回滚任务 (如果需要) (ROLLBACK MIGRATION 'jobId'):

   ROLLBACK MIGRATION 'j01010e501b498ed1bdb2c11d5d2530c0';
   

⚠️ 重要注意事项 & 最佳实践

1. 源库要求：
   • MySQL: 必须开启 binlog (log_bin=ON)，使用 ROW 模式 (binlog_format=ROW)，并设置 binlog_row_image=FULL。用户需有 REPLICATION SLAVE, REPLICATION CLIENT 权限。
   • PostgreSQL: 需配置逻辑解码输出插件 (如 pgoutput, wal2json)，用户需有 REPLICATION 权限。
2. 主键/唯一键：迁移表必须有主键或非空唯一索引，这是增量同步精确定位变更行的基础。
3. 性能影响：
   • 全量迁移：会占用源库和目标库的 IO 和 CPU。建议在业务低峰期启动，并调整 workerThread 和 batchSize 参数。
   • 增量同步：对源库影响较小（读取 binlog），但对目标库有写入压力。
4. 网络与资源：确保源库、目标库、ShardingSphere-Proxy 之间网络畅通且带宽充足。迁移节点（运行 Proxy 的机器）应有足够的内存和 CPU 处理数据流。
5. 目标表结构：务必提前在 ShardingSphere 中配置好正确的分片规则。迁移过程会根据目标逻辑表的元数据将数据写入正确的物理分片。
6. 严格测试：在预发布环境进行全流程演练！测试不同数据量、不同表结构、异常中断恢复等场景。
7. 监控告警：密切监控迁移任务状态、延迟时间 (incremental_idle_seconds)、错误日志。设置关键指标（如延迟过大、任务失败）的告警。
8. 双写过渡期：对于不停机迁移，双写期是重要的安全缓冲。确保应用能正确处理双写逻辑（或借助 ShardingSphere 的读写分离/影子库规则辅助）。

🚀 学习建议

1. 动手实验：在测试环境部署 MySQL + ShardingSphere-Proxy。模拟一个 t_order 表（带数据）迁移到分片环境 (t_order_0, t_order_1)。
2. 体验两种模式：
   • 执行一次停机迁移，感受其流程。
   • 执行一次不停机迁移，在迁移过程中持续对源库进行增删改操作，观察数据如何被同步到目标分片库。最终切换后验证数据一致性和业务连续性。
3. DistSQL 练习：反复使用上述提到的 DistSQL 命令，熟悉任务管理流程。理解 jobId 的作用。
4. 观察日志：启动迁移时，查看 Proxy 日志和源库的 binlog 位置变化，理解内部机制。
5. 参数调优：尝试调整 blockQueueSize, workerThread, batchSize (在 DistSQL MIGRATE TABLE 的 PROPERTIES 中设置) 等参数，观察对迁移速度的影响。
6. 研究一致性校验算法：了解 CRC32_MATCH, DATA_MATCH 等校验类型的原理和适用场景。

📚 总结

Apache ShardingSphere 的数据迁移 (scaling) 模块提供了：

• 自动化流程：全量 + 增量 + 校验一体化。
• 两种迁移策略：满足不同业务停机容忍度（停机迁移 vs 推荐的不停机迁移）。
• DistSQL 驱动：通过 SQL 管理迁移任务，简单直观。
• 数据一致性保障：严格的 CDC 同步和校验机制。
• 弹性与可控性：任务启停、进度监控、参数调整。