KingbaseES高可用最佳应用实践——全架构部署、故障自愈与运维规范

云边有个稻草人
0 阅读13分钟

一、前言

在金融、政务、能源、通信等关键行业的核心业务系统里，数据库能不能稳定运行，直接关系到业务能不能连续开展、数据安不安全。KingbaseES作为国产自主可控的企业级关系型数据库，提供了从单机基础保护、读写分离集群、共享存储集群到完善备份恢复体系的一整套高可用解决方案，能够满足不同规模、不同等级业务对连续性的严格要求。本文把高可用架构、核心配置、故障处理、计划内操作、备份恢复等关键内容做系统化梳理和落地解读，提炼出能直接用在生产环境里的最佳实践，帮助运维和开发人员快速搭建稳定、可靠、易扩展的高可用数据库系统。

二、KingbaseES高可用体系整体架构与能力分级

KingbaseES高可用以MAA最大可用性架构为设计目标，按照可用性从低到高分成四个等级，覆盖从测试环境到核心生产环境的全部场景。

第一级是单机高可用，主要面向非核心业务或者开发测试环境。依靠操作系统参数调优、数据库关键配置、自动重启和基础恢复能力，实现简单软件故障的自动处理，在不增加硬件成本的前提下，把基础稳定性提上来。

第二级是读写分离集群，基于流复制技术实现一主多备架构，支持自动故障切换、VIP漂移、读写负载均衡，能应对主机、网络、存储等硬件故障，大幅缩短故障恢复时间，是目前生产环境里最主流的高可用方案。

第三级是KingbaseES Clusterware共享存储集群，基于corosync与pacemaker实现资源统一管控，支持共享存储双活、多实例集约化部署、强一致性故障隔离，适合对RTO要求极高、多业务整合部署的关键核心系统。

第四级是备份恢复体系，作为数据安全最后一道防线，提供全量、增量、差异备份与时间点恢复能力，能应对数据损坏、误操作、站点级灾难这些极端情况，保证数据可追溯、可恢复。

这四级架构互相配合，形成故障自愈、负载分担、资源调度、数据备份的完整高可用闭环，为企业提供持续稳定的数据库服务能力。

三、单机高可用部署实践：基础稳定性的构建方式

单机高可用是所有高可用方案的基础，核心目标就是在单实例部署模式下，通过标准化配置提升可靠性，能自动处理实例异常、配置错误这类简单故障，出现停机时快速恢复服务，尽量减少对业务的影响。

（一）操作系统强制基础配置

操作系统环境直接影响数据库运行稳定性，KingbaseES单机部署必须对防火墙、SELinux、资源限制、内核参数做标准化配置。 关闭防火墙或者开放数据库默认54321端口，避免网络访问被拦截导致数据库连不上；强制关闭SELinux，防止权限策略拦截数据库进程读写文件；调整文件句柄数、进程数为65536，满足高并发连接需求；配置内核信号量参数，保证数据库进程间通信稳定。

# 关闭 SELinux
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
setenforce 0

# 修改资源限制
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
EOF

# 设置信号量内核参数
echo "kernel.sem = 5010 64128000 50100 1280" >> /etc/sysctl.conf
sysctl -p

（二）数据库核心参数配置

kingbase.conf是数据库运行的核心配置文件，合理配置能提升稳定性、可恢复性与监控能力。单机环境必须开启归档模式，为物理备份与故障恢复打下基础；设置合适的共享内存、连接数、WAL日志参数，保证数据库运行高效稳定。

listen_addresses = '*'
port = 54321
max_connections = 业务峰值连接数 × 1.2
shared_buffers = 物理内存的 1/3
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
wal_keep_segments = 512
logging_collector = on
log_destination = csvlog

（三）开机自启动与故障恢复

单机环境需要把数据库注册成系统服务，实现开机自动启动，提升运维便利性。

# 注册开机自启服务
/opt/Kingbase/ES/V9/install/script/root.sh
systemctl enable kingbased

出现实例故障时，可以直接用重启命令快速恢复；如果遇到数据损坏或者存储故障，就必须依靠备份恢复机制找回数据，这也说明单机环境一定要搭配备份策略才能真正安全。

四、读写分离集群高可用实践：生产主流方案详解

读写分离集群是KingbaseES高可用的核心方案，基于流复制实现主备数据实时同步，主库负责写入，备库提供只读查询，具备自动故障切换、负载均衡、异地容灾等能力，能满足核心业务高可用需求。

（一）集群部署前提条件

