金仓KES RWC配置VIP步骤：

修改repmgr.conf‌：添加virtual_ip、net_device、arping_path等参数‌

设置权限‌：确保ip和arping命令具有setuid权限（chmod 4755）‌

重启集群‌：执行./sys_monitor.sh restart生效‌

验证‌：通过ip addr检查VIP加载，测试主备切换、主机故障时VIP漂移

本文档基于版本：kingbase V009R002C010

一、需求背景

现有一套金仓数据库（KingbaseES）RWC读写分离集群( 无VIP) 已在生产环境中稳定运行。现因客户业务架构调整及高可用性策略升级，客户正式提出在现有集群上 增加一套虚拟IP（VIP）地址 的需求，以用于业务分离、多服务通道或灾备切换演练等场景。

二、需求目标

在不影响集群现有业务正常运行的前提下，于集群内新增一个VIP资源，并确保其具备故障自动漂移能力，具体包括：

• 新增VIP地址可绑定至集群当前主节点；
• 当主节点发生故障或计划性切换时，新增VIP可随集群资源组自动迁移至新主节点；
• 新增VIP的监听端口及访问策略需与业务规划保持一致。

三、变更影响与风险评估

四、实施步骤概述

1. 规划确认 ：与客户确认新增VIP地址、子网掩码、绑定网卡及对外服务端口。已完成
2. 网络就绪 ：协调网络侧完成该VIP地址的交换机路由及防火墙策略放通（如有）。已完成
3. 配置添加 ：在集群管理工具中创建新的VIP资源，并关联至现有集群资源组，配置漂移策略。
4. 验证VIP配置 ：手动加载新VIP资源，验证VIP是否在预期节点生效，测试网络连通性及端口可达性。
5. 漂移测试 ：执行手动切换或模拟故障，验证新VIP能否正确迁移至备用节点。
6. 业务验证 ：由客户侧验证新增VIP对应的业务通道是否正常。

4.1、 规划确认

特别注意：

集群使用的虚拟ip，根据用户的网络配置可以设置掩码，默认/24。掩码需要和网卡net_device上的实际掩码一致。建议VIP的掩码与物理IP的掩码保持一致，如果VIP的掩码不一致，可能会导致网络有问题。

4.2、 网络就绪

略

4.3、 配置添加

金仓数据库（KingbaseES）RWC读写分离集群原 无VIP、现在需要新增VIP 的完整配置步骤。以RWC集群（基于repmgr管理）为例，核心思路是在每个节点的 repmgr.conf 中增加VIP相关配置项。

4.3.1、操作前准备

4.3.1.1、检查集群当前状态

在存活的数据库节点，使用kingbase用户执行（当前数据库故障则无法查看状态） 执行 repmgr cluster show 和 repmgr service status ，确认集群运行正常。

--数据库进程状态
repmgr cluster show
--守护进程状态
repmgr service status

4.3.1.2、备份配置文件

使用kingbase用户 备份 每个节点 的 安装目录/kingbase/etc/repmgr.conf 文件

cd /home/kingbase/cluster/install/kingbase/etc
cp repmgr.conf repmgr.conf_bak_`date +%Y%m%d`
ls -lhtr

4.3.1.3、确认网卡信息

• 每个节点都查看，执行 ip addr show 和 route -n   查看要承载VIP的网卡名称（如 ens32）及网卡实际IP及子网掩码。
• 配置vip的网卡必须和物理ip是同一个设备。

4.3.1.4、确认VIP地址规划

根据客户提供的IP规划（如192.168.40.155/24），确认子网掩码与网卡一致。

4.3.2、修改各节点配置文件

位置： 安装目录/kingbase/etc/repmgr.conf

repmgr.conf文件中参数说明：

特别强调各节点填写差异 ： net_device 和 net_device_ip 需根据每个节点的实际网卡信息填写，其他配置项所有节点保持一致。

