ShardingSphere 的迁移限制

理解迁移的限制条件与掌握其功能同等重要！这份「迁移限制」文档是规避生产事故的关键参考。以下是深度解析与应对建议：

---

🚧 核心限制分类及应对策略

⚠️ 1. 数据源与数据库兼容性限制

限制项	根本原因	规避方案
仅支持 MySQL/PostgreSQL/Oracle	CDC 实现依赖数据库日志协议	其他数据库需改造： - 使用 Canal/Debezium 等中间件转接 - 开发定制化插件
云数据库特殊权限要求 (如 AWS RDS)	云平台 binlog 访问控制	预配专属账号并授权： GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
MySQL 必须启用 binlog	增量同步基础	检查配置： SHOW VARIABLES LIKE 'log_bin'; → 必须返回 ON
PostgreSQL 需 wal_level=logical	逻辑解码前置条件	修改配置并重启： ALTER SYSTEM SET wal_level = logical;

---

🧩 2. 表结构与元数据限制

限制场景	风险	解决方案
无主键/唯一键表	增量同步无法定位变更行	前置检查+改造： - 迁移前为表添加逻辑主键 - 使用 ALTER TABLE ADD COLUMN __mig_id BIGINT AUTO_INCREMENT
异构表结构迁移 (源库与目标分片表结构不同)	字段映射失败	结构预对齐： - 使用 CREATE SHARDING TABLE RULE 提前定义目标表结构 - 通过 columnMapper 配置字段转换
分片键非源表字段	数据路由失败	业务改造： - 增加分片键字段并回填历史数据 - 使用默认分片算法 NONE (单库路由)
ENUM/SET 类型字段	跨数据库类型兼容性问题	类型转换： - 目标库改为 VARCHAR + 应用层校验 - 定制化类型处理器

---

⚡ 3. 迁移过程性能限制

瓶颈点	影响	调优手段
单线程全量迁移	大数据表迁移缓慢	分片并行化： 配置 shardingSize=1000000 启用分片迁移 (需目标表有空分片)
binlog 单线程解析	高并发写入导致同步延迟	纵向扩容： - 升级 Proxy 节点 CPU - 调整 binlog-parser-threads (需停机)
网络带宽不足	迁移时间不可控	分层迁移： - 先迁热数据（最近N个月） - 冷数据离线备份后单独导入
目标库写入瓶颈	增量同步积压	批量提交优化： loaderBatchSize=5000 maxTransactionSize=10000

---

🔒 4. 一致性与事务限制

关键约束	后果	设计应对
大事务原子性丢失 (如 10w 行 update)	部分成功导致数据分裂	业务拆分： - 将事务拆为≤1000行/批次 - 启用 chunk-size=1000 自动分片
迁移期间 DDL 操作	表结构变更导致 CDC 中断	流程封禁： - 迁移前锁定 schema - 用 pt-online-schema-change 提前完成 DDL
全局唯一索引冲突	分片间主键冲突	分布式 ID： - 提前配置 Snowflake 或 UUID 生成策略 - 源表主键增加分片后缀
跨库外键失效	关联数据可能分属不同物理库	业务解耦： - 迁移前删除外键约束 - 应用层实现数据一致性

---

🌐 5. 分布式环境特有限制

复杂场景	挑战	ShardingSphere 方案
迁移过程中扩缩容	分片规则变更导致路由错乱	流程冻结： - 迁移任务启动后锁定集群拓扑 - 通过 CLUSTER FREEZE 禁止配置变更
多活数据库双向同步	数据回环冲突	标记过滤： - 启用 transactional-message=true - 添加 __mig_src 来源标记
异构迁移 (如 MySQL→PgSQL)	数据类型/函数不兼容	双写层转换： - 使用 SQL-Translator 插件 - 配置 dataTypeMapper 映射规则
迁移后存储过程失效	分片库不支持跨库存储过程	业务重构： - 将存储过程拆分为微服务 - 使用 ShardingSphere-Federate 查询

---

🛡️ 生产环境避险清单

必做检查项 (Pre-Migration Checklist)

1. 主键验证

   -- 检查无主键表
   SELECT t.table_schema, t.table_name
   FROM information_schema.tables t
   LEFT JOIN information_schema.key_column_usage k 
     ON t.table_schema = k.table_schema AND t.table_name = k.table_name
   WHERE k.constraint_name IS NULL 
     AND t.table_type = 'BASE TABLE'
     AND t.table_schema NOT IN ('mysql','sys');
   

2. 大事务扫描

   -- 监控事务大小 (MySQL)
   SELECT t.trx_mysql_thread_id, t.trx_rows_modified
   FROM information_schema.INNODB_TRX t
   WHERE t.trx_rows_modified > 10000;
   

3. binlog 配置验证

   SHOW GLOBAL VARIABLES WHERE 
     Variable_name IN ('log_bin','binlog_format','binlog_row_image');
   -- 必须输出: 
   -- log_bin = ON  
   -- binlog_format = ROW  
   -- binlog_row_image = FULL
   

---

💡 终极建议：影子验证法

在正式迁移前，通过影子表进行全流程验证：

graph LR
    A[生产源库] -->|全量+增量| B[影子分片集群]
    B --> C{校验通过？}
    C -->|是| D[正式迁移]
    C -->|否| E[调整方案]

操作步骤：

1. 克隆生产库结构创建影子库
2. 配置相同的分片规则到影子环境
3. 执行完整迁移流程并压测
4. 对比 生产库 vs 影子分片库 的数据一致性+性能指标

---

📜 总结：限制的本质是设计指南

ShardingSphere 的迁移限制实则是分布式数据库的最佳实践指引：

• 主键约束 → 推动良好的表设计
• 禁用 DDL → 强调变更管理流程
• 大事务拆分 → 微服务架构对齐
• 外键移除 → 引导应用层一致性实现

记住：

每一次限制突破，都是架构升级的契机。
下一站建议研究：弹性扩缩容实战案例