集群所有节点必须满足严格的环境一致性要求。所有节点时钟要同步，误差必须小于2秒，避免WAL日志回收异常；关闭防火墙或者开放54321、8890等集群通信端口；主备节点硬件配置尽量一致，保证故障切换后性能平稳；配置节点间免密登录，用sys_securecmdd或者ssh都可以，保证集群管理工具正常通信。

（二）数据库复制配置（es_rep.conf）

要保证主备数据一致和备库可读，必须开启流复制相关参数，这是集群能正常运行的基础。

wal_level = replica
max_wal_senders = 32
hot_standby = on
hot_standby_feedback = on
synchronous_commit = remote_apply
wal_log_hints = on
full_page_writes = on

（三）集群管理配置（repmgr.conf）

repmgr是集群管理核心组件，负责节点监控、故障检测、主备选举、VIP漂移这些操作。配置里要明确节点信息、故障切换策略、监控间隔、VIP等关键参数。

node_id = 1
node_name = 'node1'
conninfo = 'host=192.168.2.129 user=esrep dbname=esrep port=54321 connect_timeout=10'
failover = 'automatic'
recovery = 'automatic'
monitor_interval_secs = 2
reconnect_attempts = 3
reconnect_interval = 5
virtual_ip = '192.168.2.200/24'
net_device = 'eth0'

（四）JDBC读写分离配置

KingbaseES提供对应用透明的JDBC读写分离能力，不用修改业务代码就能实现读请求负载均衡，降低主库的查询压力。

USEDISPATCH=true
HOST=192.168.2.129
PORT=10001
DBNAME=TEST
SLAVE_ADD=192.168.2.129,192.168.2.129
SLAVE_PORT=10002,10003
nodeList=node1,node2,node3
HOSTLOADRATE=50

（五）故障处理与自动切换

读写分离集群有很完善的故障自愈能力。主库宕机、断网、掉电时，备库在重试检测之后自动发起选举，按照LSN、节点优先级、node_id选出新主库；VIP会自动漂移到新主库，应用几乎无感知切换；原主库恢复之后，可以自动或者手动重新加入集群，变成新备库；遇到网络分区、脑裂这些复杂场景，可以按照时间线、LSN判断最新数据节点，人工介入就能恢复集群。

（六）常用集群运维命令

实际运维过程中，经常需要查看集群状态、做手动切换、把故障节点重新加入集群。下面这些命令是日常维护最常用的，记熟能大幅提高工作效率。

# 查看集群状态
repmgr cluster show

# 手动主备切换
repmgr standby switchover

# 节点重新加入集群
repmgr node rejoin -h 新主IP -U esrep -d esrep --force-rewind

# 启动/停止集群服务
sys_monitor.sh start
sys_monitor.sh stop

五、KingbaseES Clusterware共享存储集群实践

Clusterware是面向企业级核心业务的高可用方案，基于共享存储架构，通过corosync实现集群成员管理，通过pacemaker实现资源调度，支持双节点多活部署、资源自动漂移、强隔离fencing机制，适合高可靠、集约化部署的场景。

（一）核心组件与架构

Clusterware由三大核心组件组成。corosync负责集群心跳、节点管理、投票盘qdevice仲裁，避免脑裂；pacemaker负责VIP、文件系统、数据库、存储锁等资源的调度与故障转移；qdevice投票盘在双节点环境下提供仲裁能力，保证集群在网络分裂时选出有效分区。

（二）corosync关键配置

corosync.conf定义集群心跳、节点列表、投票策略，是集群稳定运行的基础配置，参数设置不合理很容易导致集群异常。

totem {
    version: 2
    token: 60000
    cluster_name: 2nodes
}
nodelist {
    node { ring0_addr: node1 nodeid:1 }
    node { ring0_addr: node2 nodeid:2 }
}
quorum {
    provider: corosync_votequorum
    expected_votes: 3
    device {
        votes: 1
        model: disk
        disk { label: "2nodes" }
    }
}

（三）资源配置与调度

Clusterware以资源形式管理数据库、VIP、共享文件系统、存储锁，通过组资源和约束规则保证启动顺序和位置绑定，避免资源分散在不同节点导致业务异常。

# 配置虚拟IP
crm configure primitive FIP1 ocf:heartbeat:IPaddr2 params ip="192.168.4.135" cidr_netmask="24" nic="bond0" op monitor interval=30s

# 配置共享文件系统
crm configure primitive FILESYSTEM1 ocf:heartbeat:Filesystem params device="-U 磁盘UUID" directory="/sharedata/data1" fstype="ext4"

# 配置数据库资源
crm configure primitive DB1 ocf:kingbase:kingbase params kb_data="/sharedata/data1/data" kb_port=54321 op monitor interval=9s

