PostgreSQL集群脑裂指的是在主备复制架构中，由于网络分区、节点宕机或故障转移协调失灵，导致两个甚至多个节点同时认为自己是主库，进而同时对外提供写入服务。这种情况破坏了PostgreSQL流复制环境下一主多备的基本假设，最直接的后果是产生两个相互独立的数据分叉，恢复时不仅需要停机，还可能丢失部分已提交事务。因此，理解脑裂的成因和预防手段，是每一位负责PostgreSQL高可用架构的数据库管理员必须掌握的技能。
一、脑裂是如何产生的
PostgreSQL本身并不提供自动故障转移功能，流复制架构下的主备切换通常由外部工具完成，如Patroni、repmgr或企业级高可用套件。这些工具通过心跳检测主库健康状态，当主库连续多个周期无法响应时，便会触发备库提升。问题在于，心跳超时并不等同于主库真正宕机。主库可能只是网络抖动、负载过高或者监控进程卡死，此时备库已经提升为新主库，而旧主库仍然存活且继续接受客户端的写入请求，于是集群中出现两个主库，脑裂就此产生。
最常见的触发场景是网络分区。比如主库与备库之间的交换机故障，或者跨机房的专线中断，导致主库无法与集群中的其他节点通信。此时协调服务也可能无法访问主库，从而误判主库失联。另一种典型情况是fencing失败：当故障转移工具试图隔离旧主库时，如果调用云API停止实例失败、STONITH设备不可用或者看门狗未生效，旧主库就不会被强制下线，双主状态将持续存在。此外，心跳超时设置过短也会加剧误判，例如将loop_wait设置为1秒，网络抖动时很容易触发不必要的切换。
脑裂的危害非常严重。两个主库会各自生成WAL日志，时间线发生分叉，应用可能将数据写入不同节点，造成主键冲突、外键不一致、事务丢失。即使后来网络恢复，两个节点的数据已经无法通过流复制自动合并，必须人工介入选择保留哪个数据版本，并修复另一个节点。对于金融、电商等业务系统，脑裂期间的每一秒都可能造成资金或订单异常，因此预防远比事后处理更为重要。
二、预防脑裂的常用机制
预防脑裂的核心思路是确保在同一时刻只有一个节点能够成为主库，并且旧主库必须被有效隔离。基于法定人数的决策机制是最基础的保障。在Patroni架构中，集群状态保存在etcd、Consul或ZooKeeper等分布式协调服务中。只有获得多数节点投票的节点才能被提升为主库，如果某个节点无法与协调服务通信，即使它原本是主库，也会自动降级或拒绝写入。这避免了因网络分区导致的双主问题。配置Patroni时，通过bootstrap.dcs中的ttl和loop_wait参数控制心跳周期，合理的值能让协调服务快速感知节点失联，同时避免误判。
隔离机制（Fencing）是预防脑裂的第二道防线。当协调服务决定切换主库时，必须确保旧主库不再对外提供写入服务。常见做法包括：调用云厂商API强制停止旧主库实例；使用STONITH设备切断旧主库电源；或者在本机执行pg_ctl stop -m immediate立即停止PostgreSQL。Patroni允许配置自定义fencing脚本，在切换前强制执行隔离操作。如果隔离失败，切换应该中止，而不是冒险产生双主。看门狗（Watchdog）则提供了一层内核级别的保护：Patroni可以启用Linux内核看门狗设备/dev/watchdog，当主进程因网络异常、CPU饥饿等原因无法更新看门狗时，系统会在几秒内强制重启节点，从而让旧主库真正下线。
以下是一个Patroni配置示例，启用了etcd作为分布式协调服务，并配置了看门狗自动模式：
scope: postgres-cluster
namespace: /db/
name: postgresql0
restapi:
listen: 0.0.0.0:8008
connect_address: 192.168.1.10:8008
etcd:
host: 192.168.1.10:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
parameters:
wal_level: replica
hot_standby: on
max_connections: 200
watchdog:
mode: automatic
device: /dev/watchdog
safety_margin: 5
除了上述机制，同步复制也能在一定程度上降低脑裂后的数据丢失风险。将synchronous_commit设置为remote_apply，并且至少保留一个同步备库，可以确保主库提交的事务已经同步到备库。这样即使发生切换，新主库也拥有最近提交的数据，减少了数据分叉的严重程度。但同步复制并不能阻止双主出现，它必须与法定人数、隔离机制配合使用。此外，监控和告警也需要覆盖心跳超时、fencing失败、看门狗触发等事件，以便运维人员第一时间发现异常。
三、脑裂发生后的处理流程
即使预防措施再完善，极端情况下仍可能发生脑裂。处理脑裂的第一步是确认当前集群状态，避免在情况不明时盲目操作。可以使用patronictl list命令查看各节点的角色、状态和复制延迟。如果使用repmgr，则执行repmgr cluster show。命令输出中通常包含节点名称、主机地址、角色（Leader或Replica）、状态以及事务日志位置。下面是一个patronictl命令示例：
patronictl -c /etc/patroni/patroni.yml list +--------------+---------------+---------+---------+----+-----------+ | Member | Host | Role | State | TL | Lag in MB | +--------------+---------------+---------+---------+----+-----------+ | postgresql0 | 192.168.1.10 | Leader | running | 1 | 0 | | postgresql1 | 192.168.1.11 | Replica | running | 1 | 0 | +--------------+---------------+---------+---------+----+-----------+
确认存在两个Leader后，必须立即隔离旧主库。无论最终选择保留哪个节点，旧主库都必须停止对外写入。可以通过停止PostgreSQL服务、修改pg_hba.conf拒绝应用连接，或者在网络层通过防火墙规则阻断5432端口。这一步必须果断，因为继续写入只会让数据分叉更加严重。隔离完成后，再根据业务影响和数据新鲜度选择保留哪一个节点作为主库。一般建议选择事务日志位置（LSN）最新的节点，因为它的数据最完整。可以通过pg_controldata查看每个节点的WAL位置，或者使用pg_wal_lsn_diff函数比较。
选定主库后，需要将另一个节点回退并重新加入集群。如果旧主库启用了wal_log_hints或数据目录开启了checksum，可以使用pg_rewind工具快速回退。pg_rewind会对比两个数据目录的差异，将旧主库的时间线重置为目标主库的时间线，使其能够作为备库继续复制。以下是一个pg_rewind命令示例：
systemctl stop postgresql
pg_rewind --target-pgdata=/var/lib/postgresql/14/main \
--source-pgdata=/var/lib/postgresql/14/backup \
--no-ensure-shutdown
如果pg_rewind无法使用，或者数据分叉过于严重，则需要手动重建备库。可以先备份旧主库的数据，然后用pg_basebackup从新主库创建一个全新的备库，再删除旧数据目录并恢复。重新加入集群后，需要验证流复制状态，执行select * from pg_stat_replication查看备库是否正常连接，确认复制延迟接近零。最后，复盘脑裂的根因，调整心跳超时、网络冗余、fencing脚本和看门狗配置，同时补充监控告警，避免同样的问题再次发生。整个处理过程应形成标准操作手册，并定期演练，确保在真实故障中能够快速恢复。
PostgreSQL集群脑裂预防高可用修改时间：2026-08-24 17:21:51