金仓数据库KingbaseES V8R6 命令行部署repmgr管理集群+switchover测试（一）环境准备

最新推荐文章于 2023-09-13 11:39:47 发布

沉舟侧畔千帆过_

最新推荐文章于 2023-09-13 11:39:47 发布

阅读量2.6k

点赞数

文章标签：金仓数据库 kingbase 数据库人大金仓 DBA

本文链接：https://blog.csdn.net/arthemis_14/article/details/130806649

版权

本次部署未使用securecmd/kbha工具，无需普通用户到root用户的互信。

一、环境准备

1、创建OS用户

建立系统数据库安装用户组及用户，在所有的节点执行。
root用户登陆服务器，创建用户组及用户并且设置密码

[root@ora19c ~]# groupadd -g 6000 kes86
[root@ora19c ~]# useradd -G kes86 -g 6000 -u 6000 kes86 -m
[root@ora19c ~]# passwd kes86
Changing password for user kes86.
New password: 
BAD PASSWORD: The password is shorter than 8 characters
Retype new password: 
passwd: all authentication tokens updated successfully.
[root@ora19c ~]# 

[root@postgres ~]# groupadd -g 6000 kes86
[root@postgres ~]# useradd -G kes86 -g 6000 -u 6000 kes86 -m
[root@postgres ~]# passwd kes86
Changing password for user kes86.
New password: 
BAD PASSWORD: The password is shorter than 7 characters
Retype new password: 
passwd: all authentication tokens updated successfully.
[root@postgres ~]#

备注：用户组及用户名称可以自定义，这里以kes86用户为例

2、配置互信

配置/etc/hosts文件

vim /etc/hosts
192.168.57.30  node1      node1      #主库
192.168.57.10  node2      node2      #备库

备注：/etc/hosts配置属于可选项目，这里配置主要是区分后续的复制槽，在一主多备的场景方便区分复制槽对应的主机

配置数据库系统用户ssh互信
最好把root/系统数据库都配置(如果只访问数据库data目录文件，无需配置root用户互信，只配置数据库用户就可以)

--切换到kes86用户
[root@ora19c ~]# su - kes86 
--执行 ssh-keygen -t rsa
[kes86@ora19c ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kes86/.ssh/id_rsa): 
Created directory '/home/kes86/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/kes86/.ssh/id_rsa.
Your public key has been saved in /home/kes86/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:c6CPByaWLrQebsIbKBYBmyr+CjEzUmZoAas0M9gSBRg kes86@ora19c
The key's randomart image is:
+---[RSA 3072]----+
|E=.              |
|+B.              |
|BB=     .        |
|===  . . .       |
|X.. + + S .      |
|=*.+ o + o       |
|=++ . . o        |
|=++o   .         |
| ==.             |
+----[SHA256]-----+
ssh-copy-id kes86@192.168.57.30

[kes86@ora19c ~]$ ssh-copy-id kes86@192.168.57.30
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kes86/.ssh/id_rsa.pub"
The authenticity of host '192.168.57.30 (192.168.57.30)' can't be established.
ECDSA key fingerprint is SHA256:P2+7+Mqp10TIbLRkwBQT6lTVBxbLtWrz+zEMRNwYA2Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
kes86@192.168.57.30's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'kes86@192.168.57.30'"
and check to make sure that only the key(s) you wanted were added.

ssh-copy-id kes86@192.168.57.10

[kes86@ora19c ~]$ ssh-copy-id kes86@192.168.57.10
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kes86/.ssh/id_rsa.pub"
The authenticity of host '192.168.57.10 (192.168.57.10)' can't be established.
ECDSA key fingerprint is SHA256:jbiSTLyWOSvk9P6Rrum0V/H5PE52Fz48bO69ttVGvjU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
kes86@192.168.57.10's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'kes86@192.168.57.10'"
and check to make sure that only the key(s) you wanted were added.

ssh-copy-id kes86@node1

[kes86@ora19c ~]$ ssh-copy-id kes86@node1
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kes86/.ssh/id_rsa.pub"
The authenticity of host 'node1 (192.168.57.30)' can't be established.
ECDSA key fingerprint is SHA256:P2+7+Mqp10TIbLRkwBQT6lTVBxbLtWrz+zEMRNwYA2Y.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
        (if you think this is a mistake, you may want to use -f option)