• ip命令用于加载和卸载vip。
• arping命令用于vip切换中的arp cache的清理和测试。
• 对于arping的版本可以选择系统自带，建议使用数据库自带的版本，兼容性更好，本案例使用了数据库自带的版本。

在 每个集群节点 的 repmgr.conf 文件中 增加 以下内容：

# VIP地址及掩码（根据实际规划填写）
virtual_ip='192.168.40.155/24'
# ip命令路径（使用操作系统自带的/sbin/ip）
ipaddr_path='/sbin'
# arping命令路径（建议使用金仓自带的版本，兼容性更好）
arping_path='/home/kingbase/cluster/install/kingbase/bin'
# 承载VIP的网卡名称（各节点按实际填写）
net_device='ens32'
# 该网卡的实际IP地址（各节点按实际填写）
net_device_ip='192.168.40.107'

4.3.3、检查并调整可执行文件权限

卸载依赖 ip 和 arping 命令，需确保数据库用户有执行权限。

4.3.3.1、检查权限（以kingbase用户执行）

ls -l /sbin/ip
ls -l /home/kingbase/cluster/install/kingbase/bin/arping

4.3.3.2、调整权限（root用户执行，添加setuid权限）

chmod 4755 /sbin/ip
chown root:root /home/kingbase/cluster/install/kingbase/bin/arping
chmod 4755 /home/kingbase/cluster/install/kingbase/bin/arping

4.3.3.3、确认权限正确（应显示 -rwsr-xr-x ）

注意：如果arping使用金仓自带版本，需确保属主属组为root用户

ls -l /sbin/ip
ls -l /home/kingbase/cluster/install/kingbase/bin/arping

4.3.4、重启集群使配置生效

sys_monitor.sh restart

观察启动日志中是否有VIP加载成功的输出，如 下图

4.3.5、问题处理

[ERROR] No execute permission for "/home/kingbase/cluster/install/kingbase/bin/arping"

问题描述

repmgr.conf 配置文件中增加VIP参数后，查看集群状态报错：[ERROR] No execute permission for "/home/kingbase/cluster/install/kingbase/bin/arping"  。

增加的参数有：

# VIP地址及掩码（根据实际规划填写）
virtual_ip='192.168.40.155/24'
# ip命令路径（使用操作系统自带的/sbin/ip）
ipaddr_path='/sbin'
# arping命令路径（建议使用金仓自带的版本，兼容性更好）
arping_path='/home/kingbase/cluster/install/kingbase/bin'
# 承载VIP的网卡名称（各节点按实际填写）
net_device='ens32'
# 该网卡的实际IP地址（各节点按实际填写）
net_device_ip='192.168.40.107'

从报错信息来看： arping 命令没有正确设置执行权限 ，导致repmgr无法完成VIP的加载/卸载操作。

问题原因

设置了 /sbin/ip 和/home/kingbase/cluster/install/kingbase/bin/arping的权限，但 遗漏了对 /home/kingbase/cluster/install/kingbase/bin/arping 文件的属主属组从kingbase更改成root。

分析过程

配置文件中arping路径

cd /home/kingbase/cluster/install/kingbase/etc/
cat repmgr.conf | grep arping_path

使用的是 数据库自带的版本，非操作系统版本。

检查当前arping权限

当前显示的有setuid位但是属主属组是kiingbase而非root

ls -l /home/kingbase/cluster/install/kingbase/bin/arping

解决办法

修改arping权限（需root用户）

# 切换到root用户
su -root
# 修改arping属主为root，并添加setuid权限
chown root:root /home/kingbase/cluster/install/kingbase/bin/arping

验证权限是否正确

ls -l /home/kingbase/cluster/install/kingbase/bin/arping

重新加载集群（或重启集群）

# 在主节点执行，重新加载VIP资源
repmgr cluster reload
或
# 执行服务重启命令
./sys_monitor.sh restart
或
# 以kingbase用户手动执行arping测试，确认权限生效
/home/kingbase/cluster/install/kingbase/bin/arping -c 3 -I ens32 192.168.40.155

再次检查集群状态

