官方原文地址：https://pg-auto-failover.readthedocs.io/en/main/ref/configuration.html，原文行文逻辑并不清晰，甚至有些混乱，前两部分都是有关pgautofailover的monitor的参数配置，却分成了两个重复的部分。
以下来自于chatgpt的翻译以及笔者自己的理解
pg_auto_failover 提供了一些默认配置参数，你可以根据生产环境中的权衡进行调整。这些参数会影响以下几个方面：
笔者注：
1，这是什么层面的参数？这是pgautofailover的monitor节点上的PostgreSQL实例级别的参数，类似于Postgresql的参数
2，这些参数会影响什么？这些参数决定了对数据节点发生故障时的故障判断逻辑和自动故障转移逻辑
当 pg_auto_failover 检测到主节点（primary）不健康时，会决定是否触发故障切换（failover）并提升从节点（secondary）。
以下参数会影响监控节点（monitor）何时决定提升从节点：
pgautofailover.health_check_max_retriespgautofailover.health_check_periodpgautofailover.health_check_retry_delaypgautofailover.health_check_timeoutpgautofailover.node_considered_unhealthy_timeout在提升从节点时，pg_auto_failover 会等待以下超时时间：确保主节点关闭前的所有写入都已同步到从节点，从而避免数据丢失
相关参数：
pgautofailover.primary_demote_timeout，该参数默认为30秒，也即monitor节点发现主节点故障之后，继续等待primary_demote_timeout之后，再promote从节点为新的主节点如何防止网络分区（脑裂）的参数？primary_demote_timeout VS network_partition_timeout
network_partition_timeout 默认值是20秒
primary_demote_timeout 默认值是30秒，
为什么可以避免脑裂？网络分区后，原始主节点在等待network_partition_timeout 自动关停本地PostgreSQL服务（自杀），新的主节点在primary_demote_timeout 之后才提升，primary_demote_timeout >network_partition_timeout ，因此任意时刻都不会出现双主的情况， 这两个参数就可以避免网络分区时双主（脑裂）的发生。
pg_auto_failover 采用一种权衡策略：数据可用性优先于服务可用性
也就是说：
如果主节点失效时使用的是同步复制：
如果从节点之前被检测为不健康：
SECONDARY → CATCHING-UP以下参数允许在一定 WAL 差距内仍然提升从节点：
pgautofailover.promote_wal_log_threshold监控节点的配置存储在 PostgreSQL 数据库中（安装扩展的数据库）：
笔者注，这跟上一个章节一样，都是monitor节点参数的表述：
1，这是什么层面的参数？这是pgautofailover的monitor节点上的PostgreSQL实例级别的参数，类似于Postgresql的参数
2，这些参数会影响什么？这些参数决定了对数据节点发生故障时的故障判断逻辑和自动故障转移逻辑
pgautofailover.enable_sync_wal_log_thresholdhealth_check_max_retries：最大重试次数，默认值是2health_check_period：检查周期（毫秒），默认值是5000，也即5秒health_check_retry_delay：重试间隔，默认值是2000，也即2秒health_check_timeout：连接超时，默认值是5000，也即5秒node_considered_unhealthy_timeout：超过多久未响应则认为节点不健康，默认值是20000，也即20秒primary_demote_timeout，默认值30秒pg_auto_failover会等待一定时间，由这个参数决定，超过这个参数设置的时间之后再正式提升为主节点，以确保主服务器上所有待处理的写入操作在关闭时都已同步到备服务器，从而防止数据丢失。promote_wal_log_thresholdstartup_grace_period可以通过以下方式修改：
postgresql.confKeeper 负责管理本节点行为。
笔者注：
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 show uri 提供）
集群名称（默认 default）
节点组编号（注册后不要修改）
节点地址（用于复制和通信）
复制槽名称（不可修改）
使用 pg_basebackup 构建从节点时的带宽限制（默认 100Mbps）
从主节点复制数据时的目标目录
⚠️ 注意：
pgdata在多少秒内无法与其他节点通信，则认为发生网络分区。
如果 PRIMARY 被认为处于网络分区的“失联一侧”：
DEMOTE默认值：20 秒
笔者注：网络分区后，原始的主节点等待20秒（network_partition_timeout参数决定）之后，自身会demote，此时pgautofailover服务会运行，但是Postgresql服务会自动关闭，等于是本地服务“自杀”但是有没有彻底“死”，至于为什么pgautofailover服务自身会运行而不是彻底停止，很简单，等网络恢复后，pgautofailover服务探测到网络正常会，重启Postgresql服务，并且将当前节点会以从节点的身份加入到集群中。
postgresql_restart_failure_timeoutpostgresql_restart_failure_max_retries当 PostgreSQL 未运行时：
如果仍失败： 再向 monitor 请求 failover
一句话总结
pg_auto_failover 的核心是通过 健康检查 + WAL 延迟 + 超时控制 来在“数据安全”和“服务可用性”之间做权衡。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。