ssh-copy-id kes86@node2

[kes86@ora19c ~]$ ssh-copy-id kes86@node2
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/kes86/.ssh/id_rsa.pub"
The authenticity of host 'node2 (192.168.57.10)' can't be established.
ECDSA key fingerprint is SHA256:jbiSTLyWOSvk9P6Rrum0V/H5PE52Fz48bO69ttVGvjU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
        (if you think this is a mistake, you may want to use -f option)

--scp .ssh目录到node2节点

[kes86@ora19c ~]$ scp -r .ssh/ kes86@192.168.57.10:~
id_rsa                                                                                    100% 2602     1.1MB/s   00:00    
id_rsa.pub                                                                                100%  566     5.9KB/s   00:00    
known_hosts                                                                               100%  684   182.8KB/s   00:00    
authorized_keys                                                                           100%  566   255.8KB/s   00:00    
[kes86@ora19c ~]$ 

--免密测试
--主节点执行

[kes86@ora19c ~]$ ssh kes86@node1 date
Tue Dec  6 09:29:02 CST 2022
[kes86@ora19c ~]$ ssh kes86@node2 date
Fri Dec 16 16:10:06 CST 2022

--备节点执行

[kes86@postgres ~]$ ssh kes86@node1 date
Tue Dec  6 09:29:51 CST 2022
[kes86@postgres ~]$ ssh kes86@node2 date
Fri Dec 16 16:10:52 CST 2022

测试通过

3、操作系统参数设置

系统参数配置：所有节点都必须配置
系统内核参数/etc/sysctl.conf,详细配置请参考系统手册

示例 vim /etc/sysctl.conf
fs.aio-max-nr= 1048576
fs.file-max= 6815744
kernel.shmall= 2097152
kernel.shmmax= 2174483648
kernel.shmmni= 4096
kernel.sem= 5010 641280 5010 256
net.ipv4.ip_local_port_range= 9000 65500
net.core.rmem_default= 262144
net.core.rmem_max= 4194304
net.core.wmem_default= 262144
net.core.wmem_max= 1048576

fs.aio-max-nr参数决定了系统中所允许的文件句柄最大数目，文件句柄设置代表linux系统中可以打开的文件的数量
fs.file-max参数表示进程(比如一个worker进程)可以同时打开的最大句柄数，这个参数限制最大并发连接数。
kernel.shmall参数表示系统一次可以使用的共享内存总量(以页为单位)缺省值就是2097152，通常不需要修改
kernel.sshmmax参数定义了共享内存段的最大尺寸(以字节为单位)
kernel.shmmni参数用于设置系统范围内共享内存段的最大数量。该参数的默认值是 4096
kernel.sem参数表示设置的信号量
# 5010是参数semmsl的值，表示一个信号量集合中能够包含的信号量最大数目。
# 641280是参数semmns的值，表示系统内可允许的信号量最大数目。
# 5010是参数semopm的值，表示单个semopm()调用在一个信号量集合上可以执行的操作数量。
# 256是参数semmni的值，表示系统信号量集合总数
net.ipv4.ip_local_port_range参数表示应用程序可使用的IPv4端口范围
net.core.rmem_default参数表示套接字接收缓冲区大小的缺省值
net.core.rmem_max参数表示套接字接收缓冲区大小的最大值
net.core.wmem_default参数表示套接字发送缓冲区大小的缺省值
net.core.wmem_max=参数表示套接字发送缓冲区大小的最大值

NUMA设置

大多数情况，可以在BIOS层面关闭NUMA支持，并且在OS启动参数中设置numa off参数，那么我们再OS上就可以不用关注NUMA问题了。如果在OS上没有关闭NUMA，也可以通过下面的手段让数据库在分配内存的时候不理会NUMA的远程内存。

vm.zone_reclaim_mode=0
vm.numa_balancing=0
numactl-interleave=all

避免OOM发生

vm.swappiness = 0           # 建议设置为0(
vm.overcommit_memory = 2   # 允许一定程度的Overcommit
vm.overcommit_ratio = 50   # 允许的Overcommit:$((($mem - $swap) * 100 / $mem))

