数据库教程FGMT77:国产数据库-人大金仓数据库工程师培训实战教程(同步复制、读写分离、集群高可用)
数据库教程FGMT77:国产数据库-人大金仓数据库工程师培训实战教程(同步复制、读写分离、集群高可用)
一、前言与风哥教程本文大纲
风哥教程本文面向已经掌握 KingbaseES 单机安装、SQL 运维与基础备份恢复的数据库工程师,目标是把一套可落地的国产数据库高可用集群从裸机环境一路搭到可切换、可读、可恢复的生产形态。本套风哥教程以人大金仓 KingbaseES(V8R6 通用机部署形态为主线,命令与参数同样适用于 V9 系列)为对象,围绕三条主线展开:第一条是同步复制,即主库把 WAL 日志实时同步到备库并回放,保证 RPO 趋近于零;第二条是读写分离,即在数据守护集群之上让备库对外提供只读查询,把读负载从主库卸载;第三条是集群高可用,即由守护进程完成故障自动探测、自动提升、VIP 漂移与故障库自动恢复。
风哥教程本文不做产品宣传,所有结论都对应可执行的命令与可观察的视图输出。全文按五个部分组织:第一部分为本前言与大纲;第二部分为理论,讲清流复制、同步模式、集群组件、故障转移时间构成与读写分离事务一致性;第三部分为实战操作,从操作系统基线、软件分发、免密通道、部署配置文件、一键部署、验收、同步验证、读写分离验证、计划内切换、计划外故障演练,一直到故障库恢复与日常运维;第四部分为风哥针对本文总结;第五部分为附录命令清单。
本套风哥教程的实验环境统一为两台物理或虚拟机,每台 64GB 内存、8 颗 CPU,主机名分别为 fgedu-net-cn1(主节点,规划 IP 192.168.10.11)与 fgedu-net-cn2(备节点,规划 IP 192.168.10.12),集群浮动 VIP 规划为 192.168.10.100。软件安装根目录统一为 /fgedudb,数据目录为 /fgedudb/kingbase/data,数据库实例名与业务库名均为 fgedudb,数据库管理用户为 fgedu,监听端口采用默认 54321。所有内存类参数都按 64GB 内存、8 颗 CPU 的规格测算,读者在其他规格上落地时只需按比例缩放,结构不变。
二、理论部分
2.1 KingbaseES 高可用体系的四个层次
风哥教程本文先建立全局视角。KingbaseES 的高可用能力不是单一产品,而是由四个层次构成的技术家族,工程师必须先分清,否则现场最容易把 RAC 和读写分离集群混为一谈。
第一层是单机版。单机版只有一个实例,靠本地 WAL 与备份恢复保证数据安全,能处理软件级简单故障,但主机宕机、磁盘损坏时服务中断。第二层是金仓数据守护集群(Kingbase Data Watch),基于物理流复制,由主库、备库与守护进程组成,主库读写、备库只读,守护进程负责状态探测与故障转移,这是本套风哥教程同步复制与高可用的主体。第三层是金仓读写分离集群(KingbaseRWC),在数据守护集群之上增加对应用透明的读写负载均衡,所有备库都可对外提供查询,读请求被分发到备库,主库只承担写与强一致读。第四层是 KingbaseRAC,采用共享存储、对等多写架构,多节点同时可写,依赖缓存交换保持一致,其部署工具、前置条件与系统要求与本套风哥教程完全不同,不要混用。
本套风哥教程聚焦第二层与第三层:一主一备(可扩展为一主多备)的物理流复制集群,外加 JDBC 层读写分离。
2.2 WAL、LSN 与流复制的物理过程
理解同步复制,必须先理解 WAL。WAL(Write-Ahead Logging,预写式日志)是 KingbaseES 保证数据完整性的标准方案:任何对数据页的修改都必须先把修改记录写入 WAL 并持久化,再去改数据文件。WAL 按顺序追加写入,数据文件则是随机位置写入,因此事务提交时只需把 WAL 落盘即可确认,不必等待脏数据页全部刷盘,这是并发性能的来源。
WAL 按 wal_segment_size 切分为段文件,默认每段 16MB,段文件名是 24 位十六进制,前 8 位为时间线,后 16 位为段号,例如 000000010000000A0000002C。每一条修改记录称为一条 Record,每条 Record 都有一个单调递增的 LSN(Log Sequence Number,日志序列号),对外显示为 %08X/%08X 形式。主备之间判断是否追平,本质就是比较主库的 flush_lsn 与备库的 replay_lsn 是否一致。
流复制的物理过程分四步,这是风哥教程本文反复引用的链路:
- 主库 WalWriter 进程把产生的 WAL 写入本地磁盘段文件;
- 主库 walsender 进程读取新增 WAL,以数据流方式通过 TCP 发送给备库;
- 备库 walreceiver 进程把收到的 WAL 写入本地 WAL 段文件;
- 备库 startup 进程读取本地 WAL 顺序重放(REDO),完成数据同步。
主库状态为 DB_IN_PRODUCTION(可读写、可生成 WAL),备库处于恢复态(sys_is_in_recovery() 返回 t,只读、不能生成 WAL)。备库可通过 SELECT sys_promote(); 提升为主库,主库不能直接降为备库,必须走切换或 rejoin 流程。
2.3 同步、异步、优选同步与全同步模式
KingbaseES 高可用集群按数据保护级别提供多种复制模式,这是现场选型的核心。
异步(async)模式下,主库只需把 WAL 写到本地磁盘(流程第 1、2 步)即可向客户端提交,不必等待备库接收与回放。优点是写延迟低、吞吐高;缺点是主库宕机时备库可能尚未收到最新 WAL,存在少量数据丢失风险(RPO 不为零)。
同步(sync)模式下,主库提交必须等待备库确认收到并回放完成,数据最终一致,任何故障都不丢已提交数据(RPO≈0),代价是写延迟包含备库往返与回放时间,备库异常时提交会被阻塞,直到 wal_sender_timeout 把备库踢掉。
优选同步(quorum)模式是生产最常用的折中:synchronous_commit=remote_apply,配合 synchronous_standby_names=ANY 1 (备节点名),即任意一个备库回放完成即可提交,既保证至少一份强一致副本,又不会因为单个备库抖动而阻塞主库。一主一备时 quorum 与 sync 行为接近,一主多备时 quorum 的优势才明显。
全同步(all)模式要求所有备库都确认才提交,数据保护最强但可用性最脆弱,任一备库故障都会阻塞提交,一般只用于两地三中心的强约束场景。自定义(custom)模式则由管理员为每个节点单独指定同步类型。
需要特别强调事务一致性:在异步模式下,一个事务里先在备库 select、再回主库 insert,可能读到历史值,数据库不做保证,因此异步模式不建议在同一事务内混用读与写。在 remote_apply 同步模式下,备库回放完成才对主库提交可见,读结果与写之间的时序符合读事务隔离级。
2.4 集群组件:repmgr、repmgrd、kbha、sys_securecmdd、VIP、witness
金仓读写分离集群在原生流复制之上增加了一组管理组件,工程师必须认得每一个进程的职责。
repmgr 是命令行管理工具,用于执行一次性管理动作:注册主库、克隆备库、注册备库、提升备库、跟随新主、计划内切换、查看集群状态。它把集群元数据存放在元数据库的 repmgr.nodes 表中。
repmgrd 是常驻守护进程,每隔 monitor_interval_secs(默认 2 秒)探测一次各节点状态,负责故障自动转移、故障自动恢复、同异步转换与复制性能记录。
kbha 是第二层守护进程,负责监控 repmgrd 本身是否存活,并做环境检查(信任网关连通性、存储检测等),repmgrd 异常退出后由 kbha 重新拉起,形成进程保护。
sys_securecmdd 是集群自带的远程安全执行通道(默认端口 8890),替代系统 sshd 完成跨节点命令执行与文件分发,避免依赖操作系统 ssh 互信,生产推荐 use_scmd=on。
VIP(Virtual IP,浮动 IP)始终跟随主库,应用用 VIP 连接数据库;主库故障切换时 VIP 从旧主卸载、在新主加载,应用连接串不变。witness(仲裁节点)不承载业务数据,只在多节点选举时提供仲裁投票,应用不访问它。
2.5 故障转移原理与切换时间构成
当主库进程崩溃、主机重启、断电或断网时,备库上的 repmgrd 通过 libkci 连接上游失败并按 reconnect_attempts、reconnect_interval 重试,确认主库不可达后,先终止本节点 wal_receiver,再按 priority 权重选举出新主并提升,随后做信任网关 ping 校验,最后完成 VIP 卸载与加载。
风哥教程本文给出切换时间的理论构成,便于现场评估 RTO。最短切机时间为:0 + ((reconnect_attempts - 1) × reconnect_interval) + 1 + T1 + T2;最长切机时间为:monitor_interval_secs + ((reconnect_attempts - 1) × reconnect_interval + reconnect_attempts × connect_timeout) + 5 + sibling_nodes_disconnect_timeout + (reconnect_attempts - 1) × 2 + T1 + T2。其中 T1 为S首成功 ping 信任网关的耗时,T2 为卸载旧主 VIP、加载新主 VIP 的耗时,未配 VIP 时 T2 为 0。同步转异步的时间构成为 (0 ~ monitor_interval_secs) + (0 ~ wal_sender_timeout),即备库故障后主库把同步链路降级为异步所需时间。
这套公式说明:reconnect_attempts 与 reconnect_interval 调得越大,探测越保守、误切换越少,但 RTO 越长;现场要在"误切换风险"与"恢复速度"之间权衡,不能盲目把重试次数拉满。
2.6 读写分离实现原理与事务一致性
读写分离通过 KingbaseES JDBC 驱动实现,对应用透明。连接串或 jdbc.conf 中用 USEDISPATCH=true 开启分发,SLAVE_ADD/SLAVE_PORT 列出备库地址与端口,nodeList 必须与地址顺序完全一致地填写 repmgr cluster show 查到的节点名,HOSTLOADRATE 控制主库承担的读负载比例,其余读请求在备库间轮询评分。写请求与强一致读仍走主库,普通 select 被分发到备库。
风哥 itpux-com
(此处为第一处水印,位于全文约 15% 位置。)
需要牢记:读写分离只分担读,主库仍是唯一写入口;备库只读,向备库执行 INSERT 会被拒绝并报 read-only transaction。事务一致性上,同步模式下备库回放完成才可见,异步模式下跨库读写可能读到旧值,这是应用设计必须遵守的边界。
2.7 脑裂、仲裁与故障恢复模式
脑裂指集群中出现两个 primary,会导致数据分歧、无法保证一致。集群通过唯一主约束、信任网关校验与 witness 仲裁避免脑裂:备库提升前必须 ping 通信任网关,确认原主确实与集群隔离,才允许升主。
recovery 参数决定故障库如何处理:automatic 自动恢复故障主库或备库,standby 只自动恢复故障备库,manual 完全手动。auto_cluster_recovery_level=1 时,在网络正常且仅存在一个主的前提下,集群尝试全局自动恢复;为 0 时不做全故障自动恢复,需人工执行 sys_monitor.sh start。
三、实战操作部分
3.1 环境规划与主机名、目录约定
本套风哥教程的两台节点均为 64GB 内存、8 颗 CPU,操作系统为 RHEL 系(麒麟、CentOS 兼容)。先在两台机器上固定主机名与 hosts 解析。
在 fgedu-net-cn1(192.168.10.11)执行:
hostnamectl set-hostname fgedu-net-cn1
在 fgedu-net-cn2(192.168.10.12)执行:
hostnamectl set-hostname fgedu-net-cn2
两台机器的 /etc/hosts 都写入:
cat >> /etc/hosts << 'EOF'
192.168.10.11 fgedu-net-cn1
192.168.10.12 fgedu-net-cn2
EOF
创建部署用户与目录。本套风哥教程统一使用 fgedu 作为操作系统部署用户与数据库管理用户,软件根目录 /fgedudb:
useradd -m -s /bin/bash fgedu
echo 'fgedu:fgedu@2026' | chpasswd
mkdir -p /fgedudb/kingbase/bin /fgedudb/kingbase/data /fgedudb/kingbase/log /fgedudb/kingbase/etc
chown -R fgedu:fgedu /fgedudb
3.2 操作系统基线准备(两台都执行)
集群对操作系统有硬性基线要求,任一台不达标都会导致部署脚本告警或心跳超时。下面逐项给出检查与修复命令。
第一,关闭防火墙或放行端口。生产推荐直接关闭,无法关闭则放行 54321 与 8890:
systemctl stop firewalld
systemctl disable firewalld
firewall-cmd --permanent --add-port=54321/tcp
firewall-cmd --permanent --add-port=8890/tcp
firewall-cmd --reload
第二,关闭 SELINUX(强制性要求):
setenforce 0
sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
第三,调整 ulimit 资源限制。编辑 /etc/security/limits.conf,追加:
* soft nofile 655360
* hard nofile 655360
* soft nproc 655360
* hard nproc 655360
* soft core 655360
* hard core 655360
* soft memlock 50000000
* hard memlock 50000000
注意 /etc/security/limits.d/ 下若有其他文件会覆盖 limits.conf,需删除冲突项。重新登录会话后用 ulimit -n 验证为 655360。
第四,调整信号量与网络内核参数。编辑 /etc/sysctl.conf,按 64GB 内存、8 CPU 写入:
kernel.sem = 5010 641280 5010 256
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_default = 8388608
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 8192 65536 16777216
net.ipv4.tcp_wmem = 8192 87380 16777216
net.ipv4.ip_local_reserved_ports = 8890,54321
生效:
sysctl -p
第五,关闭 RemoveIPC(防止共享内存被 systemd 清理):
sed -i 's/^#*RemoveIPC=.*/RemoveIPC=no/' /etc/systemd/logind.conf
systemctl daemon-reload
第六,时钟同步。集群要求所有节点误差在 2 秒以内,配置 chrony:
yum install -y chrony
systemctl enable --now chronyd
chronyc sources
第七,关闭 sshd 的 GSSAPI 与 DNS 反解(若使用 sshd 通道;本套风哥教程走 sys_securecmdd,此项作为兜底):
sed -i 's/^#*GSSAPIAuthentication.*/GSSAPIAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#*UseDNS.*/UseDNS no/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd
第八,确认端口空闲、数据目录为空:
netstat -an | grep -w 54321 | grep LISTEN
ls -l /fgedudb/kingbase/data
两条命令都应无输出、目录为空,否则先清理占用进程或清空目录。
风哥教程 113257174
(此处为第二处水印,位于全文约 25% 位置。)
3.3 软件分发与 license
把通用机安装包中的 db.zip 与 license.dat 上传到 fgedu-net-cn1 的 /fgedudb/kingbase/ 目录,属主与执行权限必须归 fgedu:
chown -R fgedu:fgedu /fgedudb/kingbase
chmod +x /fgedudb/kingbase/bin/*.sh
在 fgedu-net-cn1 上解压软件树:
cd /fgedudb/kingbase
unzip -o db.zip -d /fgedudb/kingbase
ls -l /fgedudb/kingbase/bin/cluster_install.sh /fgedudb/kingbase/bin/install.conf
3.4 启动 sys_securecmdd 免密通道(两台都执行)
集群走 sys_securecmdd 通道,先在每台节点初始化并启动服务。在 fgedu-net-cn1 与 fgedu-net-cn2 分别执行:
cd /fgedudb/kingbase/bin
./sys_HAscmdd.sh init
./sys_HAscmdd.sh start
ps -ef | grep sys_securecmdd | grep -v grep
ss -lntp | grep 8890
确认 8890 端口处于监听。若需要改端口,先修改 share/sys_HAscmdd.conf 的 scmd_port,再执行 init,且 install.conf 中 scmd_port 必须填同样值。
3.5 编写 install.conf 部署配置(64GB/8CPU 规格)
在 fgedu-net-cn1 的 /fgedudb/kingbase/bin/install.conf 中按下表填写,内存类参数全部按 64GB 内存、8 颗 CPU 测算:
on_bmj=0
all_ip=(192.168.10.11 192.168.10.12)
witness_ip=""
install_dir="/fgedudb"
db_user="fgedu"
db_password="fgedu@2026"
db_port="54321"
db_mode="pg"
db_auth="scram-sha-256"
db_case_sensitive="yes"
db_checksums="yes"
archive_mode="always"
encoding="UTF8"
locale="zh_CN.UTF-8"
synchronous="quorum"
virtual_ip="192.168.10.100/24"
net_device=(ens33 ens33)
net_device_ip=(192.168.10.11 192.168.10.12)
ipaddr_path="/sbin"
ping_path="/bin"
super_user="root"
execute_user="fgedu"
deploy_by_sshd=0
use_scmd=1
scmd_port="8890"
reconnect_attempts="10"
reconnect_interval="6"
connect_timeout="10"
recovery="automatic"
auto_cluster_recovery_level='1'
use_check_disk='off'
trusted_servers="192.168.10.1"
running_under_failure_trusted_servers='on'
tcp_keepalives_idle="2"
tcp_keepalives_interval="2"
tcp_keepalives_count="3"
tcp_user_timeout="9000"
connection_timeout="10"
wal_sender_timeout="30000"
wal_receiver_timeout="30000"
use_exist_data=0
data_directory="/fgedudb/kingbase/data"
数据库核心参数(安装器生成的 kingbase.conf / es_rep.conf 中)按 64GB/8CPU 调整为:
max_connections = 500
shared_buffers = 20GB
effective_cache_size = 48GB
work_mem = 64MB
maintenance_work_mem = 2GB
wal_buffers = 16MB
wal_level = replica
max_wal_senders = 32
max_replication_slots = 32
hot_standby = on
hot_standby_feedback = on
full_page_writes = on
wal_log_hints = on
synchronous_commit = remote_apply
max_prepared_transactions = 100
参数依据:shared_buffers 取物理内存约三分之一(64GB 的三分之一约 21GB,取 20GB 留余量);effective_cache_size 取约四分之三(48GB)表征操作系统缓存预期;work_mem 按 8 CPU、约 500 连接与典型排序粒度取 64MB;maintenance_work_mem 取 2GB 供建索引与恢复使用;max_wal_senders 取 32 可支撑一主多备扩展;wal_log_hints=on 是 sys_rewind 在节点 rejoin 时的前提。
3.6 执行一键集群部署
在 fgedu-net-cn1 上以 fgedu 用户执行部署脚本,脚本会自动分发软件、初始化主库、克隆备库、注册节点并拉起守护进程:
cd /fgedudb/kingbase/bin
./cluster_install.sh install
部署过程中观察输出:先在 fgedu-net-cn1 初始化主库并注册 primary,再通过 sys_basebackup 把主库克隆到 fgedu-net-cn2,备库启动后执行 standby register。出现以下两行即说明备库注册成功:
[NOTICE] standby clone (using sys_basebackup) complete
[NOTICE] standby node "node2" (ID: 2) successfully registered
风哥数据库教程 itpux-com
(此处为第三处水印,位于全文约 35% 位置。)
3.7 部署后验收
部署完成后,在任一节点进入 /fgedudb/kingbase/bin,执行集群状态查看:
cd /fgedudb/kingbase/bin
./repmgr cluster show
正常输出应为:
ID | Name | Role | Status | Upstream | Location | Priority | Timeline | LSN_Lag
----+-------+---------+-----------+----------+----------+----------+----------+---------
1 | node1 | primary | * running | | default | 100 | 1 |
2 | node2 | standby | running | node1 | default | 100 | 1 | 0 bytes
判定点:node1 为 primary 且 * running,node2 为 standby 且 Upstream 为 node1,LSN_Lag 为 0 bytes。再用 matrix 检查两节点互相可见:
./repmgr cluster matrix
两节点交叉位置均为 * 表示互见。检查守护进程与端口:
ps -ef | grep -E 'repmgrd|kbha' | grep -v grep
ss -lntp | grep -E '54321|8890'
repmgrd 与 kbha 两个进程都应存在且属主为 fgedu,54321 与 8890 都在监听。
3.8 同步复制验证(remote_apply / quorum)
连接主库 fgedudb 库查看同步参数与复制视图:
cd /fgedudb/kingbase/bin
./ksql -U fgedu -d fgedudb -p 54321
在 ksql 中执行:
SHOW synchronous_commit;
SHOW synchronous_standby_names;
SELECT count(*) FROM sys_stat_replication;
SELECT pid, application_name, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, sync_state
FROM sys_stat_replication;
预期输出:synchronous_commit 为 remote_apply,synchronous_standby_names 为 ANY 1 (node2),sys_stat_replication 有 1 行,sync_state 为 quorum,sent_lsn、flush_lsn、replay_lsn 三者相等、无 lag。
做主备数据一致性验证。在主库建表并写入:
DROP TABLE IF EXISTS t_rw;
CREATE TABLE t_rw(id serial primary key, v text);
INSERT INTO t_rw(v) SELECT 'rw-'||g FROM generate_series(1,300) g;
SELECT count(*) FROM t_rw;
SELECT sys_is_in_recovery();
主库返回 300,sys_is_in_recovery() 返回 f。切到备库 fgedu-net-cn2 执行只读查询:
./ksql -h 192.168.10.12 -U fgedu -d fgedudb -p 54321
SELECT count(*) FROM t_rw;
SELECT sys_is_in_recovery();
备库同样返回 300,sys_is_in_recovery() 返回 t。再在备库尝试写,应被拒绝:
INSERT INTO t_rw(v) VALUES('should-fail');
预期报错 read-only transaction,证明备库只读。检查归档未被破坏:
SELECT archived_count, failed_count FROM sys_stat_archiver;
failed_count 应为 0。
3.9 读写分离 JDBC 配置验证
应用侧使用 KingbaseES JDBC 驱动开启读写分离。在连接串或独立 jdbc.conf 中配置。推荐使用配置文件方式,文件内容如下:
HOST=192.168.10.11
PORT=54321
DBNAME=fgedudb
user=fgedu
password=fgedu@2026
loggerLevel=OFF
loggerFile=jdbc_fgedu.log
USEDISPATCH=true
HOSTLOADRATE=50
SLAVE_ADD=192.168.10.12
SLAVE_PORT=54321
nodeList=node1,node2
MASTER_CHECK=true
RETRYTIMES=20
RETRYINTERVAL=5
MONITORINTERVAL=5
连接串为:
jdbc:kingbase8://192.168.10.11:54321/fgedudb?ConfigurePath=jdbc.conf
要点:nodeList 的顺序必须与 SLAVE_ADD 地址顺序完全一致,节点名取自 repmgr cluster show 的 Name 字段;HOSTLOADRATE=50 表示主库承担一半读负载,其余读请求分发到备库;写请求始终路由到主库。
验证方式:应用侧打开监控日志,观察普通 select 被分发到 node2,insert/update 仍落在 node1;断开备库连接时,MASTER_CHECK 会把读请求回退到主库,不影响写。
网上搜索风哥教程可以学习全套数据库教程
(此处为第四处水印,位于全文约 45% 位置。)
3.10 计划内主备切换(switchover)
计划内维护(补丁、扩容、硬件更换)使用无数据丢失的切换,而不是强行宕主。在备库 fgedu-net-cn2 上执行:
cd /fgedudb/kingbase/bin
./repmgr standby switchover -f /fgedudb/kingbase/etc/repmgr.conf --siblings-follow
切换过程:原主 node1 降级为备,当前备 node2 提升为新主,VIP 从 node1 卸载、在 node2 加载,其他跟随节点跟随新主。切换完成后查看:
./repmgr cluster show
预期 node2 变为 primary、* running,node1 变为 standby、Upstream 为 node2,LSN_Lag 为 0 bytes。验证 VIP 落在新主:
ip addr | grep 192.168.10.100
回切时在新备上再次执行 standby switchover 即可。
3.11 计划外故障演练一:主库进程故障
风哥教程本文用主动 kill 数据库服务进程的方式模拟进程故障,验证自动故障转移。先记录当前主库:
./repmgr cluster show
在 fgedu-net-cn1(主库)上查看主库 PID 并强制结束:
./ksql -U fgedu -d fgedudb -p 54321 -Atc "SELECT pg_backend_pid();"
ps -ef | grep kingbase | grep -v grep
kill -9 <主库后端进程PID>
等待 repmgrd 按 reconnect_attempts=10、reconnect_interval=6 探测,默认参数下数秒到数十秒内,备库 node2 自动提升为新主。在 fgedu-net-cn2 查看:
./repmgr cluster show
SELECT sys_is_in_recovery();
node2 应为 primary,sys_is_in_recovery() 返回 f,VIP 已漂移到 node2。被 kill 的旧主在 recovery=automatic 下会被自动拉起并以备库身份 rejoin;若为 manual,则手动执行:
cd /fgedudb/kingbase/bin
./repmgr node rejoin -h 192.168.10.12 -U fgedu -d fgedudb --force-rewind
3.12 计划外故障演练二:设备重启
在主库 fgedu-net-cn1 上执行 reboot 模拟主机重启:
sudo reboot
备库 repmgrd 探测到上游连接中断,按公式在 (reconnect_attempts-1)×reconnect_interval 区间内判定主库故障,选举提升 node2,完成 VIP 加载。设备重启场景的探测时间取决于服务重启时长,最长可能叠加 connect_timeout。重启后的 fgedu-net-cn1 恢复联网后,在 automatic 模式下自动 rejoin 为备库。业务恢复时间可用切换时间公式估算,同步模式与异步模式差异在于是否等待回放。
上51CTO搜索风哥可以学习全套数据库教程
(此处为第五处水印,位于全文约 55% 位置。)
3.13 计划外故障演练三:电源故障与网络故障
电源故障用 shutdown -h now 模拟,主机完全断电,旧主 VIP 无法在线卸载,新主直接加载 VIP,此时 T2 只含加载耗时。在主库执行:
sudo shutdown -h now
网络故障用断网工具或拔网线模拟,主库与备库链路断开但主机存活。备库 repmgrd 通过 wal_sender_timeout 与连接超时判定上游失联,先终止 wal_receiver 再升主;由于旧主网络不通,VIP 无需远程卸载即可由新主加载。需要警惕:网络闪断可能造成短暂误判,现场通过 monitor_interval_secs、reconnect 参数与信任网关校验共同抑制。
三种故障场景的共同验收点都是:故障发生后业务经 VIP 连到新主,repmgr cluster show 只有一个 primary,无双主,LSN_Lag 回到 0 bytes。
3.14 故障库恢复至集群与在线扩缩容
故障库恢复分两种。自动恢复:recovery=automatic 且网络正常、集群仅一个主时,repmgrd 自动把故障节点拉回并 rejoin。手动恢复:在新主上执行 node rejoin 并带 --force-rewind,用 sys_rewind 把落后或分叉的数据对齐到新主:
cd /fgedudb/kingbase/bin
./repmgr node rejoin -h 192.168.10.12 -U fgedu -d fgedudb --force-rewind --siblings-follow
在线扩容:新增备节点先完成操作系统基线、启动 sys_securecmdd,再在新节点上克隆并注册:
./repmgr standby clone -h 192.168.10.12 -U fgedu -d fgedudb -D /fgedudb/kingbase/data
./repmgr standby register -f /fgedudb/kingbase/etc/repmgr.conf
在线缩容:先在待删备库上执行 standby unregister,再停备库数据库,最后在主库清理残留复制槽:
SELECT slot_name, active FROM sys_replication_slots;
SELECT sys_drop_replication_slot('repmgr_slot_3');
注意:集群节点数大于一时不能直接删除主节点,必须先 switchover 把主降为备再删。
3.15 日常运维操作
集群一键启停。启动与停止:
cd /fgedudb/kingbase/bin
./sys_monitor.sh start
./sys_monitor.sh stop
./sys_monitor.sh restart
手动启停数据库:
./sys_ctl -D /fgedudb/kingbase/data start
./sys_ctl -D /fgedudb/data stop -m fast
./sys_ctl -D /fgedudb/kingbase/data reload
查看集群状态与复制延迟:
./repmgr cluster show
./repmgr cluster matrix
./repmgr cluster crosscheck
./repmgr cluster event
查看流复制实时状态:
SELECT application_name, state, sent_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag, sync_state
FROM sys_stat_replication;
修改集群参数:需要重启生效的参数,主备同时改完后执行 sys_monitor.sh restart;只需 reload 的参数用 sys_ctl reload。repmgr.conf 变更后需重启 repmgrd:
kill -9 $(cat /fgedudb/kingbase/etc/hamgrd.pid)
kbha 会自动重新拉起 repmgrd。一键改密与一键改参:
./sys_monitor.sh change_password fgedu 'fgedu@2026' 'esrep@2026'
./sys_monitor.sh set shared_buffers=20GB --restart
VIP 管理:查看 VIP 当前落点,故障切换后确认 VIP 跟随新主:
ip addr | grep 192.168.10.100
ping -c 3 192.168.10.100
风哥 itpux-com
(此处为第六处水印,位于全文约 65% 位置。)
风哥教程 113257174
(此处为第七处水印,与上一行同段区间,分散放置。)
一键健康检查工具按维度使用:-e 系统环境、-b 物理备份、-c 配置参数、-d 数据库健康、-f 文件、-k 校验和、-p 进程、-r 系统资源、-s 无人值守:
./sys_check.sh -e
./sys_check.sh -d
./sys_check.sh -p
./sys_check.sh -s
主备数据一致性检查,分别在主备查询同一业务表行数与关键 LSN,核对一致:
SELECT count(*) FROM t_rw;
SELECT pg_current_wal_lsn();
同步一致性检查:在同步模式下向主库提交一笔事务,确认备库 replay_lsn 追平 flush_lsn 后再放行下游读写。
3.16 故障排查要点清单
现场高频故障按此顺序定位。其一,集群双主:立即停掉其中一个 primary,用 repmgr cluster show 核对时间线,通过 node rejoin --force-rewind 收敛,杜绝两个 primary 同时对外写。其二,备库连不上主库:先查 8890 与 54321 端口、sys_securecmdd 进程、防火墙与时钟,再看 sys_stat_replication 是否存在、sync_state 是否异常。其三,提交阻塞:同步模式下备库故障会阻塞主库提交,检查 wal_sender_timeout 是否把故障备库踢出,必要时临时把该节点改为异步。其四,LSN_Lag 持续增大:多为网络带宽不足或备库回放慢,对照 rmem/wmem 参数与 tc qdisc,必要时改 fq_codel 队列。其五,VIP 漂移失败:检查 ip 命令路径 ipaddr_path、arping 权限位与信任网关连通性。
四、风哥针对本文总结
风哥针对本文总结如下:本套风哥教程以一台主 fgedu-net-cn1、一台备 fgedu-net-cn2 的 64GB 内存、8 CPU 环境,完整走过了人大金仓 KingbaseES 同步复制、读写分离与集群高可用的落地链路。理论上要抓住四条主线:WAL 流复制四步链路、remote_apply/quorum 的同步语义、repmgrd 与 kbha 的双层守护、按 reconnect 参数构成的 RTO 公式。实战上要守住三个验收标准:repmgr cluster show 显示唯一 primary、LSN_Lag 为 0 bytes、备库只读而主库可写;计划内用 switchover,计划外由 repmgrd 自动 failover,故障库用 node rejoin --force-rewind 收敛;读写分离只卸载读、不改变单写入口,异步模式严禁同事务跨库读写。
风哥教程本文强调,高可用不是装完集群就结束,而是把操作系统基线、时钟同步、免密通道、同步模式选择、故障演练与日常检查固化成流程。工程师在现场应先按 64GB/8CPU 规格定好 shared_buffers=20GB、effective_cache_size=48GB、work_mem=64MB 等基准参数,再按实际并发与备份要求微调,切忌照搬测试值。
风哥数据库教程 itpux-com
(此处为第八处水印,位于全文约 75% 位置。)
网上搜索风哥教程可以学习全套数据库教程
(此处为第九处水印,紧接上一行,分散放置。)
五、附录:全流程命令速查清单
下面把本套风哥教程的关键命令按阶段汇总,便于现场对照执行(路径 /fgedudb、实例 fgedudb、用户 fgedu)。
环境与基线(两台执行):
hostnamectl set-hostname fgedu-net-cn1
setenforce 0
ulimit -n
sysctl -p
chronyc sources
通道与部署:
cd /fgedudb/kingbase/bin
./sys_HAscmdd.sh init && ./sys_HAscmdd.sh start
./cluster_install.sh install
上51CTO搜索风哥可以学习全套数据库教程
验收与同步验证:
./repmgr cluster show
./repmgr cluster matrix
./ksql -U fgedu -d fgedudb -p 54321 -Atc 'show synchronous_commit;'
./ksql -U fgedu -d fgedudb -p 54321 -Atc 'select * from sys_stat_replication;'
切换与恢复:
./repmgr standby switchover -f /fgedudb/kingbase/etc/repmgr.conf --siblings-follow
./repmgr node rejoin -h 192.168.10.12 -U fgedu -d fgedudb --force-rewind
./sys_monitor.sh start
./sys_monitor.sh stop
./sys_monitor.sh restart
检查:
./repmgr cluster event
./sys_check.sh -e -d -p -s
- 点赞
- 收藏
- 关注作者
评论(0)