零停机迁移一个 10TB 数据库：计划是什么？

Question

IT Interview Practice · Accepted Answer

**同时向旧库和新库双写，在后台回填（backfill）历史数据，用 CDC 追上尾部，通过影子读（shadow reads）验证，然后原子地切换读——在每一步都留有回滚路径。**你从不让应用停机；你让两个数据库并行运行，直到新库被证明完全一致，然后切换（cut over）。

## 架构

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## 工作原理

1. **双写。**应用把每个变更同时写入 OLD 和 NEW。从现在起新行保持同步；只缺历史数据。
2. **回填（Backfill）。**一个后台作业分批复制历史行（限流以保护生产）。使用 `INSERT ... ON CONFLICT DO NOTHING`，使其幂等且可安全重跑。
3. **CDC 追赶。**双写可能漏掉在开启期间写入的行。**Debezium** 流式传输 OLD DB 的 WAL/binlog，重放每个变更，填补回填无法覆盖的缺口。
4. **影子读（Shadow reads）。**在读 OLD 的同时并行读 NEW，**比较结果**，并输出一个差异指标。长期零差异 = NEW 值得信任。
5. **切换（Cutover）。**翻转一个特性开关（feature flag），使读（然后是写）转向 NEW。这是一次配置变更，而非一次部署——瞬时完成，且**可通过翻回来回滚**。

## 面试视角

面试官想知道**你如何保证无数据丢失和无停机**，以及你是否有**回滚**。好的回答会提到双写；出色的回答会加上**用 CDC 捕获竞态窗口**、**用影子读在信任之前先验证**，以及**原子的、可逆的开关翻转**。经典陷阱是"回填后直接切换"而不做验证——你会在用户遇到不匹配之后才发现，且无路可退。

## 权衡与故障

- **双写一致性。**如果 NEW 写入失败而 OLD 成功，二者会分叉。让 OLD 作为权威，并让 CDC 修复 NEW，而不是让用户的请求失败。
- **成本与复杂度。**同时运行两个数据库 + CDC + 回填既昂贵又运维繁重——只有对大型、关键的存储才值得。
- 迁移期间的 **Schema 变更**会成倍放大风险；在切换前冻结 schema。
- **回填负载。**未限流的回填会让生产 I/O 饱和并造成中断——与目标背道而驰；分批并限速。
- **回滚窗口。**切换后继续双写（现在是 NEW→OLD）数天，以便在潜伏的 bug 浮现时能翻回来。之后才下线 OLD。
- **何时不该用：**一个有维护窗口的小型 DB 不需要这些——一次 30 分钟的 `pg_dump`/恢复比一条 CDC 管道更简单、更安全。

架构

工作原理

面试视角

权衡与故障

相关问题