两台机器一份存储：KES RAC 共享存储多写集群从零搭起

weixin_66401877

11402人浏览 · 2026-06-20 19:24:47

weixin_66401877 · 2026-06-20 19:24:47 发布

金融、政务、能源这些行业的核心系统,对数据库的要求是出了名的苛刻——既要"五个 9"的可用性,又要强一致,还得扛得住高并发。传统的单机或主备架构在这种压力下,短板暴露得很彻底：主库是单点,挂了整个业务跟着停;写操作只能压在主节点上,备节点干瞪眼分担不了写负载;故障切换还经常要人工介入,VIP 漂移、角色转换走完一套流程,几十秒到几分钟就没了,达不到金融级的秒级恢复。

KingbaseES 的共享存储多写集群（KES RAC）走的是另一条路:多个数据库实例并行访问同一套共享存储,真正做到多点写入和负载均衡。官方实测在典型 OLTP 场景下,写入性能相比主备模式提升三倍以上,RTO 接近 0,RPO 为 0。这篇就把一套两节点 RAC 从环境准备搭到故障切换验证,顺手把容易栽跟头的地方点出来。

先搞清楚它靠什么撑起来

动手之前得明白 RAC 这套架构的几根支柱,不然配到一半会一头雾水:

共享存储是地基。所有节点通过 SAN/NAS 或分布式文件系统访问同一份数据文件、控制文件和重做日志。这意味着存储设备的 IOPS、延迟、可靠性直接决定集群上限——它是整个架构里唯一不能省的硬投入。

集群件是大脑,基于 Pacemaker + Corosync 构建,负责节点状态监控、故障检测和资源调度。

**缓存融合（Cache Fusion）**是性能关键。通过高速私网（InfiniBand/RDMA）把各节点 Buffer Pool 里的数据块同步起来,减少重复读盘,保证内存级的数据一致。

全局锁管理器（GLM） 解决多节点同时写的冲突——所有 DML 得先拿到对应数据页的全局排他锁。

仲裁机制（QDevice） 防脑裂。网络一旦分区,谁手里票多谁继续服务,另一边自动降级。这东西通常部署在独立的第三方节点上,别图省事跟某个数据库节点共用一台机器 ,否则那台机器一挂,仲裁和数据节点一起没,等于白配。

拓扑很简单,两个实例节点 + 一份共享存储 + 一个仲裁节点:

在这里插入图片描述

环境准备:这一步偷懒后面全是坑

两节点的硬件建议保持完全对称——CPU 16 核、内存 64GB、本地 500GB SSD、共享 2TB,两台配一样。内存配置不一致会导致性能不均衡,RAC 里这个尤其忌讳。

操作系统层面,所有节点装相同版本的 Linux（CentOS 7.9 或银河麒麟 V10）,然后跑一套基础配置。关键词是"所有节点"——下面这些步骤每台都要做一遍,漏一台后面集群通信就起不来:

# 1. 创建数据库用户（注意 uid 各节点保持一致）
useradd -u 2000 kingbase
echo "kingbase:Kb@2024" | chpasswd

# 2. 配置主机名解析
cat >> /etc/hosts << EOF
10.0.1.10 node1
10.0.1.20 node2
10.0.2.10 qdevice
EOF

# 3. 关防火墙或放行端口（5400 集群通信 / 54321 数据库 / 7788 Cache Fusion）
systemctl stop firewalld
systemctl disable firewalld

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

# 5. 时间同步（集群对时钟漂移很敏感,这步不能省）
timedatectl set-ntp true
timedatectl set-timezone Asia/Shanghai

内核参数里,共享内存那几项是给 RAC 专门调的:kernel.shmmax 设 64GB、kernel.shmall 设 16777216、kernel.sem 设 250 32000 100 128、vm.swappiness 压到 10。再把网络缓冲区（net.core.rmem_max / wmem_max 等）和 TCP keepalive 调一调,改完 sysctl -p 生效。资源限制方面,nproc 和 nofile 都给 kingbase 用户拉到 65535,生产环境连接一多很容易撞上默认上限。

