去年Q3，某金融科技公司的核心交易库到了生死线。存储用了87%，查询延迟从12ms飙到400ms，DBA团队连续3周凌晨被告警叫醒。更麻烦的是：业务方说"停1分钟，损失8位数"。
这种场景下，常规方案是"深夜窗口期+停机迁移"，但25TB数据、每秒2.3万笔交易，窗口期根本不够用。工程师Vadim的解法，是把迁移拆成一场"热切换手术"——让新旧数据库同时跑，像换轮胎时车还在开。
第一阶段：把"大爆炸"切成"微创手术"
Vadim团队最初评估过AWS DMS（数据库迁移服务），但测试发现：全量加载阶段锁表时间超过业务容忍上限。他们最终选了一条更累但更稳的路——自研双写+增量同步。
核心架构不复杂：应用层加一层抽象，写操作同时落旧库（PostgreSQL 11）和新库（PostgreSQL 15）。读操作先走旧库，新库只验证数据一致性。这套双写逻辑用6天写完，代码量不到800行，但压测跑了47轮。
关键决策：双写阶段不追求实时强一致，而是保证"最终一致+可回滚"。 每笔写操作生成全局单调递增的序列号，新旧库各自独立消费。如果新库挂了，切回旧库只需改配置，数据零丢失。
双写跑了11天，期间新库追上了23TB历史数据。但真正的坑在增量同步——业务有张流水表，单表6.8亿行，每小时新增1200万条。Vadim用逻辑复制槽（logical replication slot）做流式同步，WAL（预写式日志）堆积超过500GB时自动触发告警人工介入。
第二阶段：验证比迁移更费时间
数据过去只是第一步。Vadim团队在灰度环境跑了8天的一致性校验，写了三套独立工具：
第一套按主键范围分段哈希比对，发现3处数据漂移——全是时区处理差异导致的毫秒级时间戳偏差，修复后重新同步。
第二套回放生产查询，对比新旧库执行计划和返回结果。抓到17条SQL在新库走错了索引，原因是PG15的统计信息收集策略变了，手动锁定执行计划后解决。
第三套最狠：直接镜像1%生产流量到新库，持续48小时。这期间新库承担了2300万次查询，P99延迟比旧库低34%，但暴露了连接池配置问题——默认max_connections=100在突发流量下直接打满，紧急调到400。
验证阶段累计发现31个问题，其中4个会导致切流后故障。 Vadim后来在复盘里写："如果当时急着切流，现在应该在找工作。"
第三阶段：切流当晚的"心跳时刻"
正式切流选在周六凌晨2点，业务低谷期。但真正的切换只花了4分钟——前面3周的工作，把风险压到了这4分钟里。
操作清单写了17步，每步有回滚指令和验证命令。第7步"关闭旧库写入"时，监控显示有3个连接迟迟不断开，是某个遗留的报表任务。团队临时决定：kill掉，业务方事后补数据，比延迟切换更可控。
切流后新库跑了15分钟，Vadim才允许团队去喝咖啡。这期间他盯着三个指标：复制延迟（必须为0）、错误日志（必须为0）、业务方客服群（必须没投诉）。
结果：零停机，零数据丢失，查询延迟从400ms降到89ms。但Vadim在内部文档里补了一句："下次这种项目，应该直接申请两个月的buffer，而不是三周。"
这套方法能复用吗？
双写架构的代价很明显：应用层改造成本、双份存储开销、一致性校验的人力投入。Vadim算过账：如果数据量低于5TB，或者能容忍2小时停机，用云厂商的托管迁移服务更划算。
但超过10TB、且业务连续性要求极高的场景，自研双写几乎是唯一解。国内某头部支付公司2022年做过类似迁移，他们的版本更激进——用Raft协议做三副本同步，切流时可以做到"用户无感知"到连工程师自己都找不到切换时间点。
技术选型没有银弹。Vadim这套方案的核心假设是"应用层可控"，如果用的是第三方闭源系统，双写根本插不进去。他建议后来者先做三件事：摸清数据热力分布（冷热数据分离能降低70%同步压力）、压测验证回滚路径（比验证正向流程更重要）、和法务确认数据一致性SLA（有些行业丢1条记录就是事故）。
项目结束后，Vadim把完整方案开源在GitHub， starred数两周破千。但评论区最高赞的反馈来自一位DBA："看完更确信了——这种项目能成，70%靠人，30%靠技术。你们团队凌晨3点还能冷静执行kill连接的操作，这才是真护城河。"
现在的问题是：你的数据库迁移预案，经得起凌晨3点的突发状况吗？
热门跟贴