pg_auto_failover 可上生产但需匹配运维能力，它仅协调流复制、故障探测与切换，不处理备份、wal损坏、网络分区脑裂等问题，须手动补全监控、归档、连接管理等关键环节。
postgresql 流复制 + pg_auto_failover 能不能直接上生产
能，但得先确认你的运维能力是否匹配它的“自动”程度。pg_auto_failover 本质是封装了流复制+故障探测+角色切换的协调器，不是开箱即用的黑盒——它不接管你的备份、不修复损坏的 WAL、也不帮你处理网络分区时的脑裂。
常见错误现象：node is marked as unhealthy 却查不到明显异常；waiting for primary to become healthy 卡住半天；failover 后应用连不上新主库（没更新连接串或 DNS 缓存）。
- 必须提前配置好
pg_hba.conf，让所有节点（包括 monitor）能双向免密连接彼此的 PostgreSQL 实例，否则 monitor 根本无法探活 - monitor 节点必须独立部署（别和 pg 实例混跑），否则它挂了整个高可用就失效
- 应用层必须支持重连，且连接串里别写死单个 IP；推荐用 keepalived + VIP 或服务发现（如 consul）解耦
-
pg_auto_failover默认只监控进程存活和复制延迟，不检查磁盘满、WAL 归档失败等场景，这些得自己补监控项
流复制备库为什么迟迟不接受只读查询
因为还没真正进入“hot standby”状态——PostgreSQL 在恢复中会拒绝所有客户端连接，直到完成基础备份加载并开始接收 WAL 流。
使用场景：搭建完 standby 后执行 psql -h standby-host -c "select 1" 报错 FATAL: the database system is starting up。
- 检查
pg_stat_replication视图：主库上查不到该备库记录，说明流复制根本没连上（大概率是postgresql.conf没开wal_level = replica或max_wal_senders不够） - 检查备库
postgresql.log：出现replication connection authorized才算链路通了；若一直卡在recovering，可能是recovery.conf（或standby.signal）缺失，或primary_conninfo里密码错了 - 确认备库
postgresql.conf中设置了hot_standby = on，这个参数必须重启生效，且仅对 9.0+ 有效
pg_auto_failover 切换后应用报错 “FATAL: terminating connection due to administrator command”
这是正常现象，不是故障。failover 触发时，原主库会被 pg_auto_failover 执行 pg_ctl promote -w 或直接发 SIGTERM 强制终止所有连接，为的是确保数据一致性。
性能 / 兼容性影响：这个中断时间取决于你设置的 failover_timeout（默认 10 秒）和应用重连逻辑——如果应用没设重试，就会直接报错退出。
- 应用连接池（如 PgBouncer、HikariCP）必须开启
auto-commit和连接验证（例如用SELECT 1），并在连接异常时自动重建 - 避免在事务中长时间 hold 连接；failover 窗口内未提交的事务一律回滚，没有“续传”这回事
- 别依赖 PostgreSQL 自带的
application_name做路由判断——切主后这个值不会变，容易把流量继续打到旧主（已降为备库）
归档 + PITR 跟高可用是两回事，别指望 pg_auto_failover 自动帮你恢复误删数据
流复制只同步物理块变化，PITR（基于时间点恢复）依赖的是归档的 WAL 文件和基础备份。pg_auto_failover 完全不碰归档配置，也不会触发 pg_basebackup。
容易踩的坑：以为启用了高可用就等于有备份，结果 DROP table 后发现只能回退到上次基础备份，中间几小时数据全丢。
- 必须单独配置
archive_mode = on、archive_command（推荐用rsync或aws s3 cp），并定期验证归档文件可读 - 基础备份不能只做一次：用
pg_basebackup -X stream配合cron定期执行，保留至少 2–3 份 - 归档路径必须对所有节点可见（如 NFS 或对象存储），否则 failover 后新主库可能无法访问旧 WAL 继续恢复
最常被忽略的一点：monitor 节点本身不存任何 PostgreSQL 数据，它的数据库只是记录集群状态。一旦 monitor 磁盘损坏且没备份，整个集群的 failover 历史和当前拓扑就丢了——但它不影响正在运行的主从服务，这点要分清。