对我来说，就是那个夜晚（其实连续了很多个夜晚），我们把超过10亿条记录从旧数据库迁移到新数据库……

全程没有一秒钟的停机。

我们迁移的是关键金融数据——支付、订单、账本。一旦出错，客户会亏钱，仪表板会崩溃，信任会在一夜之间蒸发。

旧数据库一直兢兢业业地为我们服务着，但规模扩大改变了一切。

• 以前只需几毫秒就能完成的查询，现在却要耗费几秒钟

• 批处理任务（比如结算）有时候要跑好几个小时

• 我们已经做了垂直扩展（更强的硬件），也做了水平扩展（只读副本），但还是不够

• 模式僵化，每一个新功能都像做外科手术

数据库记录数量突破10亿，不堪重负。业务不断增长，停机时间是不可接受的。我们别无选择：迁移。

但，这么大的数据量，怎么做到不停机迁移？

我们从“冷数据”入手，也就是那些不再更新的旧交易数据。

数据库内部发生了什么？

• 如果你尝试导出十亿行数据，数据库会占用巨大的缓冲区，可能会溢出到磁盘，然后崩溃

• 每向新数据库中插入一行数据都会更新索引，这会减慢整个数据库的运行速度

• 外键约束意味着每次插入数据都必须检查其他表

我们怎么做的：

• 将表格拆分成按主键范围分块（例如，ID 1–5M、5M–10M）

• 加载期间禁用二级索引和约束

• 并行运行多个工作进程

• 每个数据块处理完毕后，我们运行了校验和确保数据完全匹配

这办法不花哨，但管用。

复制旧数据很容易，真正的挑战在于如何应对不断增长的新流量。

试想一下：在我们复制旧数据的同时，每秒仍有数千笔新的付款信息涌入。如果我们不记录这些信息，新的数据库就会始终滞后。

我们怎么做的：

• 修改了应用程序，使其能够进行双重写入：每次插入新数据都会同时写入旧数据库和新数据库。

• 如果新的数据库写入失败，则该事件会被推送到Kafka 重试队列中。

• 消费者反复尝试，直到成功为止。

• 我们通过给写入操作添加唯一ID标签，使写入操作具有幂等性。（因此，即使重试两次，也不会重复写入同一行。

为什么可行：

在PostgreSQL/MySQL这类关系库，每次插入先写WAL（预写日志）。我们利用了这一原理，确保至少在一个地方写入成功，并不断重试，直到两个数据库的结果一致为止。

现在旧库新库同步了。

但……我们能信新库吗？

我们的秘密武器：影子读。

• 客户仍然从旧数据库中读取数据

• 但在后台，每个查询都会默默地针对新数据库重复执行

• 我们比较了结果

我们的发现：

• 时区表现不同（TIMESTAMP WITHOUT TZvs WITH TZ）

• NULL在新数据库中，部分值变成了默认值

• 排序方式不同是因为排序规则（UTF-8 与 Latin1）不相同

这些问题测试环境永远抓不到，只有真实流量才能暴露，影子读给了我们几周时间修这些坑，客户毫无感知。

系统切换日就像在备战。

风险：

• 新数据库的缓冲池（缓存）是冷的，最初的几个查询可能会导致磁盘读写速度过快

• 指数可能尚未完全升温

• 后台任务（如自动清理/压缩）可能会导致 I/O 激增

我们的计划：

• 通过运行合成查询来预热数据库，加载索引和缓存

• 选凌晨4:30（流量最低）

• 启用功能标志后，读取操作开始转移到新数据库

• 为了安全起见，保持双写开启

前10分钟……

我们盯着Grafana仪表盘，像在看病人的心电图。

• 延迟？正常

• 错误率？平的

• 业务指标（支付、退款）？全绿

没人庆祝，我们怕得要死。

24小时后，曲线依旧平静，我们才敢笑。

如果问我什么救了我们，不是酷炫SQL，而是可观测性。

我们发现：

• 复制延迟（比主服务器慢几秒）

• 新数据库中出现死锁

• 缓存命中率（必须保持在 95% 以上）

• 影子读取导致的不匹配计数器

• 业务关键绩效指标（每分钟订单量、收入流量）

没有这些仪表盘，我们如同盲人摸象。

• 大爆炸快，但无法回滚

• 分阶段慢，但可逆

→ 我们选分阶段

• ETL流程更简单，但无法处理实时流量

• 双写操作难度更高，但更安全

→ 我们选择了双写操作

• 加载期间构建索引会降低所有操作的速度

• 先加载数据，后建立索引速度更快

→ 我们延迟了索引的创建

• 业务团队不停问：“你们就不能周末搞完？”

• DBA夜夜失眠，担心隐藏数据损坏

• 开发盯着Grafana，像父母守着生病孩子的心跳

切换成功那一刻，我们没有欢呼，只是沉默地看绿色曲线。

然后有人开了个玩笑：

我们笑了，笑得有点虚。

• 设计每个任务时都要确保其幂等性，因为你会重复执行某些操作

• 批量加载期间禁用索引和约束，稍后重建

• 使用双重写入和唯一 ID来避免重复写入

• 运行影子读取以捕获规划器/编码怪异之处

• 切换前务必预热缓存，否则你的延迟曲线图会像心脏病发作一样

• 监控内部情况（WAL、缓存、死锁），而不仅仅是应用程序指标

• 制定回滚计划，自信源于知道自己可以撤销操作

我们不仅仅是迁移了十亿条记录，我们认识到，数据迁移不是数据库问题，而是系统设计问题。

你不会一次性迁移十亿行数据。你会一次迁移一个安全批次，一次迁移一个 WAL 条目，一次迁移一个校验和。

这就是秘诀。

因为当你把迁移当作构建分布式系统来对待时，零停机时间就不是运气，而是设计的结果。