实现数据库不停服迁移是个高难度动作，但通过精心设计和工具辅助完全可以做到。核心思路是 保持服务可用性的同时逐步完成数据迁移和流量切换。以下是我在实践中验证过的几种主流方案，各有适用场景：

核心方案一：双写 + 数据同步 + 流量切换 (最常用且可靠)

1. 阶段一：双写预热 (零停机)

   • 修改应用代码：同时写入旧库和新库，但读取仍走旧库。

   • 部署增量数据同步工具 (如 Canal, Debezium, DTS) 将旧库的历史数据+实时变更同步到新库。

   • 关键点：处理同步延迟、冲突解决（以新库或旧库为准？通常以应用双写为准）、幂等写入。

2. 阶段二：数据校验与追平

   • 用工具对比新旧库数据一致性（如 pt-table-checksum, 自研脚本）。

   • 修复差异数据，确保新旧库最终一致。

3. 阶段三：读流量灰度切换

   • 将部分读流量切到新库（按用户ID、业务模块等维度灰度）。

   • 监控新库性能及错误日志。

4. 阶段四：写流量切换 & 停旧写

   • 关闭应用向旧库的写入，只写新库。

   • 读流量完全切至新库。

   • 观察稳定性（建议选低峰期操作）。

5. 阶段五：下线旧库

   • 确认无残留流量后，停用旧库。

✅ 优势：平滑安全，回滚简单（切回旧库即可） ⚠️ 注意：双写可能增加延迟；需处理数据冲突（如唯一键冲突）

方案二：基于数据库日志的增量同步 (适合异构迁移)

1. 全量迁移：用工具导出旧库快照导入新库（业务低峰期操作）。

2. 增量同步：

   • 开启日志解析（MySQL binlog / PostgreSQL WAL），实时同步增量数据到新库。

   • 应用无需改造，持续写入旧库。

3. 切换时刻：

   • 暂停应用（秒级停机）→ 确保最后一批日志同步完成 → 切换DNS/配置指向新库 → 重启应用。

4. 回退方案：若新库异常，切回旧库并补偿增量数据。

✅ 优势：应用侵入性小，适合大表迁移 ⚠️ 注意：切换时有秒级停机；需严格校验数据一致性

方案三：使用数据库代理层 (如ShardingSphere, Vitess)

1. 引入代理中间件：应用连接代理，代理管理底层数据库。

2. 迁移过程：

   • 代理配置双数据源（旧库+新库）。

   • 代理将写请求转发到新旧库（类似双写）。

   • 通过代理完成读流量灰度切换。

3. 完成迁移：停用旧库路由，移除旧库配置。

✅ 优势：业务代码无感知，切换流程标准化 ⚠️ 注意：代理本身需高可用部署；可能成为性能瓶颈

关键通用技术点

1. 数据一致性校验

   • 全量校验：对比行数、Checksum值

   • 实时校验：同步消费Binlog对比差异

   • 工具推荐：pt-table-sync, DataX, 自研脚本

2. 流量切换策略

   • 按比例放量：1% → 10% → 50% → 100%

   • 按业务维度切：非核心业务优先

   • 蓝绿部署 + 负载均衡器控制流量

3. 回滚预案

   • 旧库保持只读至少24小时

   • 准备一键回切脚本（DNS/配置中心）

   • 回切后数据补偿机制（如从新库反向同步）

4. 监控告警

   • 新旧库延迟监控（Seconds_Behind_Master）

   • 新库性能指标（CPU/连接数/慢查询）

   • 业务错误日志关键字报警

方案选型建议

务必规避的坑

1. 未做充分数据校验 → 切换后数据错误

2. 忽略时区/字符集差异 → 乱码或时间错误

3. 外键约束未处理 → 同步中断

4. 切换后未关闭旧库写入 → 数据分裂

5. 未压测新库性能 → 上线后雪崩