文件缓存脏块回写策略

vm.dirty_background_ratio = 5(10–>5)
vm.dirty_ratio = 10~15
vm.dirty_background_bytes=25

当pagecache变脏了，需要将脏页刷出内存。linux中通过一些参数来控制何时进行内存回写。

vm.dirty_background_ratio/vm.dirty_background_bytes

内存中允许存在的脏页比率或者具体值。达到该值，后台刷盘。取决于外存读写速度的不同，通常将vm.dirty_background_ratio设置为5，而

vm.dirty_background_bytes设置为读写速度的25%。
vm.dirty_ratio/vm.dirty_bytes

前台刷盘会阻塞读写，一般vm.dirty_ratio设置的比vm.dirty_background_ratio大，设置该值确保系统不会再内存中保留过多数据，避免丢失。

vm.dirty_expire_centisecs

脏页在内存中保留的最大时间。

vm.dirty_writeback_centisecs

刷盘进程(pdflush/flush/kdmflush)周期性启动的时间

预留足够的物理内存，用于文件的读写CACHE
根据业务系统的特点与硬件的IO能力调整脏块刷新频率
如果物理IO性能很强，则降低刷新频率，减少脏块比例，如果物理IO性能较弱，则往反方向调整。

设置完成后使用root用户执行 sysctl -p 是参数生效

4、修改系统资源限制

系统资源限制，查看/etc/security/limits.conf /etc/security/limits.d/20-nproc.conf
如果系统只有/etc/security/limits.conf文件，没有/etc/security/limits.d/20-nproc.conf文件，只需修改/etc/security/limits.conf文件。如果全部都有，那么2个文件都要修改。

vim /etc/security/limits.conf
kingbase  soft nofile 65536
kingbase  hard nofile 65535
kingbase  soft nproc 65536
kingbase  hard nproc 65535
kingbase  soft core unlimited
kingbase  hard core unlimited

设置完成后,切换到kingbase用户使用ulimit -a进行查看

# 使用unlimited ，是最大数量则表示无限制
# * 表示所有用户，这里也可只设置root 和要安装的kingbase 用户设置其值
# nofile 是打开文件最大数目，nproc 为进程最大数目，core 为生成内核文件大小的上限
# soft 代表一个警告值，hard 为真正的阈值，超过就会报错，可以适当继续往高调
# PAM 的调整针对单个会话生效，调整后需重新登录root 和kingbase，用ulimit -n 查看生效情况
# 注意：设置nofile 的hard limit 不能大于/proc/sys/fs/nr_open，否则注销后将无法正常登陆

5、修改磁盘调度策略

查看磁盘IO调度
查看当前I/O 调度策略

cat /sys/block/{DEVICE-NAME}/queue/scheduler

• 修改I/O 调度策略为deadline(最后期限算法，根据算法保证请求不饿死)
• {DEVICE-NAME} = 硬盘名称
机械硬盘，推荐deadline 调度算法，较为适合业务单一并且IO 比较重的业务，比如数据库。
固态硬盘，推荐noop 调度算法。
查看系统支持IO 调度算法：

dmesg | grep -i scheduler
[ 1.203287] io scheduler noop registered
[ 1.203289] io scheduler deadline registered (default) [ 1.203311]
io scheduler cfq registered
[ 1.203314] io scheduler mq-deadline registered [ 1.203316] io
scheduler kyber registered

查看某块盘的IO 调度算法

cat /sys/block/{DEVICE-NAME}/queue/scheduler

如果是普通的机械硬盘建议修改磁盘IO调度策略为：deadline (最后期限算法，根据算法保证请求不饿死)

修改IO磁盘调度策略为deadline，示例如下：

linux6版本：

echo deadline > /sys/block/sda/queue/scheduler

也可以写在grub中：

kernel /vmlinuz-2.6.18-274.3.1.el5 ro root=LABEL=/
    elevator=deadline crashkernel=128M@16M  quiet console=tty1
    console=ttyS1,115200 panic=30 transparent_hugepage=never 
    initrd /initrd-2.6.18-274.3.1.el5.img

linux7版本

grubby --update-kernel=ALL --args="elevator=deadline"

