我们将 PostgreSQL 数据库迁移了，停机时间只有 11 秒
一个英国政府团队描述了他们如何将用于 GOV.UK Notify 服务的 400GB PostgreSQL 数据库迁移到一个新的 AWS RDS 实例，停机时间仅 11 秒，并使用了 AWS Database Migration Service、DNS 技巧和 logical replication。评论者将这种做法与原生 PostgreSQL 工具和 RDS blue/green deployments 等替代方案进行对比，指出 DMS 在规模较大或 schema 复杂时既强大又有陷阱。此次迁移也重新引发了关于政府依赖外国云提供商的更广泛争论，权衡运营韧性和人员限制，与数据主权、成本以及对关键基础设施的长期控制之间的取舍。
英国政府对 AWS 的使用
- 许多人对英国政府的核心服务运行在 AWS 之上感到不安，AWS 是一家美国公司；他们担心数据主权、地缘政治风险，以及对外国供应商的依赖。
- 也有人认为 AWS 提供了强大的合规性、安全性和可靠性，可能比典型的政府内部数据中心更好。
- 还有人指出，该服务此前就已经通过 GOV.UK PaaS 运行在 AWS 上；这次迁移主要改变的是账户/架构，而不是基本依赖关系。
云端 vs 本地部署 / 主权之争
- 批评者说，一个富裕的 G7 国家应该建立自己的“公共部门云”，或者运行在本地，以保留机构能力和控制权。
- 反方观点：政府 IT 招聘慢、薪酬低；本地部署成本高、复杂，而且往往最终还是外包给大型集成商；公共云让采购和扩展更容易（例如疫情期间）。
- 还有更广泛的担忧，认为对美国技术（AWS、Microsoft、Palantir 等）的依赖无处不在。
AWS DMS 与迁移方法
- 讨论串里对 AWS Database Migration Service（DMS）的体验褒贬不一：
- 有人称其有 bug、行为不透明、支持也差，并报告过静默数据损坏、schema 变更问题和类型限制。
- 也有人表示曾成功用于 MySQL↔Postgres 以及本地→AWS，但强调需要仔细测试，并尽量减少转换。
- 几位评论者指出，AWS 自己的文档建议在 Postgres→Postgres 迁移时使用原生 Postgres 工具（pg_dump、logical replication）；DMS 可能只会增加不必要的复杂性。
停机时间、DNS 与查询处理
- 文中提到的 11 秒停机时间被认为已经不错，但有人认为还可以进一步缩短：通过 pgbouncer/pgpool 暂停连接，而不是硬切换。
- 依赖 DNS TTL=1s 让一些人担忧，因为并非所有解析器都会遵守 TTL；讨论中也提到了连接池的行为。
- 长时间运行的查询和事务被视为零停机切换的敌人；超时设置和运维纪律会有所帮助。
替代工具与模式
- 多位评论者主张使用 Postgres logical replication、pglogical、pgloader，或物理/WAL 复制来实现低停机迁移。
- RDS Blue/Green Deployments 获得了高度评价，被认为几乎可实现零停机的版本升级，甚至包括加密变更，不过其局限在于跨账户能力不足，且只支持向前升级。
政府 IT 文化与采购
- 几位评论者将公共部门 IT 描述为受预算、僵化采购、招聘缓慢和规避风险的文化所限制，从而推动“买而不是造”的决策。
- 也有人认为，发布这样一篇详细、清晰的迁移说明本身就是透明度和良好工程实践的积极信号。