PostgreSQL主从同步配置与故障切换该如何一步步实现？

PostgreSQL的主从同步能力建立在预写日志（WAL）流复制机制之上。通过把主库产生的WAL记录持续发送到备库并重放，备库能够保持与主库几乎一致的数据状态。当主库因为硬件损坏、网络隔离或软件故障无法提供服务时，运维人员可以将其中一个备库提升为新主库，从而让业务在最短时间内恢复写入。理解这套机制的工作原理，是正确完成配置和故障切换的前提。

主从同步的基础原理与复制模式选择

PostgreSQL的流复制依赖WAL日志。主库在每次提交事务时，会把变更先写入WAL文件，然后后台进程wal_sender将WAL片段通过网络发送给备库的wal_receiver。备库接收到日志后写入本地WAL，再交由startup进程重放，使数据页达到与主库相同的状态。这种机制决定了备库不仅可以用于读取分流，也能在主库失效时接管写入。

在复制模式上，PostgreSQL提供了同步和异步两种主要方式。异步复制中，主库提交事务后不等待备库确认即返回成功，性能影响小，但如果主库突然宕机，最后一部分未发送的WAL可能丢失。同步复制则要求主库等待至少一个同步备库确认收到并落盘WAL后才向客户端返回提交成功，从而做到零数据丢失，代价是写入延迟受网络与备库磁盘性能制约。实际生产中，常采用一同步一异步或多备库quorum机制来平衡安全与性能。

除了流复制，PostgreSQL还支持基于文件的日志传送以及逻辑复制。逻辑复制以表级别为单位发布和订阅变更，适合跨版本升级或仅同步部分数据；而本文讨论的主从同步通常指物理流复制，它复制整个数据库实例，更适用于高可用故障切换场景。选择方案时应先明确业务对RPO和RTO的容忍度。

基于流复制的主从同步详细配置步骤

开始配置前，准备两台服务器，分别作为主库（node1）和备库（node2），安装相同大版本的PostgreSQL。主库需要修改postgresql.conf，将listen_addresses设为对备库可达的地址，wal_level设为replica或logical，max_wal_senders预留足够连接数，并配置synchronous_standby_names以启用同步备库。这些参数决定了WAL能否被正确发送与确认。

接着在主库pg_hba.conf中添加复制专属规则，允许备库以replication权限连接。例如添加一行host replication repluser 192.168.0.2/32 md5，表示允许该IP使用repluser账号进行流复制。随后在主库创建复制账号并赋予replication属性。完成上述操作后重载或重启主库使配置生效，此时主库已具备被备库拉取日志的条件。

在备库上使用pg_basebackup进行基础备份初始化。该工具会通过基线备份方式把主库当前数据目录完整拷贝过来，同时自动生成用于流复制的配置文件。执行命令时可指定-R参数让工具直接写入standby.signal与primary_conninfo，简化后续操作。以下示例展示基础备份与参数设定：

# 在主库创建复制用户
psql -c "CREATE ROLE repluser WITH REPLICATION LOGIN PASSWORD 'pwd123';"

# 备库执行基础备份，IP换为主库地址
pg_basebackup -h 192.168.0.1 -U repluser -D /var/lib/pgsql/data 
  -Fp -Xs -R -P

# 备库 postgresql.conf 关键片段
primary_conninfo = 'host=192.168.0.1 port=5432 user=repluser password=pwd123'
restore_command = 'cp /archive/%f %p'

启动备库后，通过主库执行SELECT * FROM pg_stat_replication;可看到活跃的wal_sender连接，备库查询pg_is_in_recovery()返回t表示正处于恢复状态。此时写入主库的数据会在秒级或更短时间内反映到备库，主从同步配置基本完成。若使用同步复制，需确认synchronous_standby_names已包含备库名称且状态为sync。

故障切换的手动与自动化实现方案

当主库不可用，最先要判定其确实失效而非短暂网络抖动。手动切换时，应在确认主库关闭后，于备库数据目录中移除standby.signal（旧版本为recovery.conf中的standby_mode），并创建promote信号文件或直接执行pg_ctl promote命令。备库会退出恢复模式，把自己提升为可读写的新主库，之后应用可指向该实例继续业务。

手动切换虽然直观，但在深夜或大规模集群中容易出错且速度慢。因此常引入repmgr或Patroni等工具。repmgr通过守护进程监控节点健康，结合仲裁与 fencing 避免脑裂；Patroni则依赖etcd或Consul做分布式协调，能自动选主并借助回调脚本更新负载均衡或VIP。以下为repmgr.conf中定义故障切换的简化配置：

node_id=2
node_name=node2
conninfo='host=192.168.0.2 user=repmgr dbname=repmgr'
data_directory=/var/lib/pgsql/data
failover=automatic
promote_command='repmgr standby promote -f /etc/repmgr.conf'
follow_command='repmgr standby follow -f /etc/repmgr.conf'

无论采用哪种方式，故障切换后都要处理原主库。若原主库重启，不能让它直接接入新集群，而应先以备库身份通过pg_rewind重新对齐数据再加入，否则会产生时间线分歧。此外应用端应使用支持多主机或自动重连的驱动，配合虚拟IP或代理层，使切换对业务透明。定期演练切换流程与监控复制延迟，才能确保真正故障时从容应对。

常见误区与运维监控建议

不少团队误以为配置了流复制就天然具备高可用，却忽略了监控复制延迟与脑裂风险。如果同步备库网络中断，主库在synchronous_standby_names约束下可能阻塞所有写入，此时需有超时降级策略。另一些人把备库直接开放写权限，导致数据冲突无法回放，这是物理复制架构下严格禁止的操作。

运维上应持续采集pg_stat_replication中的write_lag、flush_lag、replay_lag，并结合告警阈值。对切换演练可每季度进行一次，验证备份有效性与promote耗时。日志中关注“received promote request”与时间线切换记录，能帮助复盘过程。只有把配置、监控、演练三者结合，PostgreSQL主从同步与故障切换才真正可靠。

PostgreSQL主从同步故障切换修改时间：2026-08-13 14:21:43