MySQL 按租户分表是否值得？大型 SaaS 项目如何权衡复杂度

对于运行多年、承载在线业务的数据库来说，真正困难的往往不是把数据从一台服务器复制到另一台服务器，而是在迁移过程中尽可能保持业务继续运行。数据库规模越大、写入越频繁，传统的“停机、备份、恢复、修改连接、重新上线”方式带来的业务中断就越明显。Google Cloud Database Migration Service（DMS）的主要作用，就是把数据库迁移过程中的全量复制和持续变更同步组织起来，使企业能够在源数据库继续提供服务的情况下逐步建立目标数据库，并把真正需要停机的时间压缩到最后的切换阶段。Google 官方也将 DMS 定位为支持最小停机时间迁移的服务。

DMS如何降低数据库迁移过程中的停机时间

传统迁移通常需要先停止应用写入数据库，然后进行完整备份，再把备份恢复到新服务器。数据库越大，备份和恢复所需时间越长。在整个过程中，应用无法正常写入数据，因此停机时间会随着数据库规模直接增加。

DMS的连续迁移模式采用了不同的方法。首先从源数据库取得初始快照并加载到目标数据库，随后继续捕获源数据库发生的变化，将新增、修改和删除等变化持续复制到目标数据库。这样一来，数据库的大部分数据可以在业务正常运行期间完成迁移，而不需要等待整个数据库复制结束后才开始切换。Google 官方文档将这一过程概括为初始全量加载、约束和索引处理、持续变更数据捕获（CDC），最后再进行 Promote 切换。

这也是降低停机时间最重要的技术原理。假设一个数据库拥有数TB数据，如果采用传统方式，数TB数据的备份和恢复可能需要很长时间；而采用持续迁移后，大部分复制工作可以提前完成。到了正式切换时，真正需要处理的已经不再是整个数据库，而主要是源数据库与目标数据库之间尚未完成复制的变化。

真正决定停机时间的是复制延迟

连续迁移并不意味着完全零停机。DMS会持续监控源数据库变化向目标数据库复制的进度，两者之间存在一定的Replication delay，也就是复制延迟。

Google Cloud的官方说明指出，在最终切换时，需要停止源数据库上的写入并执行Promote操作，使目标Cloud SQL实例脱离源数据库并成为新的主数据库。应用最终经历的停机时间至少与切换决定发生时的复制延迟有关。

因此，迁移前真正应该关注的指标不是简单估算“数据库复制需要几个小时”，而应该观察复制延迟是否已经降低到业务可以接受的范围。例如，在迁移演练期间持续观察数据库写入量、网络吞吐量、目标端应用速度以及CDC复制延迟。如果源数据库产生变化的速度长期高于目标端处理变化的速度，那么复制延迟就可能持续扩大，此时即使全量数据已经复制完成，也不适合立即切换。

这也是为什么数据库迁移前必须进行容量和性能测试。网络带宽不足、源数据库负载过高、目标数据库规格不足、索引重建耗时以及大量写入操作，都可能影响复制追赶速度。

最终切换并不是简单修改DNS

原稿把DMS的切换描述成“蓝绿部署＋DNS修改”，这种说法容易把几个不同层次的技术混在一起。

DMS负责的是数据库迁移和复制，而应用如何切换到新的数据库，则属于整体迁移架构的一部分。连续迁移完成后，通常需要安排一个明确的切换窗口，暂停应用对源数据库的写入，确认复制进度达到预期，然后执行Promote，使目标数据库成为新的主数据库。

如果应用通过数据库连接字符串、配置中心、服务发现系统或代理访问数据库，那么可以根据应用架构修改连接目标。DNS只是其中一种可能的流量切换手段，并不是DMS数据库迁移的必需步骤。

实际生产环境中，更重要的是提前准备切换和验证流程。例如停止写入、确认复制延迟、执行Promote、更新应用数据库连接、启动应用写入、检查核心业务功能，然后持续观察错误率、数据库连接数、查询延迟和事务状态。

DMS并不是所有数据库都能直接迁移

数据库迁移最容易出现的误区，就是把DMS理解成“任何数据库都可以自动搬到Google Cloud”的通用工具。实际上，DMS支持哪些源数据库和目标数据库，与具体迁移路径密切相关。

