在数据库运维领域，迁移一个已经达到 TB 乃至 PB 级别的数据库系统往往意味着漫长的停机窗口、不可控的数据风险以及业务中断的潜在损失。然而，PlanetScale 作为构建于 Vitess 之上的 MySQL 数据库服务，展示了如何在不中断业务的情况下完成大规模数据迁移。其核心技术能力正是本文将要深入剖析的重点：从一致性问题处理到复制拓扑设计，从流量缓冲策略到双向回滚机制，每一个环节都体现了对零停机这一目标的系统性工程思考。
零停机迁移的核心挑战
传统数据库迁移的典型流程包括：对源数据库执行逻辑备份、将备份恢复到目标系统、验证数据完整性、切换应用流量指向新系统、最后下线旧数据库。表面上看，这几步清晰明了，但实际执行中暴露出的问题却极为棘手。最根本的矛盾在于数据一致性需求与业务连续性需求之间的冲突：当执行逻辑备份时，源数据库仍在接收写入操作，备份完成后到切换完成前的这段时间内产生的新数据该如何处理？如果在备份期间锁定表以确保一致性，则意味着写入阻塞；如果允许写入则会产生数据丢失或不一致的风险。
更大规模的数据库还面临时间成本问题。TB 级别的数据通过 mysqldump 进行逻辑导出可能需要数小时甚至数天，期间业务必须停摆。更糟糕的是，如果迁移过程中出现预期之外的错误，例如查询兼容性问题或性能退化，业务团队往往陷入两难境地：回滚意味着重新经历一次迁移过程，继续前行则可能带着隐患上线生产。PlanetScale 的零停机迁移设计正是针对这些痛点提供了系统性的解决方案。
整体迁移架构与数据复制流程
PlanetScale 的迁移架构建立在 Vitess 的 VReplication 组件之上，通过 MoveTables 工作流实现表级别的一致性数据复制。整个迁移过程可以划分为七个核心阶段，每个阶段的设计都围绕「不停机」这一核心目标展开。
第一阶段是获取一致性快照。迁移并非简单地从源数据库读取数据，而是在开始复制之前先获取一个包含后续复制所需元数据的一致性快照。具体实现上，源端的 Tablet 会向外部 MySQL 实例发起 LOCK TABLE READ 查询获取全局读锁，随后立即执行 START TRANSACTION WITH CONSISTENT SNAPSHOT 开启事务并读取当前的 GTID 位置，最后释放锁。这一过程极为短暂，应用程序几乎感知不到任何锁定延迟。通过这种方式，系统获得了一个时间点一致的数据快照以及用于后续复制的 GTID 坐标。
第二阶段是流式数据拷贝。数据拷贝按照主键顺序进行读取，这样可以直接利用 MySQL 的聚簇索引特性，避免额外的排序操作。源端的 Tablet 会启动多个并行流，每个流负责将数据发送到目标端对应的分片。如果迁移过程中需要进行分片拆分，数据会根据分片规则被路由到不同的目标分片。值得注意的是，这个拷贝过程并非一次性完成，而是采用周期轮换的方式：每次拷贝一定数量的行后会暂停数据复制，转而同步该时间段内产生的变更日志（binlog），确保不会因为源端 binlog 被清理而导致复制中断。这种设计在大规模迁移场景中尤为重要，因为它将长时间运行的迁移任务拆解为多个可管理的短周期，同时保证了增量数据不会丢失。
第三阶段是持续变更复制。当初始数据拷贝完成后，系统进入持续复制状态。此时源数据库产生的所有写入操作都会通过 binlog 实时同步到目标端，目标是确保目标数据库在任意时刻都与源数据库保持同步，随时可以执行切换。这个阶段的复制延迟应当控制在较低水平，但对于大规模数据库而言，分钟级别的延迟通常是可以接受的，因为切换发生时系统会等待复制完全追上。
数据一致性验证机制
在业务流量切换之前，必须确认源端与目标端的数据已经完全一致。PlanetScale 采用了 VDiff 工具进行自动化数据校验，这是整个迁移流程中至关重要的一环。VDiff 的校验过程同样设计为不影响源数据库的正常运作：默认情况下，它会选用源端的 Replica Tablet 进行数据读取，而非 Primary Tablet，从而避免对生产流量造成额外负担。
VDiff 的校验流程包含几个关键步骤：首先在目标 keyspace 上获取命名锁，防止并发修改迁移工作流；然后在源端和目标端分别创建一致性的数据快照；接着对源端和所有目标分片执行全表扫描比对，将结果逐行对比并记录差异。整个校验过程是容错的，如果遇到错误可以自动恢复继续执行。对于大型数据库，VDiff 还支持增量模式执行：业务团队可以在迁移准备阶段运行一次初始校验，待接近切换时间点时再恢复并完成增量校验，这种设计特别适合迁移窗口可能延续数周甚至数月的超大规模场景。
校验完成后，团队会获得一份详细的差异报告，明确指出哪些行存在缺失或值不匹配的情况。在这些问题得到解决之前，不建议执行切换，这为迁移安全增添了一道重要防线。
流量切换与查询缓冲策略
当数据同步就绪、业务团队完成应用验证之后，就可以执行流量切换了。切换过程通过 MoveTables 的 SwitchTraffic 命令实现，其核心设计理念是：将切换期间产生的写入请求缓冲起来，等待复制完全追上后再一次性执行，从而避免数据丢失。
切换的具体步骤如下：系统首先执行一系列预检查，包括验证涉及的所有 Tablet 健康状态、确认复制延迟在可接受范围内、确保切换不会导致数据不一致等。预检查通过后，系统会获取源端和目标端 keyspace 的锁，防止并发修改。随后，源 keyspace 的写入被暂停，所有 Incoming 的查询被缓存在 VGate 层面。这个缓冲机制是实现真正零停机切换的关键所在。
接下来，系统等待 VReplication 工作流完全追上源端的写入，确保目标端已经包含了所有待切换的数据变更。在此基础上，系统会创建一个反向的 VReplication 工作流，将目标端的变更同步回源端 —— 这是为可能的回滚准备的。如果切换后出现预期外的兼容性问题或性能异常，团队可以随时执行 ReverseTraffic 命令将流量切回源端，而不会丢失任何数据，因为源端始终保持着与目标端的增量同步。
最后，系统更新 Schema 路由规则，使后续查询直接路由到目标 keyspace，释放查询缓冲并恢复正常写入。整个切换过程通常在秒级完成，根据 PlanetScale 的官方数据，典型切换耗时不到一秒，用户感知到的仅仅是轻微的延迟抖动。
分片迁移与水平扩展能力
对于超过 250GB 的数据库，PlanetScale 建议在迁移过程中同步进行水平分片。这一能力是 Vitess 架构的核心优势，也是许多客户选择迁移到 PlanetScale 的重要原因。迁移流程允许将一个未分片的 MySQL 数据库在迁入时自动拆分为 N 个分片，每个分片独立存储和处理数据，从而突破单节点容量和性能瓶颈。
分片迁移的实现与普通迁移的技术原理一致，但数据在传输过程中会根据预先定义的分片键进行路由。例如，如果采用基于用户 ID 的分片策略，所有具有相同用户 ID 的行会被路由到同一分片。Vitess Sequences 机制会替代原有的 auto_increment 功能，在分片环境中生成全局唯一的递增序列值，确保分片后的表仍然能够保持主键的唯一性。
工程实践建议
基于上述技术架构，PlanetScale 在实践中积累了一些值得借鉴的工程建议。首先，对于规模较大的数据库迁移，强烈建议在源端建立一个标准的 MySQL 副本作为迁移源，而非直接在生产主库上执行复制操作。这样做的好处是迁移过程完全不会影响生产系统的性能，唯一的侵入操作只是在极短时间内获取 GTID 位置的读锁。
其次，在流量预切换阶段，应用会将请求发送至 PlanetScale，再由 PlanetScale 转发回源端数据库。这一阶段的查询延迟会明显高于直接连接源数据库，因为额外的网络跳转开销无法避免。对于已经在使用本地高速连接（如 Unix Domain Socket 或回环设备）的应用，影响尤为显著。因此，不建议在此阶段进行性能基准测试，真正的性能对比应当在完成切换之后进行。
最后，VDiff 校验虽然是可选步骤，但在生产环境中强烈建议至少执行一次完整校验。考虑到某些迁移可能持续数周甚至数月，源端的 binlog 可能会被清理，如果不在早期发现问题，后期可能需要从头重启迁移流程。
小结
PlanetScale 基于 Vitess 实现的零停机迁移技术，通过 VReplication 的流式数据复制、MoveTables 的工作流抽象、VDiff 的自动化数据校验以及 VGate 的查询缓冲机制，构建了一套完整的 PB 级数据库迁移解决方案。其核心理念是将迁移过程中的数据一致性保证和业务连续性需求分解为多个可独立验证、可安全回滚的阶段，使得大规模数据库迁移不再是令人望而生畏的运维梦魇。对于面临类似挑战的团队而言，理解这一技术背后的设计思路，无论是否采用 PlanetScale 服务，都具有重要的参考价值。
参考资料
- PlanetScale 官方博客：Zero downtime migrations at petabyte scale（https://planetscale.com/blog/zero-downtime-migrations-at-petabyte-scale）
- Vitess VReplication 文档（https://vitess.io/docs/reference/vreplication/vreplication/）