【PG】PostgreSQL高可用之自动故障转移-repmgrd

1 简介

repmgrd (" replication manager daemon") 是一个管理和监视守护进程，运行在复制集群中的每个节点上。它可以自动执行故障转移和更新备用数据库以遵循新主数据库等操作，并提供有关每个备用数据库状态的监控信息。

rempgrd的设计是易于设置，不需要额外的外部基础设施。

repmgrd 提供的功能包括：

• 丰富的配置选项
• 能够用一条命令暂停 所有节点上的 repmgrd
• 可执行自定义脚本，故障转移中不同点的事件通知
• "见证服务器"
• "位置"配置选项，用于将潜在的候选节点限制在单个位置（例如，当节点分布在多个数据中心时）
• 多种探活方式（PostgreSQL ping、查询执行或新连接）
• 保留监测统计数据（可选）

总结一下repmgrd的功能：

• 丰富的配置
• 管理方便
• 自定义脚本
• 见证服务器
• 多数据中心
• 多种探活方式

• 监控统计数据

2 repmgrd 设置和配置

repmgrd是一个守护进程，在每个 PostgreSQL 节点上运行，当运行在主节点上时可以监视本地节点，当运行在从节点上 可以监控它所连接的上游节点（上游节点可以是：主节点或级联复制的另一个中间节点）。

rempgrd可以配置为在主节点或上游节点变得无法访问时提供故障转移功能，向repmgr 元数据库提供监控数据。

从repmgr 4.4 开始，当在主节点上运行时，repmgrd还可以监控从节点 断开/重新连接的情况

2.1 通用参数配置

以下配置选项适用于所有情况下的 repmgrd ：
monitor_interval_secs

检查上游节点可用性的时间间隔（以秒为单位，默认：2 ）。

connection_check_type

该选项connection_check_type用于选择 repmgrd用于确定上游节点是否可用的方法。

可选的值为：

• ping（默认）- 用于PQping()确定服务器可用性

• connection - 通过尝试与上游节点建立新连接来确定服务器可用性

• query - 通过现有连接在节点上执行 SQL 语句来确定服务器可用性

  该查询是一个最小的一次性查询SELECT 1，用于确定服务器是否可以接受查询。

reconnect_attempts

在启动故障转移之前，将尝试重新连接到无法访问的上游节点 的次数（默认值：6） 。

每次重新连接尝试之间会有reconnect_interval几秒的间隔。

reconnect_interval

尝试重新连接到无法访问的上游节点之间的 时间间隔（以秒为单位，默认值：10） 。

重新连接尝试的次数由参数定义reconnect_attempts。

degraded_monitoring_timeout

如果被监视的任一服务器（本地节点和/或上游节点）不再可用（降级监视模式），repmgrd将终止的时间间隔（以秒为单位）。（默认 -1）完全禁用此超时。

2.2 自动故障转移的必须参数

必须在repmgr.conf中设置 以下repmgrd选项：

• failover
• promote_command
• follow_command

示例

failover=automatic
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'

每个选项的详细信息如下：
failover

failover可以是automatic或manual 之一。

promote_command

当rempgrd确定当前节点将成为新的主节点 时，将在故障转移情况下执行promote_command中定义的程序或脚本。

通常promote_command设置为repmgr的 repmgr standby promote命令。

还可以提供 shell 脚本，例如在升级当前节点之前执行用户定义的任务。在这种情况下，脚本必须 在某个时刻执行repmgr standby promote以提升节点；如果不这样做，repmgr 元数据将不会更新，并且 repmgr将不再可靠地运行。

举例

Promotion_command='/usr/bin/repmgrstandby Promotion -f /etc/repmgr.conf --log-to-file'

请注意，该--log-to-file选项将导致由 repmgrd 执行时 由 repmgr 命令生成的日志 输出记录到 repmgrd日志文件中

