专栏首页AustinDatabases谁说 PostgreSQL 没有靠谱的高可用(1)

谁说 PostgreSQL 没有靠谱的高可用(1)

最近问postgresql 那个高可用靠谱的人越来越多,其实我也试过几种postgresql 的高可用方案,而最近听到的声音是 PostgreSQL 没有靠谱的高可用方案。所以就有了这篇文字

——————————————————————————————

今天说的是另一种PG的高可用方案,这种方案的好的地方

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 不一样的地方,如果你的失败的主库还有挽救的余地,则还是可以让他变成从库,继续服务的,当然也是有时间限制的,默认一分钟的尝试,否则就放弃了。

OK 今天就到这里,下期的写写一些命令,和自动切换的方法

本文分享自微信公众号 - AustinDatabases(AustinDatabases),作者:carol11

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 谁说postgresql 没有靠谱的高可用(6)

    接上期,(如果看不懂的,请从第一期看,否则可能和看天书没两样),最近在梳理一些问题的时候,发现一个现象,大部分出现问题后,解决就完了,网上很多文字,大多都是这样...

    AustinDatabases
  • PostgreSQL 高可用集群 repmgr 与 头疼的问题

    PostgreSQL 的高可用的方案,基本上不是原生的,大多是依靠第三方的公司来进行开发的,挂名的有那么几种 Patroni, PGPOOL-II, Repmg...

    AustinDatabases
  • PostgreSQL 高可用 Repmgr 命令及配置文件(三)

    应该是第三个关于PostgreSQL 高可用的文字了,Repmgr 在使用中的一些通用的命令和一些配置文件的含义,今天需要明确。

    AustinDatabases
  • 谁说postgresql 没有靠谱的高可用(6)

    接上期,(如果看不懂的,请从第一期看,否则可能和看天书没两样),最近在梳理一些问题的时候,发现一个现象,大部分出现问题后,解决就完了,网上很多文字,大多都是这样...

    AustinDatabases
  • PostgreSQL 高可用集群 repmgr 与 头疼的问题

    PostgreSQL 的高可用的方案,基本上不是原生的,大多是依靠第三方的公司来进行开发的,挂名的有那么几种 Patroni, PGPOOL-II, Repmg...

    AustinDatabases
  • 基于repmgr的postgresql主备高可用方案

    本文比较基础,主要介绍postgresql开源高可用工具repmgr的部署和使用,初学者可以根据本文步骤一步一步做下去,废话不多说,直接进入主题,本文以两台机器...

    数据库架构之美
  • Postgresql Repmgr 级联复制 及 PostgreSQL 故障转移

    PostgreSQL 使用repmgr 进行主从数据的Clone是可以进行级联复制的,使用过MYSQL的同学可能会觉得,没有什么了不起,MYSQL 多少级的级联...

    AustinDatabases
  • Jmeter(五十)_性能测试模拟真实场景下的用户操作

    用户通过客户端向服务端发出请求的时间为: T1 服务端接收到请求,处理该请求的时间为:T2 服务端返回数据给客户端时间为: T3 客户端接收到响应数据,处理数据...

    飞天小子
  • Spring Cloud组件那么多超时设置,如何理解和运用?

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://louluan.blog.c...

    亦山
  • STT-MRAM测试调查:故障机制、故障模型和测试(CS ET)

    自旋转矩随机存取存储器(STT-MRAM)作为一种极具发展前景的新型非易失性存储器(NVM)技术,因其具有密度高、零待机泄漏、几乎无限续存等特点而备受关注。然而...

    非过度曝光

扫码关注云+社区

领取腾讯云代金券