扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章将为大家详细讲解有关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实现高可用”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流