随着企业数据量的快速增长，数据库升级成为保障系统稳定性和性能的重要工作。尤其是PostgreSQL这样广泛应用的关系型数据库，跨多个大版本的升级往往伴随着挑战。近日，我们通过谷歌云平台（Google Cloud Platform，简称GCP）的数据库迁移服务（Database Migration Service，DMS）成功完成了从PostgreSQL 13直接升级到16的多TB级数据库迁移，跳过了14和15版本。此次升级不仅验证了GCP DMS在大版本跨越中的强大能力，也为同行业提供了宝贵的实战参考。本文将详细分享整个升级过程中的关键步骤、遇到的问题与最佳实践，助您用更科学的方法完成PostgreSQL升级。GCP DMS作为一款专业的数据库迁移工具，支持多种迁移模式，但本次升级中我们重点围绕CloudSQL PostgreSQL到CloudSQL PostgreSQL的迁移展开。
源数据库和目标数据库均为CloudSQL托管环境，迁移过程中利用DMS的逻辑复制功能确保数据一致性与连续可用性。迁移前的准备阶段重中之重是源数据库的配置。DMS通过连接配置文件来代表源数据库，使用Terraform自动化完成连接配置极大提高了效率和可靠性，特别是在证书认证的设置上。此外，由于DMS内部依赖于pglogical扩展用于逻辑复制，确保源数据库和目标数据库都正确安装并配置了pglogical是项目成功的基础。Google官方文档对相关Cloud SQL参数配置和重启步骤提供了详尽说明，必须逐一确认以避免迁移中断。目标数据库的选择上，我们并未使用DMS自动创建的新实例，而是采用已有的CloudSQL实例。
这样做的优势在于能够利用Terraform对目标实例进行全面且精准的配置管理，保持环境一致性及安全策略满足企业合规要求。迁移的一个明显限制是在整个过程中，源数据库上不应执行任何DDL操作，例如创建表、修改表结构或删除索引等，这类变更不会被DMS同步。虽然序列会自动迁移，但最后的值可能略高于源实例，通常不会影响应用逻辑，因为依赖序列连续性本身就不是良好设计。迁移实际分为两个主要阶段，首先是全量数据导出，随后进入变更数据捕获（CDC）同步阶段。全量导出阶段，DMS采用PostgreSQL的\COPY命令将数据复制到目标数据库，过程开始时会对涉及表施加短暂的排他锁，持续约1到2分钟。虽然时间不长，但对高负载生产环境还是会造成一定影响，提前规划维护窗口非常必要。
值得一提的是，如果目标数据库版本不低于14，可以实时通过pg_stat_progress_copy视图监控大型表复制进度，这对迁移过程的透明管理大有裨益。在此阶段，DMS仅迁移表内数据，索引与约束会等全表数据复制完成后集中建立，能够加快数据导入速度同时保障后续一致性。进入变更数据捕获阶段后，DMS开始应用全量导出期间产生的所有数据变动，确保数据库内容保持同步。此阶段最关键的指标是复制延迟，要求持续监控直到复制落后为零，才能安全切换主数据库。实际落后时间取决于全量数据复制的时长及期间写操作活跃度。高并发迁移时，我们发现表中大量“死元组”会显著降低复制吞吐量。
由于无法对生产数据库执行VACUUM FULL避免写入阻塞，维护良好的数据库健康状态对于迁移性能至关重要。针对超大体量数据库，调优复制参数和PostgreSQL底层配置显得尤为重要。参考PostgreSQL官方关于数据装填的文档及Google的迁移最佳实践建议，有助于大幅提升数据导入速度和系统稳定性。全量迁移及CDC阶段完成后，务必运行ANALYZE命令更新目标数据库统计信息，为查询优化器提供精准数据支撑。我们深刻体会到若忽视此步骤，将导致查询性能骤降。结合并行脚本或VACUUM ANALYZE实现统计信息的快速刷新，是确保迁移后环境性能平稳的关键。
在复制延迟降至零且所有统计数据均已刷新后，即可开始推广目标数据库为主实例。在推广前应切断源数据库所有写入流量，防止数据变动，再次验证复制延迟保持为零才能操作。推广过程本身耗时约五分钟，期间会发生连接切换及角色变更，用户访问需暂时配合。若存在数千表的复杂环境，推广时有时会出现源实例清理复制设置的超时警告。通常该情况对升级影响不大，但若需要回滚或继续使用旧数据库，则必须手动清理pglogical的复制槽及配置。相关操作可参阅Google和pglogical的官方指导文档。
升级过程中，DMS会暂时禁用目标实例的时间点恢复（PITR）功能，完成推广后要重新启用。该操作将触发数据库重启，短暂影响业务响应，请预先安排维护窗口。整体验迁移过程可能产生的停机窗口包括源实例启用逻辑解码时的重启时间、全量导出开始时的排他锁停顿、目标实例推广期间的切换时间以及最后开启PITR的重启过程。每个环节的时间虽不长，但累积影响需充分评估。回顾这次跨版本升级经历，GCP DMS为大规模PostgreSQL数据库提供了稳定高效的迁移方案，跳过中间版本升级路径减少了复杂度和风险。关键成功因素在于完善的前期准备、合理的运维控制及对迁移过程的精准监控。
期待未来Google不断完善DMS，对DDL变更支持更友好，性能进一步提升，助力更多企业顺利迈入新版数据库时代。
