repmgr学习

我就是我 2022-05-22 10:55 263阅读 0赞

[https://repmgr.org/docs/4.0/using-repmgrd.html][https_repmgr.org_docs_4.0_using-repmgrd.html]

repmgrd是在复制群集中的每个节点上运行的管理和监视守护进程。它可以自动执行诸如故障转移和更新备用数据库等操作以跟踪新的主数据库，并提供关于每个备用数据库状态的监视信息。

**一、基本配置**

1、如要使用 repmgrd，必须在 postgresql.conf中 配置关联库（需要重启pg服务方可生效）

shared\_preload\_libraries ='repmgr'

\[postgres@vlnx107001 ~\]$ pg\_ctl -D $PGDATA -l /var/lib/pgsql/9.6/data/pg\_log/logfile0511 restart

2、如果要使用自动故障转移功能，必须在repmgr.conf中配置下列命令：

failover=automatic

promote\_command='/usr/pgsql-9.6/bin/repmgr standby promote -f /etc/repmgr/9.6/repmgr.conf  --log-to-file'

\#提升节点级别为primary； --log-to-file 指定输出的日志记录到 配置文件中 log\_file指定的目录文件中

follow\_command='/usr/pgsql-9.6/bin/repmgr standby follow -f /etc/repmgr/9.6/repmgr.conf --upstream-node-id=%n'

\#让其他从节点 follow新的primary节点

上述follow\_command应提供--upstream节点-ID =％N 选项repmgr standby follow; 的％N将被替换 repmgrd与新的主节点的ID。如果未提供此信息，repmgr 将尝试自行确定新主服务器，但是如果在新主服务器升级后原始主服务器重新联机，则存在repmgr standby follow 将导致节点继续遵循原始主的风险。

3、使用自动故障转移，repmgrd会执行 repmgr standby follow 在从节点上重启postgresql，以便让它们通新的primary上同步数据，故必须配置

service\_start\_command = 'sudo systemctl start postgresql-9.6'

service\_stop\_command = 'sudo systemctl stop postgresql-9.6'

service\_restart\_command = 'sudo systemctl restart postgresql-9.6'

service\_reload\_command = 'sudo systemctl reload postgresql-9.6'

如果不这样配置，repmgrd将默认使用 pg\_ctl，这样操作可能导致意外问题的发生，特别是在基于 systemd的系统上，故强烈建议配置以上四项。

**二、监控配置**

1、如果要启用 repmgrd 守护进程和监控，需在 repmgr.conf中启用 moitoring\_history=yes

monitoring\_history=yes

默认监控时间间隔为2秒

monitor\_interval\_secs=2

2、启动 repmgrd命令

repmgrd -f /etc/repmgr/9.6/repmgr.conf --pid-file /tmp/repmgrd.pid --daemonize

查看 集群中记录的repmgrd进程启动信息

repmgr -f /etc/repmgr/9.6/repmgr.conf  cluster event --event=repmgrd\_start

3、停止repmgrd

kill 'cat /tmp/repmgrd.pid'   \#可以根据具体的路径进行调整即可

**三、模拟切换主从**

默认会 每隔10秒重试连接一次，连续6次，然后选举出新的primary节点（这些由/repmgr.conf配置文件中的 reconnect\_attempts=6  reconnect\_interval=10  参数决定 ）

\[postgres@vlnx107001 ~\]$ pg\_ctl -D  $PGDATA -m fast stop

![70][]

\[root@vlnx107001 ~\]\# tailf /var/log/repmgr/repmgr.log

![70 1][]

\[postgres@vlnx107002 tmp\]$  repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show

![70 2][]

\[root@vlnx107002 ~\]\# tailf /var/log/repmgr/repmgr.log

![70 3][]

\[postgres@vlnx107002 tmp\]$  repmgr -f /etc/repmgr/9.6/repmgr.conf cluster event

![70 4][]  
\[postgres@vlnx107003 data\]$  repmgr -f /etc/repmgr/9.6/repmgr.conf cluster show  
![70 5][]

\[root@vlnx107003 ~\]\# tailf /var/log/repmgr/repmgr.log  
![70 6][]

发现主从切换成功，并且从节点同步数据源也指向了新的primary节点

**成功切换的前提：**

postgresql.conf

![70 7][]  
repmgr.conf  
![70 8][]

**将出故障的 原Primary节点重新加入到集群中使其成为 standby节点**

总的思路：

这是一个两阶段的过程。首先，失败的主数据目录必须与当前的主数据库重新同步; 其次，失败的主要需要重新注册为备用。

pg9.5以后提供了 pg\_rewind应用程序，让我们更快更方便的实现。

\[postgres@vlnx107001 data\]$ repmgr -f /etc/repmgr/9.6/repmgr.conf node rejoin -d 'host=172.31.107.2 dbname=repmgr user=repmgr' --force-rewind --config-files=postgresql.conf,postgresql.auto.conf --verbose --dry-run

![70 9][]

**注意：**如果不执行本脚本，而是直接使用 pg\_ctl -D $PGDAT start         启动，则会导致 变相的 “脑裂”，即 vlnx107001 和 vlnx107002 都显示 primary

![70 10][]

这时候需要做的是，将 recovery.conf 重命名或删除，然后停止 postgresql服务；最后再执行：

repmgr -f /etc/repmgr/9.6/repmgr.conf node rejoin -d 'host=172.31.107.2 dbname=repmgr user=repmgr' --force-rewind --config-files=postgresql.conf,postgresql.auto.conf --verbose --dry-run

验证是否 可以重新加入，如果提示重新加入的先决条件得到满足，则就可以执行 remgr rejoin 命令了

![70 11][]

**四、使用repmgrd 处理网络问题**

复制群集设置的常见模式是将服务器分布到多个数据中心。这可以提供诸如地理分布的只读副本和DR（灾难恢复能力）等好处。但这也意味着数据中心位置之间的网络层面存在断开连接的风险，如果次要数据中心中的服务器不再能够看到主数据中心的主服务器并提升备用服务器，则会导致裂脑情形在他们中间。

repmgr允许提供"见证服务器"，以人为地在特定位置创建法定服务器数量，确保在其他位置的节点如果无法查看大多数节点，则不会选择新的主服务器。但是，这种方法并不能很好地扩展，特别是对于更复杂的复制设置，例如大多数节点位于主数据中心之外。这也意味着见证节点需要作为主复制集群外的额外PostgreSQL实例进行管理，这增加了管理和编程的复杂性。

repmgr4引入了位置的概念：每个节点都与一个任意的位置字符串相关联（默认为 default）; 这在repmgr.conf中设置：

location='DC001'

在故障切换情况下，repmgrd将检查与当前主节点位于同一位置的任何服务器是否可见。否则，repmgrd 将假定网络中断，并且不会在任何其他位置提升任何节点（但是会进入 “降级监视”模式 [https://repmgr.org/docs/4.0/repmgrd-degraded-monitoring.html][https_repmgr.org_docs_4.0_repmgrd-degraded-monitoring.html]，直到primary节点可见）

**五、见证服务器的作用**

在由于两个数据中心之间的网络中断等原因导致的情况下，避免出现“裂脑”情况非常重要，因为网络双方都假设它们是活动网段，而没有活动网点的一方单方面推荐其一个备用网址。

为了防止这种情况发生，确保一个网段具有“投票多数”是非常重要的，所以其他部门将知道他们是少数派，而不是试图推销新的主要部门。在存在奇数个服务器的情况下，这不是问题。但是，如果每个网络具有偶数个节点，则有必要提供一些确保多数的方式，这是证人服务器变得有用的地方。

这不是一个完全成熟的备用节点，并未集成到复制中，但它在确定哪个网段占多数时有效地代表了“投票”。见证服务器可以使用repmgr见证注册表进行设置。请注意，只有在运行repmgrd的情况下创建见证服务器才有意义 ; 见证服务器将需要它自己的 repmgrd实例。

**六、降级监视模式**

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

发生这种情况的情况是：

出现故障切换情况时，主节点位置中的任何节点都不可见

发生了故障转移情况，但没有提供晋升候选人

发生了故障转移情况，但晋升候选人无法晋升

发生了故障转移情况，但节点无法关注新的主节点

发生了故障转移情况，但没有可用的主服务器

发生了故障转移情况，但节点未启用自动故障转移

repmgrd正在监视主节点，但它不可用（并且没有其他节点已被提升为主节点）

默认情况下，repmgrd将无限期地继续处于降级监视模式。但是，可以使用degraded\_monitoring\_timeout设置超时（以秒为单位），之后repmgrd将终止。

**七、repmgrd进行监视**

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

视图replication\_status显示每个节点的最新状态;

监视历史写入的时间间隔由配置参数monitor\_interval\_secs控制 ; 默认值是2。

因为这会在表repmgr.monitoring\_history中生成大量的监控数据 。建议使用repmgr集群清理 命令定期清除历史数据; 使用-k / - keep-history选项来指定应该保留多少天的数据。

通过在节点的repmgr.conf文件中设置failover = manual， 可以将repmgrd仅以监控模式运行（无自动故障转移功能）。如果节点上游发生故障，则不会执行故障切换操作，并且节点需要手动干预才能重新连接到复制。如果发生这种情况，将创建一个 事件通知standby\_disconnect\_manual。

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

提示： 如果启用了监视历史记录，repmgr.monitoring\_history 表的内容将被复制到附加的备用数据库中。这意味着将会有一小部分但持续不断的复制活动流，这可能并不理想。为防止出现这种情况，请将表格转换为UNLOGGED表格，其中包含：

ALTER TABLE repmgr.monitoring\_history SET UNLOGGED;

但是，这意味着监视历史记录在故障转移后将不会在另一个节点上可用，并且repmgr.replication\_status视图 在standbys上不起作用。

**八、BDR(Bi-Directional Replication 双向复制)**

[https://repmgr.org/docs/4.0/repmgrd-bdr.html][https_repmgr.org_docs_4.0_repmgrd-bdr.html]

[https_repmgr.org_docs_4.0_using-repmgrd.html]: https://repmgr.org/docs/4.0/using-repmgrd.html
[70]: /images/20220522/762ac6752fec49509b31ee7ad1e5073a.png
[70 1]: /images/20220522/6a1693117cb04b22a5f6b730519aa87d.png
[70 2]: /images/20220522/c138b534f2c84de5ae2da569fb17842c.png
[70 3]: /images/20220522/4b4d6eae02fb4619800e1b250e2a64b3.png
[70 4]: /images/20220522/564d1fbb92bb4caca57f6498966778de.png
[70 5]: /images/20220522/7c1c16321cb249b6931cddc0bee291c4.png
[70 6]: /images/20220522/b315849ff019405b9952d05a0ed7585e.png
[70 7]: /images/20220522/75efc4315a1648a7beaeb50c0a89e52c.png
[70 8]: /images/20220522/862cfb2d16174c01bd2ceab01e79bcd5.png
[70 9]: /images/20220522/f13807c5c8634b2082fbd6393fab7e2b.png
[70 10]: /images/20220522/23370361e7f440af956701cdd7f145ef.png
[70 11]: /images/20220522/c9e0d7a456cf48b9ad1057c408b49312.png
[https_repmgr.org_docs_4.0_repmgrd-degraded-monitoring.html]: https://repmgr.org/docs/4.0/repmgrd-degraded-monitoring.html
[https_repmgr.org_docs_4.0_repmgrd-bdr.html]: https://repmgr.org/docs/4.0/repmgrd-bdr.html