特别注意 pg_bindir执行 promote_command 或 follow_command 时， repmgr将不适用；这些可以是用户定义的脚本，因此必须始终指定shell脚本的完整路径。

promote_command

可以接受两种参数

1 repmgr standby promote 命令

2 自定义shell脚本

注意：shell 脚本需要是绝对路径 ，可以通过--log-to-file 参数将日志输出到日志文件中

follow_command

当rempgrd确定当前节点将跟随新的主节点 时，将在故障转移情况下执行 follow_command中定义的程序或脚本

通常follow_command设置为repmgr的 repmgr standby follow命令。

follow_command参数提供的命令repmgr standby follow 需要添加参数 ``--upstream-node-id=%n 。%n将由带有新主节点 ID 的替换 。如果未提供此选项， repmgr standby follow 将尝试自行确定新的主节点，但如果在新的主节点升级后原始主节点重新上线，repmgr standby follow 则存在导致节点继续追随原始主节点的风险 。

还可以提供 shell 脚本，例如在升级当前节点之前执行用户定义的任务。在这种情况下，脚本必须 在某个时刻执行repmgr standby follow 以提升节点；如果不这样做，repmgr 元数据将不会更新，并且 repmgr将不再可靠地运行。

例子：

follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'

请注意，该--log-to-file选项将导致由 repmgrd 执行时由 repmgr 命令生成的输出记录到配置为接收repmgrd日志输出的同一目标。

follow_command

可以接受两种参数

1 ``repmgr standby follow 命令

2 自定义shell脚本

注意：

shell 脚本需要是绝对路径 ，

可以通过--log-to-file 参数将日志输出到日志文件中

需要添加参数 ``--upstream-node-id=%n 来传入新的主节点的node-id

2.3 自动故障转移的可选参数

priority

提升节点的优先级（默认： 100）。

请注意，仅当两个或更多节点被确定为升级候选者时才应用优先级设置；在这种情况下，将选择具有较高优先级的节点。

值为0 将始终阻止节点升级为主节点，即使没有其他升级候选节点。

failover_validation_command

用户定义的脚本，用于为外部机制执行以验证由repmgrd 做出的故障转移决策。可以提供以下一个或多个参数占位符，这些占位符将被 repmgrd 替换为适当的值：

• %n：节点ID
• %a: 节点名称
• %v：可见节点数
• %u：共享上游节点数量
• %t：节点总数
  always_promote

默认值：false.

如果true，则升级本地节点，即使其 repmgr 元数据不是最新的。

通常，repmgr希望其元数据（存储在表中repmgr.nodes ）是最新的，以便repmgrd可以在故障转移期间采取正确的操作。但是，在主数据库上进行的更新可能尚未传播到备用数据库（升级候选数据库）。在这种情况下，repmrd将默认不提升备用数据库。always_promote可以通过设置为 来覆盖此行为 true。

standby_disconnect_on_failover

在故障转移情况下，断开本地节点的 WAL 接收器。

PostgreSQL 9.5 及更高版本提供此选项。
repmgrd_exit_on_inactive_node

此参数在repmgr 5.3 及更高版本 中可用。

如果节点被标记为非活动但正在运行，并且此选项设置为 true，repmgrd将在启动时中止。

默认情况下，repmgrd_exit_on_inactive_node设置为false，在这种情况下，repmgrd将在启动时将节点记录设置为活动状态。

将此参数设置为true会导致rempgrd 的行为方式与在repmgr 5.2 及更早版本 中的行为方式相同。

以下选项可用于进一步微调故障转移行为。实际上，这些默认值不太可能需要更改，但如果需要，可以作为配置选项使用。
election_rerun_interval

如果failover_validation_command设置，并且命令返回错误，则在重新选举之前 将会暂停指定的秒数（默认值：15）。

sibling_nodes_disconnect_timeout

如果standby_disconnect_on_failover是，则等待其他备用数据库确认它们已断开其 WAL 接收器的 true最大时间长度（以秒为单位，默认值：30） 。

