2026 PostgreSQL 18 主备复制怎样验收？故障切换清单

判断：适合正在准备 PostgreSQL 18 主备上线的团队；不要只凭复制延迟低或备用节点能连接就放行，应分别验证 WAL 接收与回放、计划内提升、应用写入恢复、逻辑复制槽和回退边界。异步复制可能让尚未送达备用节点的事务在切换时丢失，主备复制也不能代替机外备份。PostgreSQL 官方版本策略列出的当前 18 系列小版本为 18.6，发布于 2026 年 8 月 13 日；涉及参数与状态判断时，应以对应版本的官方版本策略为准。

负责生产主库和物理备用节点的 DBA，可用本文核对复制是否追上、备用节点是否可提升。
基础设施工程师，可检查服务器资源、网络连通、访问控制和节点隔离。
负责发布或值班的后端工程师与技术负责人，可据此验证连接恢复、写入结果和放行责任。

PostgreSQL 18 主备复制验收：分别检查接收、回放与切换

复制延迟是观察信号，不是上线验收结论。主库的 WAL 已发送，不代表备用节点已经收到并落盘；WAL 已接收，也不代表备用节点已完成回放。官方文档建议结合发送端与接收端位置判断差距：主库的当前 WAL 位置与发送位置之间的差异，可能反映主库负载；发送位置与备用端接收位置的差异，可能与网络或备用端负载有关；接收位置与回放位置的差距，则说明 WAL 尚未全部应用。详见流复制监控说明。

可在主库检查发送端：

SELECT application_name, state, sent_lsn, write_lsn,
       flush_lsn, replay_lsn, sync_state
FROM pg_stat_replication;

在备用节点检查接收与恢复状态：

SELECT status, written_lsn, flushed_lsn, latest_end_lsn
FROM pg_stat_wal_receiver;

SELECT pg_is_in_recovery(),
       pg_last_wal_receive_lsn(),
       pg_last_wal_replay_lsn();

这些视图和函数呈现的是不同阶段的状态，不能把单个字段当作完整的健康判定。尤其要留意查询采样时刻、持续一段时间的变化趋势，以及应用端实际观察到的结果。字段定义可核对管理函数文档与复制参数文档。

复制延迟正常，是否就能切换？

不能据此直接批准。PostgreSQL 流复制默认是异步的；主库故障时，已经提交但尚未复制到备用节点的事务可能丢失，风险取决于故障发生时的复制差距。即使某次观察到发送、接收与回放位置接近，也只能说明采样时的状态，无法证明故障瞬间一定没有差距。异步与同步复制的行为边界见官方备用节点文档。

验收时应记录团队允许的数据缺口，并把它与复制模式、监控告警和业务可接受的数据恢复点对齐。若数据不能接受异步复制留下的潜在缺口，不能靠提高告警敏感度来消除这一机制本身的风险；需要由 DBA 评估同步复制等方案对提交行为和可用性的影响，并针对实际拓扑测试。

按团队职责核对上线边界

DBA：确认复制槽与 WAL 保留风险

• ✅ 检查物理复制连接、发送与回放状态；分别记录主库和备用节点上的观察结果。
• ✅ 盘点物理复制槽，核对槽是否失效、保留位置是否持续落后，并确认 WAL 空间监控和清理预案。
• ✅ 确认断连后的追赶路径，例如可用的 WAL 归档或重新初始化流程。复制槽能帮助保留备用端所需 WAL，但配置不当也可能造成 WAL 长期积压；相关参数含义与边界见复制参数文档。

基础设施：验证两台服务器之间的实际路径

• ✅ 从实际部署位置验证主备连接、路由、端口访问控制与名称解析；不要假设租用两台服务器就自动形成私有网络或隔离域。
• ✅ 检查主备节点的维护、重启和断连情形，确认单节点故障不会让两端同时被应用当作可写主库。
• ✅ 明确谁能执行提升、谁负责隔离故障主库，以及执行结果记录在哪里。PostgreSQL 本身不会替团队提供检测主库故障并通知备用节点的完整系统；故障切换文档也强调，旧主库恢复后必须避免双方同时认为自己是主库。

DBA 与值班负责人：执行计划内提升演练

备用节点是否可提升，最终要在可控演练中验证，而不是由“端口可连接”推断。演练前先确认变更窗口、业务影响、停止条件和负责人；若无法确认旧主库已隔离，或备用节点状态不符合计划，应停止操作，不要同时尝试两端写入。

在批准的演练窗口内，按团队预定流程执行提升。手动提升可使用 pg_ctl promote 或 pg_promote()；它们用于触发备用节点退出恢复状态，并不自动提供故障检测、应用连接切换或旧主库隔离。提升操作及相关状态可参照备用节点操作文档和管理函数文档。