目前Google Cloud官方文档列出了MySQL、PostgreSQL、SQL Server以及部分异构迁移场景。例如，MySQL可以迁移到Cloud SQL for MySQL，PostgreSQL可以迁移到Cloud SQL for PostgreSQL，也支持PostgreSQL到AlloyDB for PostgreSQL等场景；Oracle和SQL Server也存在特定的异构迁移路径。

因此，数据库迁移项目开始之前，首先应该确认源数据库版本、目标数据库版本、迁移类型以及具体支持范围，而不能仅仅根据“都是关系型数据库”判断可以直接迁移。

例如，MySQL的版本兼容就存在明确限制，某些旧版本不能直接迁移到较新的目标版本，而需要按照Google Cloud提供的版本兼容矩阵设计迁移路径。

数据库一致性不能只靠一次简单校验

数据库迁移完成后，还必须验证目标数据库是否能够承担真实业务。这里需要区分“迁移工具完成复制”和“业务验证通过”两个概念。

数据量、表数量、主键记录数量、关键业务表的数据范围以及抽样记录可以作为验证手段，但不能简单认为比较几个哈希值或行数就能够证明整个数据库完全一致。对于重要系统，还应该结合数据库自身的一致性检查、业务级查询以及关键交易验证。

例如，电商系统可以检查订单、库存、支付状态和用户账户；财务系统则应该检查关键账务记录、余额和交易流水。数据库层面的检查解决的是数据复制问题，而业务层面的验证则解决“迁移后系统能否正确运行”的问题。

对于持续迁移，源数据库的主键设计同样可能影响CDC复制。例如Google Cloud文档特别指出，在某些连续迁移场景中，源表缺少主键会影响UPDATE和DELETE等变化的复制，因此迁移前检查表结构非常重要。

Cloud SQL和Spanner不能混为一谈

原稿提出“迁移过程中使用Cloud Spanner作为临时数据存储”，这并不是DMS标准迁移流程，也容易造成架构误导。

Cloud SQL和Cloud Spanner解决的是不同类型的问题。Cloud SQL主要用于托管MySQL、PostgreSQL和SQL Server等关系型数据库工作负载，而Spanner面向的是具有全球规模、水平扩展和高可用需求的关系型数据库场景。是否从Cloud SQL进一步迁移到Spanner，需要根据应用数据模型、事务模式、SQL兼容性和扩展需求单独进行架构设计，并不是普通数据库迁移过程中的“临时存储”。

同样，Cloud SQL自身的高可用能力可以提高目标数据库在生产运行阶段的可靠性，但不能把Cloud SQL的高可用功能理解成DMS迁移过程中的数据回滚机制。

真正有效的迁移方案是提前演练

减少数据库停机时间，最有效的方法通常不是寻找一个所谓“自动零停机”的按钮，而是把正式切换前能够完成的工作全部提前完成。

迁移前应该确认网络连接、数据库权限、版本兼容性、字符集、表结构、索引、主键以及需要迁移的数据库对象；随后建立目标环境，进行初始数据加载并持续运行CDC。进入正式迁移前，再进行至少一次完整演练，记录全量加载时间、CDC复制速度、复制延迟、目标数据库性能以及应用切换所需时间。

正式切换时，则按照预先验证过的流程执行：停止写入、等待或确认复制延迟达到目标、执行数据库Promote、修改应用连接、验证核心业务，然后逐步恢复正常流量。

因此，数据库迁移的停机时间实际上可以拆成两个部分：大量数据复制阶段可以在业务运行期间完成，而真正需要业务暂停的阶段主要集中在最后的切换窗口。DMS的价值正是把迁移工作从一次性的“停机搬家”，变成一个可以提前进行全量复制、持续同步、最后切换的过程。

对于生产数据库，迁移成功的标准也不应该只是“数据搬过去了”，而应该包括数据完整性、复制延迟、应用兼容性、性能、监控、故障处理以及切换后的运行状态。只有把这些环节在正式迁移之前全部演练过，才能真正把数据库迁移带来的业务停机风险控制在可接受范围内。