Postgresql Repmgr级联复制及PostgreSQL 故障转移是怎样的

Postgresql Repmgr级联复制及PostgreSQL 故障转移是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

首先我们已经有两台机器，在repmgr 的管理中，从图中可以看到 110 ，111 两台机器已经在 repmgr 的管理中

我们安装另外一台 postgresql 的机器 112 并且安装 repmgr 软件。

注意不要进行数据的初始化，repmgr 的机器需要复制的机器的指定的数据目录必须为空。

repmgr -h 192.168.198.111 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --upstream-node-id=2 --verbose

192.168.198.111 是从库，而复制直接是从从库进行复制，而不是主库。

开始将机器的信息加入到集群中这里首先需要的就是编辑好 repmgr.conf

具体如何编译，请参见前几天的 repmgr 的安装的文字内容。这里就不重复了

repmgr -f /etc/repmgr.conf standby register --upstream-node-id=2 

命令里面的 --upstream-node-id =2  指的是数据的初始复制是来自于 从节点而从节点的 node_id  是 2 ，之后的数据复制还是来自于从库而不是主库

命令执行完毕后，可以在主机中找到新加入的节点信息。

我们下边可以来验证

select * from pg_stat_replication

通过执行语句在 110 ，111 上

在 110

在 111

相关的级联复制就OK 了。

而一个数据库系统的failover 其实是评判一个数据库是否靠谱的一个重要的指标。

PostgreSQL  数据库本身是可以进行 failover 切换的。在repmgr中我们可以通过见证服务器来做这件事。

1 首先将刚才的112 节点 脱离目前的集群

直接在 112 上执行命令

 repmgr standby unregister -f /etc/repmgr.conf 

节点会直接在 110 111上的注册信息进行清除，但清除注册信息，不会将复制进行清除，如有必要还需要断掉 111 到 112 之间的复制连接。（如何停止复制，请百度或翻一下之前写过的关于复制的文字）

112 上停止复制后，停机，将原来的 /pgdata/data 下的数据清空

 重新初始化数据库

initdb -D /pgdata/data

启动数据库

pg_ctl -D /pgdata/data start

然后需要做以下工作，确认112 与其他111 110 两台服务器 SSH 免密登录 账号以启动 pg数据库的账号为免密对象

配置好 repmgr.conf 文件，并且对pg_hba.conf 文件进行修改，保证见证服务器上的repmgr 账号登录主机和从库都是OK 的

 repmgr -f /etc/repmgr.conf witness register -h 192.168.198.110  -d repmgr -U repmgr

执行上面的命令对112 注册witness 见证服务器

然后在112上查看相关的信息是否正确

可以从图中看到 112已经被注册为见证服务器

基本上我们的环境就搭建完毕了，下面需要实现的当主机DOWN 掉后，从库自动升级为主库的功能。

需要repmgr 的两点功能

1  监控功能，postgresql 服务状态

2  通过监控状态，触发脚本，进行从库转为主库的工作

这里我们要借助repmgr 中的监控程序 repmgrd 守护程序来对整体的集群进行一个监控。首先repmgrd守护程序需要对 /etc/repmgr.conf 中关于repmgrd 的设置进行相关配置。

下图是配置的选择项和相关的配置值

failover=automatic            

priority=100                          

connection_check_type=ping          

#reconnect_attempts=6                   

#reconnect_interval=10                 

promote_command=repmgr standby promote -f /etc/repmgr.conf

follow_command=repmgr standby follow -f /etc/repmgr.conf -W --upstream-node-id=%n

在配置完毕后，就可以在 111 节点运行

repmgrd -f /etc/repmgr.conf --verbose --monitoring-history

在 111 节点运行 监控后，我们关掉 110 节点的 PG 服务，监控马上就开始反应，在尝试6次重新连接到 主节点失败后，开始进行从库 升级的操作

我们在从库和见证服务器可以运行相关查看集群状态的命令，可以看到111已经变为了主库。

repmgr 作为FAILOVER 以及 switch over  standby to primary 的软件，其功能是强大的，完全满足企业或互联网企业在高可用中使用，辅助以一些脚本，就可以做到 MHA 一样的效果，或更好。

PG 有了repmgr 第三方软件的支持，如虎添翼。

看完上述内容，你们掌握Postgresql Repmgr级联复制及PostgreSQL 故障转移是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！