在存活的数据库节点，使用kingbase用户执行（当前数据库故障则无法查看状态） 执行 repmgr cluster show

不再报权限错误，正常显示集群节点状态及VIP绑定信息

补充：如果arping不在金仓自带目录下

如果金仓安装目录下没有arping，可以使用系统自带的：

# 确认系统arping位置
which arping
# 通常在 /sbin/arping 或 /usr/sbin/arping
# 设置权限
chown root:root /sbin/arping
chmod 4755 /sbin/arping

然后修改 repmgr.conf 中的 arping_path 指向系统路径：

arping_path='/sbin'

快速检查清单

4.4、 验证VIP配置

4.4.1、VIP是否加载

执行 ip addr show ， 在主节点网卡上能看到新增VIP 192.168.40.155/24

4.4.2、VIP连通性

分别从其他2个节点的机器上 ping 192.168.40.155 ， 能ping通

4.4.3、数据库连接

通过VIP连接数据库： ksql -h 192.168.40.155 -p 54321 -U system -d test

4.4.4、故障切换测试

手动停止主库，观察VIP是否漂移。VIP自动漂移至新主节点，应用可继续通过VIP访问。

4.4.5、主备switchover切换测试

4.4.5.1、查看当前集群状态

存活的数据库节点，使用kingbase用户执行（当前数据库故障则无法查看状态） 执行 repmgr cluster show

。图略

4.4.5.2、手动切换主备节点

在准备成为主节点的standby节点运行： repmgr standby switchover --force-rewind --siblings-follow --verbose 。图略

--备机操作(要升主的备机)
2节点
repmgr standby switchover --siblings-follow  --verbose
＞＝3节点
repmgr standby switchover --force-rewind --siblings-follow --verbose

4.4.5.3、查看切换之后的集群状态

会发现主节点ip变为192.168.40.160,备节点是192.168.40.107。图略

4.4.5.4、查看VIP节点是否已经加载在新主节点环境

在192.168.40.160环境中执行 ip addr show , 发现VIP已经加载在新主节点环境。图略

4.4.5.5、查看原主库vip（已经被卸载）

在192.168.40.107环境中执行 ip addr show , 发现VIP已经被卸载。图略

4.4.6、集群failover switch测试

4.4.6.1、关闭主节点数据库服务

手动关闭数据库服务命令  sys_ctl  stop -D data 目录

4.4.6.2、查看集群状态

在存活的数据库节点，使用kingbase用户执行（当前数据库故障则无法查看状态） 执行 repmgr cluster show

4.4.6.3、将原主加入集群

在故障的数据库节点执行 repmgr node rejoin -h 192.168.40.160 -Uesrep -desrep  --force-rewind

即node1  节点执行

# 在故障的数据库节点执行
repmgr node rejoin -h ${主库 IP} -d esrep -U esrep -p ${主库 port} [--force-rewind] [--no-check-wal]
# 可以执行简化后的命令  本文采用简化后的命令
kbha -A rejoin -h ${主库 IP}

4.4.6.4、查看集群状态

在存活的数据库节点，使用kingbase用户执行（当前数据库故障则无法查看状态） 执行 repmgr cluster show

4.4.6.5、查看failover后vip的加载

4.5、 业务验证

略

五、注意事项

• 新增VIP的地址段必须与集群节点所在网段一致，避免跨网段引起路由不可达；
• 若集群中使用了防火墙或安全组策略，需同步更新放行规则；
• 如有监控系统或负载均衡器，需绑定了新增VIP，评估是否有必要纳入新增VIP的监听；
• 操作完成后，请客户侧更新相关配置文档及运维手册。
• 集群使用的虚拟ip，根据用户的网络配置可以设置掩码，默认/24。掩码需要和网卡net_device上的实际掩码一致。建议VIP的掩码与物理IP的掩码保持一致，如果VIP的掩码不一致，可能会导致网络有问题。
• VIP不支持域名解析。

参考链接： https://blog.csdn.net/2301_76369891/article/details/153977048