凌晨两点，运维老张盯着屏幕上跳动的复制延迟数字，手心全是汗。数据库切换窗口只剩20分钟，全公司几千号人等着第二天早上正常登录系统。这种场景，但凡做过一次数据库迁移的人都懂——数据迁移本身不难，难的是怎么让业务毫无感知地完成切换。说白了，用户不会关心你用的是MySQL还是PostgreSQL，他们只关心自己的订单、余额、聊天记录还在不在，以及页面能不能正常打开。
零停机迁移这件事，圈里讨论了很多年，方案也翻来覆去就那几种：双写、基于日志的增量同步、灰度切换。但真正落地的时候，细节比方案本身重要得多。先别急着选工具，你第一件要做的事，是搞清楚自己的业务到底能不能接受短时间只读。很多团队嘴上说要零停机，实际上业务根本不允许任何一秒的写操作停顿，那思路就得完全换一条。
如果你的业务可以接受只读窗口，那事情简单不少。流程大概是：全量拷贝数据到新库，然后启动增量同步工具，比如用Debezium监听binlog，或者用DataX定期拉取增量。等两边数据追平了，把应用切换成只读模式，再等一波增量同步完成，然后把读写切到新库。整个过程里，只读窗口可以压缩到几秒甚至更短。这里有个坑，很多新手容易踩——全量拷贝的时候，千万别直接停掉旧库的业务写入。你得用在线热备份的方式，比如MySQL的mysqldump配合--single-transaction参数，或者用物理备份工具Percona XtraBackup，这样备份过程中业务照样写，不影响线上。
但如果你连几秒的只读窗口都接受不了，那就得上双写方案了。所谓双写，就是在迁移期间，应用层把写操作同时发给旧库和新库，读操作还是走旧库。等到两边数据完全一致了，再把读流量一点一点切到新库，摘掉旧库。这个方案的核心在于，你得有个靠谱的同步机制来保证两边数据最终一致。实际操作中，很多人会在应用里加一层抽象，写操作先落到本地消息队列，然后由消费者同时往两个库写。但这样有个麻烦——如果新库写入失败，你得回滚旧库的操作，否则两边数据就不一致了。所以更稳妥的做法是，旧库作为主库，新库通过binlog同步，应用层只往旧库写，同步由数据库层面完成。这样应用改动最小，风险也最低。
说到binlog同步，这里有个关键细节很多人忽略：binlog的格式。你要是用MySQL，binlog_format得设成ROW，不能用STATEMENT。因为STATEMENT记录的是SQL语句，同步到新库执行的时候，可能因为函数、存储过程、时间戳这些因素产生偏差。ROW模式记录的是每一行的实际变更，虽然日志量会大不少，但同步出来是精确的。另外，主键和唯一索引必须保证两边一致，否则同步过程一旦出现重复数据，整个链路就断了。我自己就栽过这个跟头——迁移的时候发现新库少了个唯一索引，结果同步任务跑了一半直接报错，半天时间全耗在排查数据冲突上。
工具选型方面，开源社区有不少现成方案。Debezium是目前用得最多的CDC框架，支持MySQL、PostgreSQL、SQL Server、Oracle这些主流数据库，它能监听binlog，把变更事件发到Kafka，你再写个消费者把变更落到目标库。这套链路好处是解耦，源库的增量数据先进消息队列，消费者按自己的节奏消费，压力大就扩消费者数量。但坏处也很明显——你得维护Kafka集群，运维成本上去了。如果团队规模不大，我更推荐直接用现成的同步工具，比如阿里开源的canal，专门针对MySQL，部署简单，配置也直观。PostgreSQL用户可以用pglogical或者Debezium的PostgreSQL connector，效果都不错。
还有一种思路，很多人没意识到——利用数据库自带的主从复制机制做迁移。比如你想从MySQL迁到TiDB，TiDB本身就兼容MySQL协议，而且支持从MySQL进行数据同步。这种情况下，你完全可以把TiDB当成一个MySQL的从库挂上去，等它追上主库的binlog位置，然后手动把主从关系断开，把应用切到TiDB上。这套操作跟平时做MySQL主从切换一模一样，团队里只要有人熟悉主从复制，上手就特别快。而且TiDB的扩容能力比单机MySQL强得多，切过去之后性能还能提升不少。
不过，不管选哪种方案，切换那一刻的流量切换策略才是整个项目成败的关键。我见过太多团队，数据同步搞了俩月，结果切换当天把所有流量一次性切过去，新库扛不住压力直接雪崩。正确的做法是分步切：先把一部分只读流量放到新库上，比如把后台报表查询、数据分析任务的连接串改到新库，观察一段时间，确认新库性能稳定、数据一致，再把读流量全部切过去。最后一步才是切写流量，这一步要选业务低峰期，并且要准备好回退方案——一旦新库出问题，立刻把写流量切回旧库。回退方案不是嘴上说说，你得提前写好切换脚本，甚至演练过几次，不然真出问题的时候，手忙脚乱只会更糟。
另外还有个容易被忽略的点——数据校验。同步完成不等于数据一致，你得有一套校验机制来确认两边数据完全对得上。简单粗暴的做法是，对每张表算出校验和，比如用CRC32或者MD5，然后对比两边的值。但大表这么干效率太低，更实用的办法是抽样校验加全量校验结合。全量校验可以放在业务低峰期跑，用类似pt-table-checksum这样的工具，它能一边校验一边不锁表。抽样校验则是在日常同步过程中随机挑一些主键，对比两边对应行的数据。校验发现不一致的时候，别慌，先看是不是同步延迟导致的，等延迟追平再校验一次，如果还不一致，那就得查同步任务是不是出bug了。
文章写到这里，我想起前阵子帮一个客户做迁移，他们之前用的是一个云厂商的数据库，因为成本问题想迁到自建的开源数据库上。整个过程折腾了两个多月，切换那天，我们选了凌晨三点，前后不到五分钟就把写流量切过去了。但真正让我印象深刻的不是切换本身，而是之前准备阶段的一件小事——我们提前一个月就开始每晚跑数据校验脚本，把发现的不一致问题一个个解决掉，等到切换那天，两边数据已经连续一周完全一致了。这种准备工作，看着不起眼，但正是零停机切换能成功的底气所在。
说到底，数据库迁移拼的不是某个花哨的技术，而是对细节的把控和周密的准备。从备份方式到binlog格式，从流量切换到回退预案，每一步都得想清楚。零停机不是靠运气，是靠一套经过验证的流程和无数次演练堆出来的。下次你要做迁移，别急着动手，先花一周时间把方案里每一环都推演一遍，把可能出问题的点提前堵上。这样真正到了切换那天，你才能像老张凌晨两点盯着屏幕时那样，心里有底。
