pg_auto_failover 配置参数

官方原文地址：https://pg-auto-failover.readthedocs.io/en/main/ref/configuration.html，原文行文逻辑并不清晰，甚至有些混乱，前两部分都是有关pgautofailover的monitor的参数配置，却分成了两个重复的部分。
以下来自于chatgpt的翻译以及笔者自己的理解
 

---

配置 pg_auto_failover

pg_auto_failover 提供了一些默认配置参数，你可以根据生产环境中的权衡进行调整。这些参数会影响以下几个方面：
笔者注：
1，这是什么层面的参数？这是pgautofailover的monitor节点上的PostgreSQL实例级别的参数，类似于Postgresql的参数
2，这些参数会影响什么？这些参数决定了对数据节点发生故障时的故障判断逻辑和自动故障转移逻辑

---

1. 决定何时提升（promote）从节点

当 pg_auto_failover 检测到主节点（primary）不健康时，会决定是否触发故障切换（failover）并提升从节点（secondary）。
以下参数会影响监控节点（monitor）何时决定提升从节点：

• pgautofailover.health_check_max_retries
  
• pgautofailover.health_check_period
  
• pgautofailover.health_check_retry_delay
  
• pgautofailover.health_check_timeout
  
• pgautofailover.node_considered_unhealthy_timeout
  

---

2. 提升从节点所需时间

在提升从节点时，pg_auto_failover 会等待以下超时时间：确保主节点关闭前的所有写入都已同步到从节点，从而避免数据丢失
相关参数：

• pgautofailover.primary_demote_timeout，该参数默认为30秒，也即monitor节点发现主节点故障之后，继续等待primary_demote_timeout之后，再promote从节点为新的主节点
  

---

3. 防止从节点随意被提升为主节点

pg_auto_failover 采用一种权衡策略：数据可用性优先于服务可用性
也就是说：

• 当主节点故障时
  
• 只有在“主节点失效时，从节点是健康且可用”的情况下才会被提升
  

---

✔ 情况1：使用同步复制

如果主节点失效时使用的是同步复制：

• WAL 延迟为 0
  
• 可以安全切换到从节点
  

---

✔ 情况2：从节点之前不健康

如果从节点之前被检测为不健康：

• 状态从 SECONDARY → CATCHING-UP
  
• 不允许提升
  

---

✔ 可强制提升（允许数据丢失）

以下参数允许在一定 WAL 差距内仍然提升从节点：

• pgautofailover.promote_wal_log_threshold
  

---

 

pg_auto_failover Monitor（监控节点）

监控节点的配置存储在 PostgreSQL 数据库中（安装扩展的数据库）：
select name, setting, unit, short_desc
from pg_settings
where name ~ 'pgautofailover.';
笔者注，这跟上一个章节一样，都是monitor节点参数的表述：
1，这是什么层面的参数？这是pgautofailover的monitor节点上的PostgreSQL实例级别的参数，类似于Postgresql的参数
2，这些参数会影响什么？这些参数决定了对数据节点发生故障时的故障判断逻辑和自动故障转移逻辑

---

参数说明

1. 同步复制阈值

• pgautofailover.enable_sync_wal_log_threshold
  在从节点 WAL 落后主节点一定字节数以内时才启用同步复制，默认值是16777216字节，16MB，也即一个WAL日志文件
  

---

2. 健康检查参数

• health_check_max_retries：最大重试次数，默认值是2
  
• health_check_period：检查周期（毫秒），默认值是5000，也即5秒
  
• health_check_retry_delay：重试间隔，默认值是2000，也即2秒
  
• health_check_timeout：连接超时，默认值是5000，也即5秒
  
• node_considered_unhealthy_timeout：超过多久未响应则认为节点不健康，默认值是20000，也即20秒
  

---

3. 主节点降级等待时间

• primary_demote_timeout
  提升从节点前，等待主节点“排空写入”的时间，primary_demote_timeout 用来给主节点（PRIMARY）留出时间，将（可能）未同步到从节点的数据“排空”后再真正降级，确保 secondary 可以安全接管。
  

---

4. 提升 WAL 阈值

• promote_wal_log_threshold
  从节点 WAL 落后不超过该值时才允许提升，默认值是16777216字节，16MB，也即一个WAL日志文件  
  

---

