吉林中岩峰建设有限公司网站,做职业资格考试的网站有哪些,技术支持 创思佳网站建设,网站需求报告怎么写前言 上面的几篇文章介绍了repmgr的部署#xff0c;手动进行 从节点提升#xff0c;主从切换#xff0c;孤立从从节点找到新的主库等操作#xff0c;但是都是需要通过手动去执行命令。大家都知道#xff0c;在线上生产环境中数据库每秒钟的不可用都会造成严重的事故手动进行 从节点提升主从切换孤立从从节点找到新的主库等操作但是都是需要通过手动去执行命令。大家都知道在线上生产环境中数据库每秒钟的不可用都会造成严重的事故所以等到收到告警再去手动处理是不太能被接受的。我们需要一个自动化的程序去帮助我们发现故障完成故障的自动切换发送通知记录问题等。repmgr提供了工具repmgrd可以完成以上的场景。本篇文章介绍repmrgd的配置参数运维管理测试repmrgd进行自动故障的切换。 目录 前言 1 简介
2 repmgrd 设置和配置
2.0 PostgreSQL必须配置
2.1 通用参数配置
2.2 自动故障转移的必须参数
2.3 自动故障转移的可选参数
2.4 repmgrd服务配置
2.5 监控配置
3 repmgrd 运维管理
3.1 repmgrd启停
3.2 repmgrd的PID文件
3.3 查看repmgrd进程
3.4 repmgrd连接设置
3.5 repmgrd日志轮转
3.6 repmgrd暂停功能
3.7 repmgrd WAL重放
3.8 repmgrd“降级监控”模式
3.9 repmgrd 监控数据
仅监控模式
4 实验验证自动故障切换
停止主库前查看状态
停止主库
查看日志 1 简介
repmgrd ( replication manager daemon) 是一个管理和监视守护进程运行在复制集群中的每个节点上。它可以自动执行故障转移和更新备用数据库以遵循新主数据库等操作并提供有关每个备用数据库状态的监控信息。
rempgrd的设计是易于设置不需要额外的外部基础设施。
repmgrd 提供的功能包括
丰富的配置选项能够用一条命令暂停 所有节点上的 repmgrd可执行自定义脚本故障转移中不同点的事件通知 “见证服务器”“位置”配置选项用于将潜在的候选节点限制在单个位置例如当节点分布在多个数据中心时多种探活方式PostgreSQL ping、查询执行或新连接保留监测统计数据可选 总结一下repmgrd的功能 丰富的配置管理方便自定义脚本见证服务器多数据中心多种探活方式监控统计数据 2 repmgrd 设置和配置 repmgrd是一个守护进程在每个 PostgreSQL 节点上运行当运行在主节点上时可以监视本地节点当运行在从节点上 可以监控它所连接的上游节点上游节点可以是主节点或级联复制的另一个中间节点。
rempgrd可以配置为在主节点或上游节点变得无法访问时提供故障转移功能向repmgr 元数据库提供监控数据。
从repmgr 4.4 开始当在主节点上运行时repmgrd还可以监控从节点 断开/重新连接的情况
2.0 PostgreSQL必须配置
要使用 repmgr必须在 postgresql.conf设置一下参数 并重启postgresql才能生效。
shared_preload_libraries repmgr
关于这个参数的官方文档 PostgreSQL: Documentation: 16: 20.11. Client Connection Defaults
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选项 failoverpromote_commandfollow_command 示例
failoverautomatic
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 及更高版本 中可用。 如果节点被标记为非活动但正在运行并且此选项设置为 truerepmgrd将在启动时中止。 默认情况下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_commandrepmgrd_service_stop_command 举例 repmgrd_service_start_commandsudo systemctl repmgr12 start
repmgrd_service_stop_commandsudo systemctl repmgr12 stop 2.5 监控配置 开启监控需要在配置文件repmgr.conf中设置 monitoring_historyyes 每隔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-file/home/storage/repmgr/repmgrd.pid 停止 kill cat /home/storage/repmgr/repmgrd.pid 启动报错 1 [ERROR] unable to write to shared memory [HINT] ensure shared_preload_libraries includes repmgr $cat /home/storage/repmgr/repmgr.log
[2023-11-16 11:13:03] [NOTICE] repmgrd (repmgrd 5.3.3) starting up
[2023-11-16 11:13:03] [INFO] connecting to database host10.79.21.30 port5432 userrepmgr dbnamerepmgr connect_timeout2
[2023-11-16 11:13:03] [ERROR] unable to write to shared memory
[2023-11-16 11:13:03] [HINT] ensure shared_preload_libraries includes repmgr
[2023-11-16 11:13:03] [INFO] repmgrd terminating... 解决 设置参数 shared_preload_libraries repmgr 然后重启 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的状态包括暂停状态。 repmgr -f /etc/repmgr.conf node check --repmgrd $repmgr -f /etc/repmgr.conf node check --repmgrd
OK (repmgrd running) 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则强制轮换 vi /etc/logrotate.conf /home/storage/repmgr/repmgr.log {missingokcompressrotate 52maxsize 100Mweeklycreate 0600 postgres postgrespostrotate/usr/bin/killall -HUP repmgrdendscript
}/home/storage/repmgr/repmgr.log : 指定需要轮转的日志文件的路径。
missingok: 如果日志文件不存在不产生错误。
compress: 在轮转时使用 gzip 进行压缩。
rotate 52: 保留 52 个旧的日志文件备份。
maxsize 100M: 当日志文件大小达到 100MB 时触发轮转。
weekly: 指定日志文件每周轮转一次。
create 0600 postgres postgres: 在轮转后创建一个新的空日志文件权限设置为 0600属主和属组设置为 postgres。postrotate ... endscript: 在轮转后执行的脚本。在这里它使用 killall 命令发送 SIGHUP 信号给 repmgrd 进程。这可以用于通知 repmgrd 重新加载配置或进行其他操作。
手动执行 /usr/bin/killall -HUP repmgrd 该命令 日志文件中会输出如下信息[2023-11-16 15:48:05] [NOTICE] received SIGHUP, reloading configuration
[2023-11-16 15:48:05] [INFO] reloading configuration file
[2023-11-16 15:48:05] [DETAIL] using file /etc/repmgr.conf
[2023-11-16 15:48:05] [NOTICE] configuration was successfully changed
[2023-11-16 15:48:05] [DETAIL] following configuration items were changed:monitoring_history changed from false to true这个配置确保了 repmgrd 的日志文件能够被轮转并在需要时进行压缩同时保留一定数量的历史备份。轮转后会创建一个新的、空的日志文件而 postrotate 部分用于触发某些操作这里是发送 SIGHUP 信号给 repmgrd 进程。 手动执行轮转 查看效果 logrotate -v /etc/logrotate.conf 3.6 repmgrd暂停功能 在正常操作中repmgrd监视它正在运行的 PostgreSQL 节点的状态如果检测到问题将采取适当的操作例如如果如此配置如果现有主节点已被确定为故障则将节点提升为主节点。 但是repmgrd无法区分计划中断例如执行切换 或安装 PostgreSQL 维护版本和实际服务器中断。在repmgr 4.2之前的版本中 必须在所有节点上停止repmgrd或者至少在为自动故障转移配置repmgrd 的所有节点上以防止repmgrd对复制集群进行无意的更改。 从repmgr 4.2开始repmgr 现在可以“暂停”即指示不要采取任何操作例如执行故障转移。这可以从集群中的任何节点完成无需单独停止/重新启动每个repmgrd。 暂停是为了在有计划内中断 为了能够暂停/取消暂停repmgrd必须满足以下先决条件 所有节点上必须安装repmgr 4.2或更高版本。必须在所有节点上安装相同的主要repmgr版本例如 4.2最好是相同的次要版本。所有节点上的 PostgreSQL 必须可以从执行pause/unpause操作的节点访问 使用conninfo所示的字符串repmgr cluster show。 暂停
repmgr -f /etc/repmgr.conf service pause $repmgr -f /etc/repmgr.conf service pause
NOTICE: node 1 (node1) paused
NOTICE: node 2 (node2) paused# 暂停之后的状态$repmgr node check --repmgrd
WARNING (repmgrd running but paused) 取消暂停 # 取消暂停
$repmgr -f /etc/repmgr.conf service unpause
NOTICE: node 1 (node1) unpaused
NOTICE: node 2 (node2) unpaused 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_historytrue它会不断地将备用节点状态信息写入表中 monitoring_history从而提供集群中所有节点上的复制状态的近乎实时的概述。 该视图replication_status显示每个节点的最新状态例如 select * from repmgr.replication_status; select * from repmgr.replication_status;primary_node_id | standby_node_id | standby_name | node_type | active | last_monitor_time | last_wal_primary_location | last_wal_standby_location | replication_lag | replication_time_lag | apply_lag | communication_time_lag
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------2 | 1 | node1 | standby | t | 2023-11-16 15:53:33.52982708 | 0/15028AF0 | 0/15028AF0 | 0 bytes | 00:00:00 | 0 bytes | 00:00:01.832594
(1 row) 写入监控历史记录的时间间隔由配置参数控制monitor_interval_secs默认值为 2。 因为这样会在repmgr.monitoring_history表中产生大量的监控数据 。建议使用repmgr cluster cleanup 命令定期清除历史数据使用该-k/--keep-history选项指定应保留多少天的数据。 仅监控模式 通过在节点 repmgr.conf文件中进行设置 failovermanual 可以使用repmgrd在某些或所有节点的监视模式下运行没有自动故障转移功能。如果节点的上游发生故障则不会采取故障转移操作并且节点将需要手动干预才能重新连接到复制。如果发生这种情况 将创建 standby_disconnect_manual事件通知。 请注意当备用节点不直接从其上游节点进行流传输时例如从存档中恢复 WALapply_lag将始终显示为 0 bytes。 4 实验验证自动故障切换 停止主库前查看状态 $repmgr -f /etc/repmgr.conf cluster showID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
-----------------------------------------------------------------------------------------------------------------------------------------------1 | node1 | standby | running | node2 | default | 100 | 4 | host10.79.21.30 port5432 userrepmgr dbnamerepmgr connect_timeout22 | node2 | primary | * running | | default | 100 | 4 | host10.79.21.29 port5432 userrepmgr dbnamerepmgr connect_timeout2 停止主库 /usr/local/pgsql/bin/pg_ctl -D /home/storage/pgsql/data -l /home/storage/pgsql/data/server.log stop 查看日志 主节点 [2023-11-16 15:57:41] [DETAIL] attempted to connect using:userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr options-csearch_path
[2023-11-16 15:57:41] [WARNING] reconnection to node node2 (ID: 2) failed
[2023-11-16 15:57:41] [WARNING] unable to connect to local node
[2023-11-16 15:57:41] [INFO] checking state of node 2, 1 of 6 attempts
[2023-11-16 15:57:41] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:57:41] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:57:41] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-11-16 15:57:51] [INFO] checking state of node 2, 2 of 6 attempts
[2023-11-16 15:57:51] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:57:51] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:57:51] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-11-16 15:58:01] [INFO] checking state of node 2, 3 of 6 attempts
[2023-11-16 15:58:01] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:01] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:01] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-11-16 15:58:11] [INFO] checking state of node 2, 4 of 6 attempts
[2023-11-16 15:58:11] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:11] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:11] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-11-16 15:58:21] [INFO] checking state of node 2, 5 of 6 attempts
[2023-11-16 15:58:21] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:21] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:21] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-11-16 15:58:31] [INFO] checking state of node 2, 6 of 6 attempts
[2023-11-16 15:58:31] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:31] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:31] [WARNING] unable to reconnect to node 2 after 6 attempts
[2023-11-16 15:58:31] [NOTICE] unable to connect to local node, falling back to degraded monitoring
[2023-11-16 15:58:31] [WARNING] unable to ping host10.79.21.29 port5432 userrepmgr dbnamerepmgr connect_timeout2
[2023-11-16 15:58:31] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:31] [ERROR] unable to determine if server is in recovery
[2023-11-16 15:58:31] [DETAIL] query text is:
SELECT pg_catalog.pg_is_in_recovery()
[2023-11-16 15:58:31] [WARNING] unable to determine node recovery status
[2023-11-16 15:58:33] [WARNING] unable to ping host10.79.21.29 port5432 userrepmgr dbnamerepmgr connect_timeout2
[2023-11-16 15:58:33] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:33] [WARNING] connection to node node2 (ID: 2) lost
[2023-11-16 15:58:33] [DETAIL]
connection pointer is NULL 从节点 [2023-11-16 15:57:40] [WARNING] unable to ping host10.79.21.29 port5432 userrepmgr dbnamerepmgr connect_timeout2
[2023-11-16 15:57:40] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:57:40] [WARNING] unable to connect to upstream node node2 (ID: 2)
[2023-11-16 15:57:40] [INFO] checking state of node node2 (ID: 2), 1 of 6 attempts
[2023-11-16 15:57:40] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:57:40] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:57:40] [INFO] sleeping up to 10 seconds until next reconnection attempt
[2023-11-16 15:57:50] [INFO] checking state of node node2 (ID: 2), 2 of 6 attempts
[2023-11-16 15:57:50] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:57:50] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:57:50] [INFO] sleeping up to 10 seconds until next reconnection attempt
[2023-11-16 15:58:00] [INFO] checking state of node node2 (ID: 2), 3 of 6 attempts
[2023-11-16 15:58:00] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:00] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:00] [INFO] sleeping up to 10 seconds until next reconnection attempt
[2023-11-16 15:58:10] [INFO] checking state of node node2 (ID: 2), 4 of 6 attempts
[2023-11-16 15:58:10] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:10] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:10] [INFO] sleeping up to 10 seconds until next reconnection attempt
[2023-11-16 15:58:20] [INFO] checking state of node node2 (ID: 2), 5 of 6 attempts
[2023-11-16 15:58:20] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:20] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:20] [INFO] sleeping up to 10 seconds until next reconnection attempt
[2023-11-16 15:58:30] [INFO] checking state of node node2 (ID: 2), 6 of 6 attempts
[2023-11-16 15:58:30] [WARNING] unable to ping userrepmgr connect_timeout2 dbnamerepmgr host10.79.21.29 port5432 fallback_application_namerepmgr
[2023-11-16 15:58:30] [DETAIL] PQping() returned PQPING_NO_RESPONSE
[2023-11-16 15:58:30] [WARNING] unable to reconnect to node node2 (ID: 2) after 6 attempts
[2023-11-16 15:58:30] [INFO] 0 active sibling nodes registered
[2023-11-16 15:58:30] [INFO] 2 total nodes registered
[2023-11-16 15:58:30] [INFO] primary node node2 (ID: 2) and this node have the same location (default)
[2023-11-16 15:58:30] [INFO] no other sibling nodes - we win by default
[2023-11-16 15:58:30] [NOTICE] this node is the only available candidate and will now promote itself
[2023-11-16 15:58:30] [INFO] promote_command is:/usr/local/pgsql/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file
[2023-11-16 15:58:30] [NOTICE] redirecting logging output to /home/storage/repmgr/repmgr.log[2023-11-16 15:58:30] [NOTICE] promoting standby to primary
[2023-11-16 15:58:30] [DETAIL] promoting server node1 (ID: 1) using pg_promote()
[2023-11-16 15:58:30] [NOTICE] waiting up to 60 seconds (parameter promote_check_timeout) for promotion to complete
[2023-11-16 15:58:31] [NOTICE] STANDBY PROMOTE successful
[2023-11-16 15:58:31] [DETAIL] server node1 (ID: 1) was successfully promoted to primary
[2023-11-16 15:58:31] [INFO] checking state of node 1, 1 of 6 attempts
[2023-11-16 15:58:31] [NOTICE] node 1 has recovered, reconnecting
[2023-11-16 15:58:31] [INFO] connection to node 1 succeeded
[2023-11-16 15:58:31] [INFO] original connection is still available
[2023-11-16 15:58:31] [INFO] 0 followers to notify
[2023-11-16 15:58:31] [INFO] switching to primary monitoring mode
[2023-11-16 15:58:31] [NOTICE] monitoring cluster primary node1 (ID: 1) 查看状态 $repmgr -f /etc/repmgr.conf cluster showID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
-----------------------------------------------------------------------------------------------------------------------------------------------1 | node1 | primary | * running | | default | 100 | 5 | host10.79.21.30 port5432 userrepmgr dbnamerepmgr connect_timeout22 | node2 | primary | - failed | ? | default | 100 | | host10.79.21.29 port5432 userrepmgr dbnamerepmgr connect_timeout2WARNING: following issues were detected- unable to connect to node node2 (ID: 2) TODO 配合VIP或者自定义脚本的切换