2.4 repmgrd服务配置

如果你想使用 repmgr daemon start 和 repmgr daemon stop 命令来管理repmgrd的进程，需要在配置文件 repmgr.conf 中设置参数：

• repmgrd_service_start_command
• repmgrd_service_stop_command

举例

repmgrd_service_start_command='sudo systemctl repmgr12 start'
repmgrd_service_stop_command='sudo systemctl repmgr12 stop'

2.5 监控配置

开启监控需要在配置文件repmgr.conf中设置

monitoring_history=yes

每隔monitor_interval_secs 秒将会写一次监控数据。更多的详细详细 参考： Storing monitoring data.

监控从节点断开的信息 参考 Monitoring standby disconnections on the primary.

3 repmgrd 运维管理

3.1 repmgrd启停

如果从软件包安装，repmgrd可以通过操作系统的服务命令启动，例如在systemd中 使用systemctl。

通过命令 repmgr daemon start 和 repmgr daemon stop 命令来管理repmgrd的进程 ，参考本篇文章的2.4

可以像这样手动启动 repmgrd

repmgrd -f /etc/repmgr.conf --pid 文件 /tmp/repmgrd.pid

停止

``kill `cat /tmp/repmgrd.pid```。

3.2 repmgrd的PID文件

rempgrd默认会生成一个 PID 文件。

PID 文件可以通过配置epmgr.conf中的参数 repmgrd_pid_file 指定。

也可以使用命令行参数在命令行上指定（如以前的版本）--pid-file。请注意，这将覆盖repmgr.conf中设置的任何值repmgrd_pid_file。 --pid-file可能会在未来版本中被弃用。

如果包维护者指定了 PID 文件位置，repmgrd 将使用该位置。这仅适用于从软件包安装 repmgr并且软件包维护者已指定 PID 文件位置的情况。

如果以上都不适用，repmgrd将在操作系统的临时目录中创建一个 PID 文件（由环境变量 确定 TMPDIR，或者如果未设置，将使用/tmp）。

要完全防止生成 PID 文件，请提供命令行选项 --no-pid-file。

要查看repmgrd将使用哪个PID 文件，请 使用选项执行repmgrd--show-pid-file。 如果提供此选项，repmgrd将不会启动。

请注意，显示的值是repmgrd下次启动时将使用的文件 ，不一定是当前使用的 PID 文件。

3.3 查看repmgrd进程

repmgr service status命令提供集群中所有节点上的 repmgrd守护程序状态（包括暂停状态） 的概述。

从repmgr 5.3开始。repmgr node check --repmgrd将用于检查本地节点上 repmgrd的状态（包括暂停状态）。

3.4 repmgrd连接设置

除了repmgr配置设置之外，字符串中的参数 conninfo还会影响repmgr与 PostgreSQL 建立网络连接的方式。特别是，如果复制集群中的另一台服务器在网络级别无法访问，则系统网络设置将影响确定无法连接所需的时间长度。

特别是应考虑显式设置参数connect_timeout；该参数的最小值（2秒） 将确保尽快报告网络级别的连接故障，否则根据系统设置（例如 在 Linux 中tcp_syn_retries），可能会延迟一分钟或更长时间。

有关conninfo网络连接参数的更多详细信息，请参阅 PostgreSQL 文档。

3.5 repmgrd日志轮转

为了确保当前的repmgrd日志文件（在repmgr.conf参数 中指定log_file）不会无限期地增长，请将您的系统配置logrotate为定期轮换它。

每周轮换日志文件的示例配置，保留时间长达 52 周，如果文件增长超过 100Mb，则强制轮换：

    /var/log/repmgr/repmgrd.log {
        missingok
        compress
        rotate 52
        maxsize 100M
        weekly
        create 0600 postgres postgres
        postrotate
            /usr/bin/killall -HUP repmgrd
        endscript
    }

