马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?立即注册
×
官方原文地点: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:利用同步复制
假如主节点失效时利用的是同步复制:
✔ 环境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实例)等等
示例设置文件
- [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 被以为处于网络分区的“失联一侧”:
- 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 延长 + 超时控制 来在“数据安全”和“服务可用性”之间做衡量。
免责声明:如果侵犯了您的权益,请联系站长及时删除侵权内容,谢谢合作!qidao123.com:ToB企服之家,中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |