谁说 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 今天就到这里，下期的写写一些命令，和自动切换的方法