PostgreSQL 19 预览：解析复制槽同步期间强制Promote机制与实现

在PostgreSQL高可用集群中，当备用服务器（Standby）正在进行复制槽（Replication Slots）同步操作时，如果需要立即将其提升（Promote）为主服务器，能否强制进行？针对这一场景，PostgreSQL 19的预览版本通过提交1362bc33e025fd2848ff38558f5672e2f0f0c7de引入了关键改进。

该提交的核心目标是确保在备用服务器执行Promote操作时，任何正在进行的复制槽同步进程（无论是后台工作进程还是通过SQL函数调用的后端进程）都能被立即中断，从而避免阻塞高可用性切换的关键路径。

补丁内容解读：增强槽同步API以响应升级信号

变更原因

1. 原有机制不足：此前，在Standby升级时，系统仅会通知专门的槽同步工作进程退出。而对于通过执行pg_sync_replication_slots() SQL函数进行同步的后端进程，则不会收到信号，它会继续完成当前同步周期，这在快速故障转移场景下可能造成延迟。
2. 为新功能铺垫：一个即将到来的补丁将改进pg_sync_replication_slots()函数，使其会等待复制槽被完全持久化后才返回。这种行为要求，一旦发生Promote，该后端进程必须能立即退出，以免干扰升级过程。
3. 本补丁的作用：此补丁修改了槽同步的共享内存结构及相关逻辑，使其能够追踪并发送信号给所有类型的同步进程，确保它们在收到Promote信号后能即刻终止。

关键代码变更

补丁主要修改了src/backend/replication/logical/slotsync.c文件。它扩展了共享结构体中进程ID（pid）字段的用途，使其不仅能标识后台工作进程，也能标识执行SQL函数的后端进程。当启动进程（Startup Process）在Promote期间设置停止标志（stopSignaled=true）后，会利用这个pid向正在同步的进程发送信号，唤醒并使其退出。

此外，补丁还细化了配置重载逻辑：对于后台工作进程，参数变化会触发进程重启；对于执行SQL函数的用户后端进程，参数变化则会抛出一个错误。这部分关于配置管理和进程控制的逻辑，是数据库/中间件高可用设计中精细控制的一环。

核心问题解析

1. 执行同步的进程位于何处？
是的，正在执行复制槽同步操作的后端进程位于备用服务器（Standby）上。复制槽同步的目的，是确保在发生故障转移（Failover）时，即将成为新主库的节点能够获取并维护必要的槽状态信息，实现平滑接管。

2. 中断同步是否会导致状态不一致？
在Promotion场景下，中断是必要且安全的。其设计哲学是优先保障高可用切换流程不被阻塞。虽然中断可能导致槽的最新状态未完全同步，但不会造成永久性数据丢失。

• 强制退出是为关键步骤让路：Promote过程中，新的主库需要由Startup Process执行一系列关键操作（如持久化最终槽状态）。若同步进程不退出，可能因等待I/O而阻塞整个升级流程。
• 最终状态由权威进程确定：复制槽的最终、正确的restart_lsn将由执行Promote的Startup Process在升级收尾阶段确定并写入。它会读取备库已应用的最新WAL位置（current_lsn），并以此为基础确保所有槽的状态安全。

3. Startup Process如何确定新的restart_lsn？
代码（src/backend/replication/slot.c中的StartupReplicationSlots()函数）证实了这一逻辑。当系统处于Promote状态（IsPromoting()）时：

if (IsPromoting())
{
    current_lsn = GetXLogReplayRecPtr();
    // ... 遍历所有槽
    if (XLsnLT(slot->data.restart_lsn, current_lsn))
        slot->data.restart_lsn = current_lsn;
}

Startup Process会获取当前已回放的最新WAL位置（current_lsn），并将所有复制槽的restart_lsn至少提升至此位置。这确保了新主库不会试图保留它已不再拥有的旧WAL文件，这是运维/DevOps实践中保证故障转移后数据可服务性的关键机制。

4. 为何由新主库决定restart_lsn？
这涉及Promotion场景下的特殊逻辑。在正常运行时，restart_lsn由下游消费者反馈决定。但在备库升级的瞬间，情况发生根本变化：

• WAL可用性边界：新主库只能保证提供从current_lsn（其成为主库的起点）之后新产生的WAL。此前的WAL文件可能很快被清理。
• 安全底线原则：如果某个槽的restart_lsn落后于current_lsn，新主库必须将其强制提升至current_lsn。这相当于告知所有消费者：“故障转移后，请从current_lsn这个安全点开始重新同步。” 这虽然可能导致少量数据重复处理，但避免了因WAL缺失导致的复制永久中断，是在高可用场景下保障服务连续性的必要权衡。

总结

PostgreSQL 19的这一预览特性，强化了在复制槽同步场景下进行强制Promote的能力。其核心在于通过立即中断同步进程来确保高可用切换的速度，并通过Startup Process在升级末期统一确定并持久化槽的安全状态。这体现了PostgreSQL在平衡数据一致性与服务可用性方面的精细设计，对于构建健壮的数据库高可用架构具有重要意义。