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 会等待以下超时时间：确保主节点关闭前的所有写入都已同步到从节点，从而避免数据丢失

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，默认值30秒
在副本节点提升为主节点时，pg_auto_failover会等待一定时间，由这个参数决定，超过这个参数设置的时间之后再正式提升为主节点，以确保主服务器上所有待处理的写入操作在关闭时都已同步到备服务器，从而防止数据丢失。

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实例）等等

示例配置文件


[pg_autoctl]
role = keeper
monitor = postgres://autoctl_node@192.168.1.34:6000/pg_auto_failover
formation = default
group = 0
hostname = node1.db
nodekind = standalone

[postgresql]
pgdata = /data/pgsql/
pg_ctl = /usr/pgsql-10/bin/pg_ctl
dbname = postgres
host = /tmp
port = 5000

[replication]
slot = pgautofailover_standby
maximum_backup_rate = 100M
backup_directory = /data/backup/node1.db

[timeout]
network_partition_timeout = 20
postgresql_restart_failure_timeout = 20
postgresql_restart_failure_max_retries = 3

配置管理命令

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

root@ubuntu11:~# pg_autoctl config set timeout.network_partition_timeout 10
10
root@ubuntu11:~# pg_autoctl config get timeout.network_partition_timeout
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 延迟 + 超时控制来在“数据安全”和“服务可用性”之间做权衡。

posted on 2026-04-02 08:45 MSSQL123 阅读(74) 评论(0) 收藏举报

刷新页面返回顶部

专注，勤学，慎思。戒骄戒躁，谦虚谨慎

导航