暂时不建议使用透明大页，并且在一些高负载的大型数据库系统中建议关闭操作系统的透明大页功能

grubby --update-kernel=ALL --args="transparent_hugepage=never"

磁盘阵列一般都用write-back cache，因为他配置了电池，一般称为battery-backed write cache(BBC or BBWC)

6、kingbase.conf常用参数说明

wal_log_hints=on                                   # 参数必须开启，在流复制主备需要进行切换时，主备时间线出现分歧，方便使用sys_rewind进行时间同步 
full_page_writes=on                                # 参数必须开启，在流复制主备需要进行切换时，主备时间线出现分歧，方便使用sys_rewind进行时间同步
archive_mode=on                                    # 开启归档模式。启用archive_mode时，通过设置archive_command将已完成的WAL段发送到归档存储。
                                                   # 除了off，disable，还有两种模式：on,always
                                                   # 在正常操作期间，两种模式之间没有区别，但是当设置为always的情况下,WAL archiver在存档恢复或待                                                                                                                   # 机模式下也被启用。
                                                   # 在always模式下，从归档还原或流式复制流的所有文件都将被再次归档
                                                   # archive_mode和archive_command是单独的变量，因此可以在不更改存档模式的情况下更改archive_command
                                                   # 此参数只能在服务器启动时设置。当wal_level设置为minimal时，无法启用archive_mode
wal_level=replica                                  # minimal 记录基本的数据操作，保证数据库的ACID
                                                   # replica 在minmal的基础上，记录额外的事务类型操作和数据，保证主备同步一致
                                                   # logical 在replica的基础上，记录完整的数据(主要是更新操作中的旧数据，低于此级别只记录旧数据的                                                                                                        # 某个标记
                                                   # 保证逻辑解码功能逻辑解码是为逻辑同步服务的，两个独立主库通过逻辑同步的方式同步表数据.
archive_command='test ! -f /home/kingbase/data/sys_wal/archive_status/%f && cp %p /home/kingbase/archive/%f' # 定义对wal进行归档的命令。
                                                                                                             # 当archive_mode配置参数启用并且archive_command配置参数是空字符串时，

                                                                                                             # wal archiving暂时被禁用，但是数据库会继续积累wal segment文件。
                                                                                                             # archive_command参数值设置为/bin/true会禁用归档
                                                                                                             # 但这样会导致wal文件归档中断，归档中断是无法进行归档恢复的，请注意这一点。
                                                                                                             # archive_command = 'test ! -f /mnt/archivedir/%f && cp %p /mnt/archivedir/%f'
                                                                                                             # archive_command = 'gzip < %p > /mnt/archivedir/%f'
archive_timeout=0                                  # archive_command执行本地shell命令来归档已完成的WAL文件段。仅对已完成的WAL段进行调用。
                                                   # 因此，如果你的服务器产生很少的WAL(或者在这种情况下有很长的时间)，在事务完成和归档存储器中的安                                                                                                     # 全记录之间可能会有很长的延迟。
                                                   # 为了限制未归档的数据的可能性，可以设置archive_timeout来强制服务器定期切换到新的WAL段文件。
                                                   # 当此参数大于零时只要从最后一个段文件切换开始经过了许多秒，服务器就会切换到一个新的段文件，
                                                   # 并且存在任何数据库活动，包括一个检查点(如果没有检查点，则跳过检查点数据库活动)。
                                                   # 请注意，由于强制切换而提前关闭的归档文件的长度与完整文件的长度相同。 因此，使用一个非常短的                                                                                                             # archive_timeout是不明智的
                                                   # 这会使您的存档存储空间膨胀。一分钟左右的archive_timeout设置通常是合理的。
synchronous_commit=on                              # on off local remote_write remote_apply
                                                   # 在流复制的环境下对性能的影响由小到大分别是：
                                                   # off (async) > on (async) > remote_write (sync)  > on|local (sync)  > remote_apply (sync)
                                                   # remote_apply 应用发起提交后，等到在备库上应用WAL(更新数据)后，它将返回COMMIT响应，并且可                                                                                                         # 以在备库上进行引用。
                                                   # 由于完全保证了数据同步，因此它适合需要备库始终保持最新数据的负载分配场景。
                                                   # on 应用发起提交后，在备库上写入WAL之后，返回COMMIT响应。该选项是性能和可靠性之间的最佳平衡。
                                                   # remote_write 应用发起提交后，等到WAL已传输到备库后，返回COMMIT响应。
                                                   # local 应用发起提交后，写入主库WAL之后，返回COMMIT响应。
                                                   # off 应用发起提交后，直接返回COMMIT响应，而无需等待主库WAL完成写入。
