标签：#ShardingSphere #分库分表 #数据迁移 #高可用 #MySQL #架构设计
💀 前言：深夜 3 点的“停机维护”噩梦
传统的分库分表扩容方案（例如：2库 -> 4库）通常是这样的：
- 停机：发布公告，凌晨 0 点停止对外服务。
- 洗数据：跑一个巨大的脚本，把旧库数据 Hash 算出新路由，写入新库。
- 改配置：修改代码里的分片规则。
- 重启：祈祷数据没丢，服务正常。
这种“刀耕火种”的方式，风险极高，且随着数据量增大，停机时间会变得不可接受。
我们需要的是Online Migration (在线迁移)。
🏗️ 一、 核心原理：全量复制 + 增量追赶
ShardingSphere-Scaling 的迁移逻辑借鉴了 Redis 主从同步和 MySQL 主从复制的思想。它将迁移分为四个阶段。
不停机迁移流程图 (Mermaid):
🛠️ 二、 环境准备与避坑指南
在开始迁移前，必须检查你的 MySQL 配置。这是90% 的人翻车的地方。
1. Binlog 格式必须是 ROW
ShardingSphere 需要解析具体的字段值变化，STATEMENT格式是不行的。
-- 检查配置SHOWVARIABLESLIKE'binlog_format';-- 必须是 ROWSHOWVARIABLESLIKE'binlog_row_image';-- 必须是 FULL2. 表必须有主键
迁移引擎依赖主键进行切分（Range 切分）和去重。无主键表无法进行断点续传。
3. 部署模式建议
虽然ShardingSphere-JDBC也可以做 Scaling，但为了运维可视化和指令管理，强烈建议在扩容阶段**引入ShardingSphere-Proxy**。你可以把 Proxy 看作是一个增强版的 MySQL Server，我们通过连接它来执行迁移指令。
💻 三、 实战：使用 DistSQL 指挥迁移
ShardingSphere 5.x 引入了DistSQL (Distributed SQL)，让我们像操作数据库一样操作架构。
1. 准备新节点
假设我们现在的规则是ds_0，我们要扩容加入ds_1。
首先在 Proxy 中注册新的存储节点。
REGISTER STORAGE UNIT ds_1(URL='jdbc:mysql://192.168.1.200:3306/db_new?useSSL=false',USER='root',PASSWORD='password');2. 创建扩容任务 (MIGRATE)
这是一个魔法指令。你只需要告诉它：我要把t_order表应用新的分片算法。
-- 假设我们创建了一个新的分片策略 sharding_strategy_new (模 4)MIGRATETABLEt_orderINTOsharding_strategy_new;执行后，后台会自动启动 ElasticJob 任务，开始搬运数据。
3. 监控进度与一致性校验
在数据搬运过程中，你可以随时查看进度。
-- 查看进度 (Inventory: 全量阶段, Incremental: 增量阶段)SHOWMIGRATIONSTATUS;-- 只有当 Inventory 完成，且 Incremental 延迟极低时，执行校验-- 这一步会对比源端和目标端的 CRC32CHECKMIGRATION t_order;避坑：如果数据量极大，CRC32 校验也很耗时，可以配置采样率校验。
4. 停写切换 (COMMIT)
这是最激动人心的一刻。
当校验通过，且增量同步几乎没有延迟时，执行切换。
-- 这一步会自动加短暂的分布式锁，修改元数据，重置路由COMMITMIGRATION t_order;耗时：通常在毫秒级。用户端只会感觉到一次极其短暂的抖动（或重试），然后流量就瞬间切到了新的 4 库架构上。
⚠️ 四、 那些官方文档没写的“深坑”
- 触发器 (Trigger) 与 存储过程：
Scaling 模块通常只迁移数据（DML）和结构（DDL）。如果你的原表里有复杂的触发器，请务必手动在新库重建，Scaling 可能会忽略它们或导致冲突。 - 自增主键冲突：
如果从单库扩容到分库，原有的 MySQL 自增 ID 会失效（因为多库会重复）。
解决方案：在迁移前，业务代码必须先升级为Snowflake (雪花算法)生成 ID，确保全局唯一，然后再进行数据迁移。 - 时间时区问题：
确保所有 MySQL 节点的serverTimezone一致。否则 Binlog 解析出的时间戳和实际存入的时间可能会差 8 小时，导致增量同步数据错乱。
🎯 总结
分库分表扩容不再是“听天由命”的赌博。
通过ShardingSphere Scaling，我们将一次高风险的“运维操作”变成了一个可控的、可视化的“数据流转过程”。
| 方案 | 停机时间 | 复杂度 | 回滚难度 |
|---|---|---|---|
| 传统停机清洗 | 小时级 (随着数据量增加) | 低 (手写脚本) | 困难 (需恢复备份) |
| ShardingSphere Scaling | 毫秒级 (仅切换瞬间) | 中 (需配置 Server) | 简单 (STOP 任务即可) |
Next Step:
不管你现在需不需要扩容，先去检查你的生产库 Binlog 格式是不是ROW。如果是MIXED或STATEMENT，请在下一个维护窗口把它改过来，这是你未来能“平滑扩容”的救命稻草。