5. 启动保护时间

• startup_grace_period
  启动后等待一段时间再允许触发故障切换，默认值是10000，也即10秒
  

---

修改配置方式

可以通过以下方式修改：

• postgresql.conf
  
• 或 SQL：ALTER DATABASE pg_auto_failover SET parameter = value;然后执行 reload 生效。
  

---

 

pg_auto_failover Keeper 服务

Keeper 负责管理本节点行为。
笔者注：
1，如何找到这个配置文件？该文件是一个隐藏文件，有pgautofailover自动创建，su - postgres切换到postgres用户下，执行 pg_autoctl show files，monitor节点的role是monitor，数据节点的role是keeper
2，这个配置文件中参数的作用？这是keeper节点也即数据节点的运行配置，包含了向谁（monitor地址）汇报自身的状态，节点故障后自身的处理逻辑（重启本地Postgresql实例）等等

---

示例配置文件

1. [pg_autoctl]
2. role = keeper
3. monitor = postgres://autoctl_node@192.168.1.34:6000/pg_auto_failover
4. formation = default
5. group = 0
6. hostname = node1.db
7. nodekind = standalone
9. [postgresql]
10. pgdata = /data/pgsql/
11. pg_ctl = /usr/pgsql-10/bin/pg_ctl
12. dbname = postgres
13. host = /tmp
14. port = 5000
16. [replication]
17. slot = pgautofailover_standby
18. maximum_backup_rate = 100M
19. backup_directory = /data/backup/node1.db
21. [timeout]
22. network_partition_timeout = 20
23. postgresql_restart_failure_timeout = 20
24. postgresql_restart_failure_max_retries = 3

复制代码

---

配置管理命令

pg_autoctl config check
pg_autoctl config get section.option
pg_autoctl config set section.option value
示例

1. root@ubuntu11:~# pg_autoctl config set timeout.network_partition_timeout 10
2. 10
3. root@ubuntu11:~# pg_autoctl config get timeout.network_partition_timeout
4. 10

复制代码

---

关键配置说明

---

pg_autoctl.monitor

监控节点连接字符串（由 pg_autoctl show uri 提供）

---

pg_autoctl.formation

集群名称（默认 default）

---

pg_autoctl.group

节点组编号（注册后不要修改）

---

pg_autoctl.hostname

节点地址（用于复制和通信）

---

replication.slot

复制槽名称（不可修改）

---

replication.maximum_backup_rate

使用 pg_basebackup 构建从节点时的带宽限制（默认 100Mbps）

---

replication.backup_directory

从主节点复制数据时的目标目录
⚠️ 注意：

• 最终会重命名为 pgdata
  
• 必须在同一文件系统内才能保证原子性
  

---

timeout 配置（重点）

---

network_partition_timeout

在多少秒内无法与其他节点通信，则认为发生网络分区。

• 仅在 PRIMARY 节点检查
  
• 其他节点包括：
  
  
  
  • monitor
    
  • standby
    
  
  

行为：

如果 PRIMARY 被认为处于网络分区的“失联一侧”：

• keeper 进入 DEMOTE
  
• 停止 PostgreSQL
  
• 防止脑裂（split brain）
  

默认值：20 秒
笔者注：网络分区后，原始的主节点等待20秒（network_partition_timeout参数决定）之后，自身会demote，此时pgautofailover服务会运行，但是Postgresql服务会自动关闭，等于是本地服务“自杀”但是有没有彻底“死”，至于为什么pgautofailover服务自身会运行而不是彻底停止，很简单，等网络恢复后，pgautofailover服务探测到网络正常会，重启Postgresql服务，并且将当前节点会以从节点的身份加入到集群中。

---

PostgreSQL 重启失败处理

参数：

• postgresql_restart_failure_timeout
  
• postgresql_restart_failure_max_retries
  

---

行为：

当 PostgreSQL 未运行时：

• keeper 尝试重启
  
• 如果失败：
  
  
  
  • 最多重试 N 次（默认 3）
    
  • 或在超时时间内（默认 20 秒）
    
  
  

如果仍失败： 再向 monitor 请求 failover

---

 
一句话总结
pg_auto_failover 的核心是通过 健康检查 + WAL 延迟 + 超时控制 来在“数据安全”和“服务可用性”之间做权衡。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！