使用 Pub/Sub 逻辑复制实现 Aurora PostgreSQL 大版本近零停机升级
内容提要
本文介绍使用Aurora Clone与PostgreSQL原生逻辑复制（Pub/Sub）实现Aurora PostgreSQL大版本近零停机升级的方案。以PG13升级至PG17为例，通过创建复制槽、克隆集群、原地升级、推进LSN位点及建立订阅等步骤，将停机时间压缩至分钟级。文章还涵盖高写入量表的并行订阅拆分、回滚保障机制及升级注意事项。
延伸解读
方案选型对比
文章对比了五种升级方案，其中手动Pub/Sub方案在停机时间、数据一致性、灵活性和成本方面具有优势。它利用Aurora Clone的写时复制特性，避免物理拷贝数据，初始不产生额外存储费用，且支持跨多个大版本升级，不受AWS蓝绿部署版本路径限制。相比原地升级，该方案可回退，风险更低。
关键步骤与风险控制
升级流程中，复制槽在Clone之前创建，确保WAL保留，之后推进到Clone LSN避免重复应用。Cutover时需将源集群设为只读，等待lag归零，并重置Sequence防止主键冲突。回滚机制提供三个时间窗口：Cutover前零成本回滚，Cutover后DNS回切，以及通过反向复制保障数据完整。
高写入量表的并行处理
针对高写入量表，单订阅单线程apply会成为瓶颈，导致整体lag无法追平。文章提出按表组拆分多个独立订阅任务，各组互不阻塞，并发apply。通过--table-pattern参数支持通配符、任务分隔符、合并符和排除模式，灵活控制任务划分，每个任务lag独立可控，需全部归零后才能Cutover。
注意事项与运维要点
升级后需执行全库ANALYZE，避免统计信息过时导致执行计划偏差。Replication Slot会保留WAL，需监控源集群存储使用率，防止膨胀。外键关联的父子表必须放在同一订阅任务中，否则可能因并发apply导致约束违反。此外，需确保max_replication_slots和max_wal_senders有足够余量。
Q&A
如何实现 Aurora PostgreSQL 大版本升级的近零停机？
使用 Aurora Clone 和 PostgreSQL 原生逻辑复制（Pub/Sub）方案。通过创建复制槽、克隆集群、原地升级、推进 LSN 位点及建立订阅，将停机时间压缩至分钟级。
Aurora PostgreSQL 大版本升级有哪些方案？各自的优缺点是什么？
主要有原地升级、AWS 蓝绿部署、手动蓝绿DMS、Clone+原生Pub/Sub、业务双写。原地升级停机时间长且不可回滚；AWS蓝绿部署停机短但高写入时lag难追平；DMS需要数据校验；Clone+Pub/Sub停机短且可控；业务双写停机最短但需业务改造。
为什么选择 Clone + 原生 Pub/Sub 方案？
因为该方案停机时间短（分钟级），使用原生逻辑复制保证数据一致性，无需额外组件，支持精细控制（按表拆分订阅），全程可观测，安全回退，且成本低（Aurora Clone 写时复制）。
升级前需要做哪些准备？
需要修改参数组（rds.logical_replication=on等），检查表结构（无主键表需处理），并进行兼容性验证（索引健康、函数兼容性等）。
手动 Pub/Sub 升级的完整流程是什么？
流程包括：创建复制槽与发布、Aurora Fast Clone、原地升级、推进 Slot 位点、创建订阅、监控复制延迟、升级验证、Cutover 切流。
为什么需要推进 Slot 位点？
因为复制槽在 Clone 之前创建，其 restart_lsn 早于 Clone 时刻，如果不推进，订阅会重复应用 Clone 已包含的数据，导致主键冲突。推进到 Clone 的 LSN 后，两侧数据对齐。
高写入量场景下如何拆分并行订阅任务？
通过 --table-pattern 参数按表组拆分，每组创建独立的 Publication、Slot 和 Subscription，各组互不阻塞，并发 apply。支持通配符、逗号分隔任务、加号合并模式、减号排除模式。
如何实现回滚？
提供三个时间窗口的回滚：Cutover 前直接删除 Clone；Cutover 后 DNS 回切并恢复源集群可写；切流后建立反向复制链路保障数据完整。Cleanup 后只能通过快照恢复。
升级过程中有哪些注意事项？
注意无主键表处理、外键与 Trigger 处理（父子表需在同一订阅任务）、LOB/TOAST 大字段影响、升级后全库 ANALYZE、WAL 膨胀风险、Extension 版本对齐、并行任务数量与 Slot 限制。