网络要双网卡分工:eth0 走业务（10.0.1.x）,eth1 走集群私网（192.168.1.x）专门给 Cache Fusion 和集群通信用。再留一个 VIP（10.0.1.100）,这个在 Clusterware 里配,不在网卡上直接绑。

共享存储:多路径不是可选项

共享存储是 RAC 的命根子,配置上几个要点:

先装多路径软件 device-mapper-multipath,这在生产 SAN 环境里几乎是必配——单路径一断链路存储就丢,多路径才能保证一条线挂了还有另一条顶着。配置 /etc/multipath.conf 时把 path_grouping_policy 设成 multibus、failback 设 immediate,再把 sr、loop 这类设备拉进黑名单避免误识别。

存储识别出来后,只在主节点上做卷管理和格式化,别两台都做:

# 仅主节点执行
pvcreate /dev/mapper/mpatha1
vgcreate kingbase_vg /dev/mapper/mpatha1
lvcreate -L 1.8T -n kingbase_lv kingbase_vg
mkfs.xfs /dev/kingbase_vg/kingbase_lv

挂载点 /sharedata/kingbase 和 /etc/fstab 的挂载配置则是所有节点都要做,挂载时建议加 noatime 减少不必要的 inode 写入。最后务必做一次跨节点验证——node1 上 touch 一个文件,node2 上能 ls 到,才说明共享存储真的通了。这一步看着多余,但能省掉后面一堆莫名其妙的排查。

部署集群件:SSH 免密是隐形前提

Clusterware 可以走集成化安装包一键部署,也可以解压绿色版手动来。如果安装目录不是默认的 /opt,记得改 cluster_manager.conf 里的 install_dir。

**SSH 免密登录是 Clusterware 集群通信的基础,也是最容易被忽略的一步。**所有节点之间都要互相打通,不光是 node1→node2,反向也得配:

su - kingbase
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
# 每个节点都对所有节点（含自己）做一遍 ssh-copy-id
ssh-copy-id kingbase@node1
ssh-copy-id kingbase@node2
# 验证：能无密码拿到对方时间才算成
ssh node1 "date" && ssh node2 "date"

集群配置文件 cluster_manager.conf 里把集群名、节点列表、安装目录、共享数据目录、VIP、VIP 绑定网卡、仲裁节点 IP 都填好。接着在独立的仲裁机上初始化 QDevice,仲裁算法用 ffsplit,这是防脑裂的最后一道闸。

然后所有节点跑 --base_configure_init 做基础初始化,它会自动装 Corosync/Pacemaker、配通信参数、挂共享存储、设资源约束。

把数据库注册成集群资源

这是 RAC 跟普通部署区别最大的地方——数据库不再是你手动 start/stop 的进程,而是交给 Clusterware 托管的"资源"。在 node1 上依次配三类资源,再打包成组:

# 共享存储资源
crm configure primitive FS_KINGBASE ocf:heartbeat:Filesystem \
    params device="/dev/kingbase_vg/kingbase_lv" \
          directory="/sharedata/kingbase" fstype="xfs" \
    op monitor interval="20s" timeout="40"

# 虚拟 IP 资源
crm configure primitive VIP_KINGBASE ocf:heartbeat:IPaddr2 \
    params ip="10.0.1.100" cidr_netmask="24" nic="eth0" \
    op monitor interval="10s" timeout="20"

# 数据库实例资源
crm configure primitive DB_KINGBASE ocf:kingbase:kingbase \
    params kb_data="/sharedata/kingbase/data" kb_port="54321" ... \
    op monitor interval="9s" timeout="30"

# 打包成组,固定启动顺序：先 VIP,再挂存储,最后起库
crm configure group KINGBASE_GROUP VIP_KINGBASE FS_KINGBASE DB_KINGBASE