synchronous_standby_names='node2'                  # 如果不配置此参数，默认为async同步方式。kingbaseES生成规则为''kingbase_*&+_++'',主库                                                                                                             # synchronous_standby_names参数为备机名称。
                                                   # 当自身是备库的时候synchronous_standby_names参数为自己
                                                   # 主库配置为备库节点名称。当自身为备库时，配置为备库节点名称。
max_wal_size=1GB                                   # 两个检查点之间，wal可增长的最大大小，这是一个软限制
                                                   # 如果日志量大于max_wal_size，则WAL日志空间尽量保持在max_wal_size。因为会触发检查点，不需要                                                                                                         # 的段文件将被移除直到系统回到这个限制以下
                                                   # 如果日志量小于max_wal_size，则WAL日志空间至少保持min_wal_size
                                                   # 通常情况下，WAL日志空间大小在min_wal_size和max_wal_size之间动态评估。该估计基于在以前的检                                                                                                         # 查点周期中使用的WAL文件数的动态平均值。
                                                   # 如果实际使用量超过估计值，动态平均数会立即增加
min_wal_size=100MB                                 # 检查点后用来保留的，用于未来循环使用的wal文件。可以被用来确保有足够的 WAL 空间被保留来应付                                                                                                          # WAL 使用的高峰
                                                   # WAL异常增长，或WAL一直膨胀且超过max_wal_size，执行检查点后，WAL使用量未见降低或WAL日志不会                                                                                                     # 被删除重用，需要排查以下因素
                                                   # 独立于max_wal_size之外，wal_keep_segments + 1 个最近的 WAL 文件将总是被保留
                                                   # 启用了WAL 归档，旧的段在被归档之前不能被移除或者再利用
                                                   # 启用了复制槽功能，一个使用了复制槽的较慢或者失败的后备服务器也会导致WAL不能被删除或重用
                                                   # checkpoing未完成,长事务未提交
checkpoint_completion_target=0.5                   # 100GB /(0.5*5*60)*1024≈670M/s 100GB /(0.9*5*60)*1024≈380M/s
checkpoint_timeout=10min                           # 写入速度越低，对客户而言，体验越好，性能越高。反之，较低的值可能会引起I/O峰值，导致“卡死”的现象
shared_buffers=1GB                                 # 最佳值为内存RAM 1/3
archive_cleanup_command                            # 提供一个清理不被standby server所需要的老的archived wal file
                                                   # %r代表最后一个有效的restart point 的 wal file.该 wal file 是最早一个必须保留的文件，以便                                                                                                        # 允许 restore 操作可以被 restart
                                                   # 注意：restart point 是一个 point ，该 point 用于 standby server 重启 recovery 操作。
                                                   # 因此，所有早于 % r 的文件可以被安全的清理掉。本信息可以用来 truncate 掉 
                                                   # archive wal file，以便满足从当前 restore 可以 restart 的最小需求
                                                   # 常被用在单个 standby 配置的 archive_cleanup_command 参数中
                                                   # 当命令被一个 signal 终止或者 shell 中有错误时，一个 fatal error 会被抛出

关于synchronous_standby_names参数

该参数用于指定：基于优先的多同步后备节点对事务提交的影响 synchronous_standby_names =“FIRST 2 ()”，所有流复制链接到此主节点的standy节点中，任意选择两个节点是sync状态，剩下的都是potential状态； synchronous_standby_names =“ANY 2 ()”，所有流复制链接到此主节点的所有standy节点都是quorum状态。

pg_stat_replication 表中的 sync_state 字段的状态： FIRST语法下，同步的节点值为sync，异步的节点值为asyn；被匹配为同步的节点，但是被个数限制的值为 potential； Any语法下，值为quorum，表现上没有同步和异步一说，一个写事务主节点收到指定数量的standy节点的反馈，接着就会给客户端返回事务执行成功。