3.6 repmgrd暂停功能

在正常操作中，repmgrd监视它正在运行的 PostgreSQL 节点的状态，如果检测到问题，将采取适当的操作，例如（如果如此配置）如果现有主节点已被确定为故障，则将节点提升为主节点。

但是，repmgrd无法区分计划中断（例如执行切换 或安装 PostgreSQL 维护版本）和实际服务器中断。在repmgr 4.2之前的版本中， 必须在所有节点上停止repmgrd（或者至少在为自动故障转移配置repmgrd 的所有节点上），以防止repmgrd对复制集群进行无意的更改。

从repmgr 4.2开始，repmgr 现在可以"暂停"，即指示不要采取任何操作，例如执行故障转移。这可以从集群中的任何节点完成，无需单独停止/重新启动每个repmgrd。

暂停是为了在有计划内中断

为了能够暂停/取消暂停repmgrd，必须满足以下先决条件：

• 所有节点上必须安装repmgr4.2或更高版本。
• 必须在所有节点上安装相同的主要repmgr版本（例如 4.2）（最好是相同的次要版本）。
• 所有节点上的 PostgreSQL 必须可以从执行pause/unpause操作的节点访问 ，使用conninfo所示的字符串repmgr cluster show。

暂停
repmgr -f /etc/repmgr.conf service pause

取消暂停

repmgr -f /etc/repmgr.conf service unpause

3.7 repmgrd WAL重放

如果 WAL 重放已暂停（pg_wal_replay_pause()在 PostgreSQL 9.6 及更早版本上使用pg_xlog_replay_pause(), ），在故障转移情况下，repmgrd将自动恢复 WAL 重放。

这是因为，如果 WAL 重放暂停，但 WAL 正在等待重放， WAL 重放之前，则在恢复PostgreSQL 的节点无法进行提升。

3.8 repmgrd**"降级监控"模式**

在某些情况下，repmgrd无法完成其监视节点上游服务器的主要任务。在这些情况下，它会进入"降级监控"模式，在该模式下，repmgrd保持活动状态，但正在等待情况得到解决。

发生这种情况的情况有：

• 发生故障转移情况，主节点所在位置的节点不可见
• 发生了故障转移情况，但没有可用的提升节点
• 发生了故障转移情况，但无法提升节点
• 发生了故障转移情况，但该节点无法成为新的主节点的从节点
• 发生了故障转移情况，但没有可用的主数据库
• 发生故障转移情况，但节点未启用自动故障转移
• repmgrd 正在监控主节点，但它不可用（并且没有其他节点被提升为主节点）

默认情况下，repmgrd将无限期地继续处于降级监控模式。然而，可以使用 degraded_monitoring_timeout 设置超时（以秒为单位），之后rempgrd将终止。

3.9 repmgrd 监控数据

当repmgrd使用选项运行时 monitoring_history=true，它会不断地将备用节点状态信息写入表中 monitoring_history，从而提供集群中所有节点上的复制状态的近乎实时的概述。

该视图replication_status显示每个节点的最新状态，例如：

select * from repmgr.replication_status;

写入监控历史记录的时间间隔由配置参数控制monitor_interval_secs；默认值为 2。

因为这样会在repmgr.monitoring_history表中产生大量的监控数据 。建议使用repmgr cluster cleanup 命令定期清除历史数据；使用该-k/--keep-history选项指定应保留多少天的数据。

仅监控模式

通过在节点 repmgr.conf文件中进行设置 failover=manual ，可以使用repmgrd在某些或所有节点的监视模式下运行（没有自动故障转移功能）。如果节点的上游发生故障，则不会采取故障转移操作，并且节点将需要手动干预才能重新连接到复制。如果发生这种情况， 将创建 standby_disconnect_manual事件通知。

请注意，当备用节点不直接从其上游节点进行流传输时，例如从存档中恢复 WAL，apply_lag将始终显示为 0 bytes。