# 组资源绑定启动顺序
crm configure group DB1_GROUP FIP1 FILESYSTEM1 DB1

（四）故障处理机制

Clusterware对网络故障、节点故障、存储故障、进程挂起都有明确的处理策略。节点异常时自动触发fencing，强制隔离故障节点；资源失败后自动重启或者漂移到可用节点；网络分区时由投票盘仲裁有效节点，保证集群只有一个可用分区，避免数据错乱。

六、KingbaseES备份恢复最佳实践

备份恢复是数据安全的最后保障，KingbaseES提供独立备份与非独立备份两种模式，支持全量、增量、差异备份与时间点恢复PITR，能应对数据损坏、误删除、站点灾难等场景。

（一）备份方案选择

独立备份使用专用备份服务器，不占用业务节点资源，容灾能力更强，适合核心业务；非独立备份在数据库节点本地执行备份，配置简单、没有网络依赖，适合中小型环境。实际使用时可以根据业务重要程度、硬件条件灵活选择。

（二）备份配置（sys_backup.conf）

备份系统的配置直接决定备份是否可靠、恢复是否顺利，下面是生产环境常用的配置项，按照实际环境修改IP、路径、保留份数即可。

_target_db_style="cluster"
_one_db_ip="192.168.1.11"
_repo_ip="192.168.1.66"
_stanza_name="kingbase"
_os_user_name="kingbase"
_repo_path="/home/kingbase/back_dir"
_repo_retention_full_count=5
_crond_full_days=7
_crond_incr_days=1
_use_scmd=on

（三）备份与恢复常用命令

备份和恢复操作有固定的命令流程，熟练使用可以快速完成初始化、定时备份、手动备份、时间点恢复等工作。

# 初始化备份系统
sys_backup.sh init

# 启动定时备份
sys_backup.sh start

# 手动执行全量备份
sys_rman --config=/back_dir/sys_rman.conf --stanza=kingbase --type=full backup

# 按时间点恢复数据
sys_rman --config=/back_dir/sys_rman.conf --stanza=kingbase --type=time --target='2026-04-29 10:00:00' restore

（四）集群恢复策略

集群环境的恢复和单机不一样，要讲究顺序。单节点损坏时，用repmgr clone快速重建备库就行；全集群损坏时，先在一个节点执行备份恢复，再通过克隆方式恢复其他节点，能快速拉起整个集群，缩短业务中断时间。

七、高可用运维与计划内操作规范

想要高可用系统长期稳定运行，必须遵守标准化的计划内操作，包括补丁升级、配置变更、节点扩缩容等，随意操作很容易引发故障。

（一）补丁与升级规范

集群组件比如repmgr、kbha支持在线滚动升级，先升级备节点，再升级主节点，不影响业务；数据库内核升级要判断兼容性，兼容版本可以滚动升级，不兼容版本需要逻辑备份后重建实例；Clusterware升级可以用脱管资源或者滚动方式，优先选择停机升级，保证升级过程安全。

（二）配置变更规范

数据库热参数修改用sys_ctl reload就能生效，不需要重启；冷参数修改需要重启集群，应该选在业务低峰期操作；repmgr、corosync配置修改之后，要重启对应的守护进程，不然配置不会生效。

（三）节点增删规范

新增节点直接用repmgr注册加入集群即可，操作很简单；删除节点要先切换主库，把要删除的节点变成备库再移除，同时清理残留的复制槽，避免影响集群稳定性。

八、高可用监控指标与故障预防

持续监控是高可用的重要保障，KingbaseES高可用方案有明确的监控指标，日常运维要重点关注。集群节点状态要为running，出现failed、unreachable要及时处理；主备角色只能有一个primary，其他都是standby，严禁出现双主；数据库进程状态必须是running；流复制状态要为streaming，非streaming就是异常；复制延迟建议小于10秒，延迟过高会影响切换后的数据一致性。

同时，要定期做故障演练，比如模拟主库宕机、断网、存储故障、脑裂等场景，验证集群自愈能力，确保真的发生故障时能快速恢复，而不是临时手忙脚乱。

九、总结

KingbaseES高可用体系以标准化、自动化、易运维为设计核心，覆盖单机、读写分离集群、共享存储集群、备份恢复四大场景，能满足从非核心业务到关键核心系统的可用性要求。严格按照官方最佳实践，统一操作系统配置、数据库参数、集群管理策略、备份恢复机制，就能搭建稳定、高效、可自愈的数据库高可用环境，为企业业务7×24小时连续运行提供坚实支撑。实际生产落地时，建议优先采用读写分离集群，搭配独立备份和定期故障演练，形成完整可靠的高可用保障体系。

avatar
文章
阅读
粉丝