PostgreSQL同步复制模式下备库宕机后如何保障服务持续运行

有成熟落地方案，不需要停业务，核心逻辑是绕开「主库必须等待故障备库返回写入ACK才提交事务」的阻塞点，动态摘除故障复制链路即可，具体操作如下：

• 前置配置优化（推荐长期配置，避免故障时临时操作）
  不要把同步复制规则写死为固定单备库，优先用数据库自带的同步副本阈值配置：将最小同步生效副本数设为1，同时配置备库心跳超时、ACK失败的自动剔除规则。当备库宕机、连续收不到日志同步响应时，主库会自动把故障节点移出同步备库列表，不会阻塞写入。
• 故障发生时的手动应急操作
  如果没配自动剔除规则，直接在主库执行热配置变更，不需要重启数据库进程，秒级生效：

  操作前确认主库本身进程、网络正常，避免误操作导致二次故障
  PostgreSQL场景执行：

  ALTER SYSTEM SET synchronous_standby_names = '';
  SELECT pg_reload_conf();
  

  执行后主库会立即清空同步备库校验规则，不再等待任何备库的写入确认，业务写入直接恢复，故障备库的复制链路会自动标记为断开状态，不会持续重试占用资源。
  MySQL增强半同步场景执行：

  SET GLOBAL rpl_semi_sync_master_enabled = OFF;
  

• 备库恢复后的回切操作
  备库修复启动后，先确认备库已经追平主库的所有日志差量（PostgreSQL看pg_stat_wal_receiver的flush位点、MySQL看show slave status的Relay_Master_Log_File和Exec_Master_Log_Pos位点和主库一致），再把主库的同步复制配置改回原有值，reload配置即可恢复sync同步模式，全程无业务中断，仅需注意回切瞬间可能存在毫秒级写入抖动，尽量在业务低峰操作。

注意事项 #

• 降级期间主库处于单节点运行状态，没有实时副本校验数据完整性，必须配置对应告警，提醒运维尽快修复备库，避免长时间单节点运行出现数据丢失风险。
• 两节点同步复制本身存在架构缺陷，如果对数据可靠性SLA要求很高，后续可以新增一台轻量仲裁节点（仅参与日志ACK投票，不需要存储全量业务数据），后续单备库故障时不需要降级也能维持同步复制逻辑。

内容的提问来源于stack exchange，提问作者Jae