演练记录至少应包含：操作前的节点角色与 WAL 位置、提升指令及其结果、提升后 pg_is_in_recovery() 的状态，以及新主库是否接受预期写入。演练结束后，旧主库必须先处理分裂风险，再按恢复方案重新加入；不能把提升后的旧主库直接启动并默认它会自动跟随新主库。

应用团队：验证连接恢复与写入结果

数据库端状态正常，不代表服务已经恢复。应用负责人应检查连接池在断连后的处理方式、重连目标是否指向当前主库、读写请求是否被错误路由，以及事务结果不确定时的处理逻辑。

用可回滚的测试事务验证新主库的写入路径和读取路径，并记录客户端如何识别旧主库与新主库。对超时后重试的请求，还需确认业务是否具备幂等处理或结果核对机制，避免把“客户端没收到确认”误认为“数据库没有提交”，从而造成重复提交。只做数据库端口连通测试，不足以作为业务恢复标准。

下游数据团队：核实逻辑复制槽是否就绪

物理流复制与逻辑复制的用途不同：物理复制传送并回放 WAL；逻辑复制则由发布与订阅机制传递变更。使用 CDC、逻辑订阅或其他逻辑槽消费者的团队，必须单独核对这些消费者在切换后能否继续工作；没有逻辑复制消费者的团队，应把此项标为不适用，而不是将其与物理复制状态混为一谈。两种复制机制的区别可见逻辑复制概览。

主库切换后，逻辑复制槽还会在吗？

不能假定槽已经同步。PostgreSQL 18 的逻辑复制故障切换文档说明，逻辑槽同步是异步的；计划提升前，需要核实订阅所需槽已同步到目标备用节点，并处于可用于故障切换的状态。按该文档逐一列出相关槽，再检查备用节点 pg_replication_slots 的 synced、temporary 和 invalidation_reason 等字段；该检查不是对所有团队都适用，只有实际使用相关逻辑复制或 CDC 的团队才需要执行。步骤与判定条件见逻辑复制故障切换文档及复制槽视图字段说明。

对照服务器资源与主备验收边界

主备部署涉及两台独立节点，但硬件规格只是团队规划输入，不等于已配置好的主备服务、自动切换或网络隔离。以下服务器信息应以当前配置与价格页面为准；服务器资源、复制拓扑和切换机制应分别核对。

配置细节与价格可能调整，采购时应以当前产品信息为准。两台机器是否组成可用的主备拓扑，取决于团队自行设计的复制、网络、安全、监控与切换流程；本站页面没有确认提供自动故障转移、私有网络、集群管理或代运维能力，因此不应把这些能力写入上线验收假设。

值班放行条件与数据保护

把验收结果整理成有责任人的放行清单，以下任一项未完成时，值班负责人应决定暂缓上线或按预案回退：

• ✅ 主库发送端、备用端接收端和回放端分别有可复核记录，且差距解释清楚。
• ✅ 复制槽与 WAL 保留风险已检查；断连后的追赶或重建方案已明确。
• ✅ 计划内提升演练完成；新主库角色、写入路径与应用重连结果均已验证。
• ✅ 旧主库隔离及重新加入流程已经过审阅；无法确认隔离时不得继续提升或恢复双端写入。
• ✅ CDC 或逻辑复制消费者已核对目标槽状态；没有此类消费者则明确记录不适用。
• ✅ 机外备份可访问，且团队演练过恢复。PostgreSQL 官方备份文档将 SQL 导出、文件级备份与连续归档列为不同方法，并说明数据库应定期备份；复制不是其中任何一种备份的替代品。参见备份与恢复文档。

上线验收的核心不是得到一个“延迟正常”的绿灯，而是让 DBA、基础设施、应用与下游数据团队分别证明自己负责的环节可工作，并事先约定何时停止切换、谁批准回退、如何保护数据。若故障时无法判断旧主库是否仍可写，或机外备份从未做过恢复验证，继续扩大生产写入范围就缺乏足够依据。

对于正在使用共享云主机或托管数据库的团队，迁到独享服务器可能有利于自主规划整机资源与直连磁盘，但也意味着团队要承担复制维护、故障切换、备份和恢复演练；两台独享服务器本身不会自动解决这些工作。若评估后确定需要自主管理的数据库服务器，可对照 SFP Cloud 当前列出的内存、直连 NVMe、系统与计费周期核实采购方案；主备拓扑、访问控制和机外备份仍需由团队设计并实际验收。需要进一步核对可选项时，可查看服务器申请页面，但单台租用不等于已交付主备集群。