资源组的顺序不是随便排的——VIP→存储→数据库,这个先后保证了起库时存储已经挂好、地址已经就位。

再补两条让集群更稳的配置:位置约束让资源优先落在 node1（权重 1000 比 node2 的 800 高）;资源粘性 resource-stickiness=500 防止资源在节点间反复横跳。配完 crm configure show 和 crm_verify --live-check 检查一遍。

实例初始化:两个节点不一样

这里有个容易搞错的点:两个节点的初始化方式完全不同。

node1 是"开荒"的,要真正 initdb 出数据目录到共享存储上:

./initdb -D /sharedata/kingbase/data --locale=zh_CN.UTF-8 --encoding=UTF8

然后改 kingbase.conf,RAC 模式有几个跟单机不一样的参数得特别注意:synchronous_commit = off、max_wal_senders = 0、wal_level = minimal——这些在 RAC 下都跟主备模式反着来,因为多写架构靠的是 Cache Fusion 和共享存储,不再依赖 WAL 流复制。再打开 enable_rac_mode = on,设好 rac_node_id、rac_node_name、rac_private_ip。

node2 则绝对不能再 initdb——数据目录已经在共享存储上了,再初始化一次就把 node1 的数据冲了。node2 要做的是把配置文件复制到本地,改掉节点特定参数（rac_node_id 必须唯一、私网 IP 换成自己的）,日志走本地路径,然后指定本地配置文件启动:

./sys_ctl -D /sharedata/kingbase/data -c /home/kingbase/config/kingbase.conf start

数据目录共享、配置文件各自本地化,这是 RAC 双节点的标准做法。

启动、验证、模拟故障

集群件起来后（systemctl start corosync pacemaker）,crm status 应该能看到两个节点 Online,资源组里 VIP、FS、DB 三个资源都 Started。

功能验证连的是 VIP 而不是某个节点的真实 IP——这正是 RAC 对外屏蔽节点细节的体现。连上去查 sys_rac_nodes 看节点状态、查 sys_rac_locks 看全局锁,再在多个会话里并发写入,确认数据一致。

最关键的是故障切换演练,这是验收 RAC 价值的核心动作:

crm resource stop DB_KINGBASE      # 模拟主节点库故障
crm status                          # 观察资源是否自动切到 node2
ip addr show | grep 10.0.1.100      # 确认 VIP 已漂移
ksql -h 10.0.1.100 -p 54321 -U system -d testdb -c "SELECT version();"  # 服务仍可用
crm resource start DB_KINGBASE      # 恢复

VIP 漂过去、服务不中断,这套流程跑通了,RAC 才算真正落地。这个演练一定要在上生产前做,而且最好定期复演——很多集群是平时好好的,真出故障时才发现切换链路某个环节早就坏了。

性能调优:RAC 的内存账要重算

RAC 的参数调优跟单机有个反直觉的地方:shared_buffers 反而要调小。官方建议压到物理内存的 18% 左右（比如 12GB）,把省出来的内存让给 Cache Fusion 和并发连接。effective_cache_size 给 48GB,work_mem 给 128MB,maintenance_work_mem 给 2GB。

Cache Fusion 这块单独调:连接池 rac_cache_fusion_pool_size 给 2GB、缓冲区 8MB、超时 30s,并开启自适应 rac_cache_fusion_adaptive。检查点方面把 checkpoint_completion_target 设 0.9、checkpoint_timeout 拉到 15min,削峰填谷减少 IO 抖动。改完 SELECT sys_reload_conf() 重载。

监控建议上 Prometheus,重点盯三个指标并配告警:节点存活（kingbase_cluster_node_up,掉了就 critical）、Cache Fusion 延迟（超 100ms 告警,这是节点间同步变慢的信号）、全局锁争用比（超 0.3 告警,说明多节点抢锁太凶,往往是热点数据或事务设计的问题）。