多个同步后备同步复制支持一个或者更多个同步后备服务器，事务将会等待，直到所有同步后备服务器都确认收到了它们的数据为止。事务必须等待其回复的同步后备的数量由synchronous_standby_names指定。这个参数还指定一个后备服务器名称及方法(FIRST和ANY)的列表来从列出的后备中选取同步后备。

方法FIRST指定一种基于优先的同步复制并且让事务提交等待，直到它们的WAL记录被复制到基于优先级选中的所要求数量的同步后备上为止。在列表中出现较早的后备被给予较高的优先级，并且将被考虑为同步后备。其他在这个列表中位置靠后的后备服务器表示可能的同步后备。如果任何当前的同步后备由于任何原因断开连接，它将立刻被下一个最高优先级的后备所替代。

基于优先的多同步后备的synchronous_standby_names示例为：

synchronous_standby_names = ‘FIRST 2 (s1, s2, s3)’ 在这个例子中，如果有四个后备服务器s1、s2、s3和s4在运行，两个后备服务器s1和s2将被选中为同步后备，因为它们出现在后备服务器名称列表的前部。s3是一个潜在的同步后备，当s1或s2中的任何一个失效，它就会取而代之。s4则是一个异步后备因为它的名字不在列表中。

方法ANY指定一种基于规定数量的同步复制并且让事务提交等待，直到它们的WAL记录至少被复制到列表中所要求数量的同步后备上为止。

synchronous_standby_names的基于规定数量的多同步后备的例子：

synchronous_standby_names = ‘ANY 2 (s1, s2, s3)’ 在这个例子中，如果有四台后备服务器s1、s2、s3以及s4正在运行，事务提交将会等待来自至少其中任意两台后备服务器的回复。s4是一台异步后备，因为它的名字不在该列表中。

后备服务器的同步状态可以使用pg_stat_replication视图查看。

7、repmgr.conf参数说明

# 日志管理

log_level=INFO
log_file='/home/kes86/cluster/log/repmgrd.log'      # repmgr log 文件
log_status_interval=10                              # 此设置导致 repmgrd 以指定的时间间隔(以秒为单位，默认为 300)发出状态日志行，
                                                                                                        # 描述 repmgrd 的当前状态， 
                                                    # 例如：  [2022-10-30 17:51:15] [INFO] monitoring primary node "node1" (ID: 1) in normal state
failover=automatic/manual

# failover设置

promote_command='/home/kes86/kes86/cluster/bin/repmgr standby promote -f /home/kes86/kes86/cluster/etc/repmgr.conf'                     
# 当repmgrd 确定当前节点将成为新的主节点时 ，将在故障转移情况下执行 
follow_command='/home/kes86/kes86/cluster/bin/repmgr standby follow -f /home/kes86/kes86/cluster/etc/repmgr.conf --upstream-node=%n'   
# %n将被替换repmgrd与新的主节点的ID,如果没有提供,repmgr standby  follow将尝试自行确定新的主repmgr standby follow节点
# 但如果在新主节点提升后原主节点重新上线，则存在导致节点继续跟随原主节点的风险。
repmgrd_pid_file='/home/kes86/kes86/cluster/etc/hamgrd.pid'
# repmgrd 运行时的 pid 文件

# 高可用参数设置

location='location1'                # 定义节点位置的任意字符串,在故障转移期间用于检查当前主节点的可见性
priority=100                        # 节点优先级，选主时可能使用到。(lsn > priority > node_id)
                                    # 0 代表该节点不会被提升为主节点
monitoring_history=yes              # 是否将监控数据写入“monitoring_history”表
reconnect_interval=10               # 故障转移之前，尝试重新连接的间隔(以秒为单位)
reconnect_attempts=6                # 故障转移之前，尝试重新连接的次数
connection_check_type=ping          # ping: repmg 使用PQPing() 方法测试连接
                                    # connection: 尝试与节点建立新的连接
                                    # query: 通过现有连接在节点上执行 SQL 语句
monitor_interval_secs=5             # 写入监控数据的间隔
use_replication_slots=true          # 是否使用复制槽