189 8069 5689
这篇文章将为大家详细讲解有关PostgreSQL如何使用repmgr实现高可用，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
创新互联主营绥芬河网站建设的网络公司,主营网站建设方案,成都app软件开发公司,绥芬河h5小程序制作搭建,绥芬河网站营销推广欢迎绥芬河等地区企业咨询
1 大厂支持
2 配置简单靠谱，没有众多依赖包安装后，还出问题让你有想自杀的意愿，或者是相关的技术文字少，解决问题困难的尿点。
这个高可用的方案已经在生产上使用了有一段时间，目前没有出过问题，之前写过，但是在这一段时间的使用中也发现了一些问题，所以准备详细的对这个高可用方案来详细的说说，也避免某些挑刺的说 PG 没有靠谱的高可用这样的笑话，继续存在。
这个高可用的方式就是repmgr ，2象限公司的产品。（免费的），以下的文字中的PG的版本是 11.2 ，REPMGR 是 4.4 版本。由于功能比较多，所以一次也写不完，只能分期的写，今天的文字要做到的是 两台 POSTGRESQL ，完成手动切换。
首先你需要安装2台postgresql ，这里假设你已经安装完毕了（安装当然是编译安装，如果不是编译安装则我不保证不会出其他的问题，之前有一篇是关于编译安装的，当然也可以去 “德哥”的github 上去找专业的文字关于POSTGRESQL 的安装，水不浅）
1 安装完毕的POSTGRESQL首先能有进行 replication 的条件
2 两台postgresql 要配置一样，包含配置文件，以及extension等等
这里为了便于下面理解两台机器的
192.168.198.21 主库
192.168.198.22 备库
其实我们配置一台机器就可以了，我们在一台机器（主机）
操作以下的命令
create database repmgr;
create user repmgr with password 'repmgr'; （密码您随意）
alter user repmgr superuser login;
alter database repmgr owner to repmgr;
对 repmgr 解包进行编译
在确认已经编译好repmgr 后，需要对两台机器进行ssh 免密的工作
这里的免密建议是基于你操控postgresql 的账户，而不是root
（注：免密的工作这里如是MySQL的DBA 这将不是很难理解的工作，因为MHA就是这么干的）
另外还需要配置repmgr 高可用使用的通讯账户，也需要进行免密的工作，需要在你操作postgresql的账户中目录位置设置.pgpass ，内容请参见下图
其实如果配置过mha ，对这样的事情也是很容易理解）
另外也需要对 pg_hba.conf 进行配置，配置方法见下图 （可能懂的会在这里有疑问，但这里的确是需要这样设置，官网的文档）
https://repmgr.org/docs/4.4/quickstart-authentication.html
在做完这一切后，我们需要配置 repmgr.conf 文件 （其实这还是和MHA 的配置方式类似，所以如果你是MYSQL DBA 则PG的高可用方式的学习成本会很低）
node_id=1 集群中的标识 注意这个一个集群不能有重复，一般用数字来
node_name='192.168.198.21' 需要给节点一个注册的名字，这里可以使用IP 也可以使用机器名等等
conninfo='host=192.168.198.21 dbname=repmgr user=repmgr connect_timeout=2'
本地连接信息，repmgr 操作本地时的连接信息
data_directory='/pgdata/data' 指定当前主机的数据目录
replication_user='repmgr' 进行复制的操作的账户
replication_type='physical' 复制的方式
repmgr_bindir='/usr/local/postgres/bin' repmgr 的执行文件的目录
pg_bindir='/usr/local/postgres' 配置PG的执行文件
另一台机器，需要在 node_id , node_name , conninfo 等位置做改变，
我们到目前小结一下当前的两台机器的状况
主机，已经注册repmgr ，服务器开启的状态，可以接受repmgr 的远程连接免密的方式，备库关机，备库的数据目录是清空的状态（因为要开始进行主库拉数据的操作）
下面我们就要使用一下的命令来进行 --dry-run (mysql的DBA 是不是很惊喜 和pt 工具一路货)
repmgr -h 192.168.198.21 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --dry-run
可以看到--dry-run 没有问题直接执行命令进行 clone
repmgr -h 192.168.198.21 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
然后在clone 成功后，其实就是pg_basebackup ，在这以后需要修改standby 机器中的postgresql,conf 文件中的 listen 地址改为本机的地址
（这些工作其实也是做 primary standby 的工作，和高可用本身是没有关系的，知识 repmgr 帮助你做了这件事）
启动服务器，正常，并开始复制
如果到这里出了问题，可能的原因
1 pg_hba.conf 设置的有问题
2 postgresql.conf 从库 没有改 postgresql,conf 监听地址
（请补充POSTGRESQL 基础知识）
下一步我们就需要对复制进行一个验证（如果有自信就跳过此步骤）
在从库我们查看目前的复制是否OK ，下图显示OK
然后在从库执行
repmgr -f /etc/repmgr.conf standby register
注册成功后
目前大部分的高可用（手动切换）的工作已经完成了百分之80%
repmgr -f /etc/repmgr.conf cluster show
通过上面的图和命令可以很顺利查看，两台机器的主从状态。
写到下面，可能有人要吐槽我了，人家都自动，你手动，你脑子进水了。
1 POSTGRESQL 的repmgr 主从切换，是可以自动的，但这期写不完
2 如果使用mysql 比较顺溜的，到这里马上就可以反映出一个问题，MHA 我切换我也没有用 MHA 去侦测，我也是通过其他的方式来检测，然后使用 MHA 命令切换方式来进行高可用的切换。
话说到这里已经说的很明了，你要是有MYSQL的高可用MHA的解决方案，到这里你自己已经有主意了，还有必要看下去的原因就是，怎么手动切换。然后你就可以放飞自我了。
想说 POSTGRESQL 没有靠谱高可用方式的，打脸不
下面就开始手动切换
repmgr -f /etc/repmgr.conf standby switchover -U repmgr --verbose
好了在切换命令开始后，主从开始切换，参见下图
切换后，我们在主机上查看状态
主机已经变成从库，从库已经升级为主库
在从库上查看，很清晰的告诉你，主库已经是 22 ，从库变成了21
这也是和MHA 不一样的地方，如果你的失败的主库还有挽救的余地，则还是可以让他变成从库，继续服务的，当然也是有时间限制的，默认一分钟的尝试，否则就放弃了。
关于“PostgreSQL如何使用repmgr实现高可用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。