数据库教程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 是否一致。

流复制的物理过程分四步，这是风哥教程本文反复引用的链路：

1. 主库 WalWriter 进程把产生的 WAL 写入本地磁盘段文件；

2. 主库 walsender 进程读取新增 WAL，以数据流方式通过 TCP 发送给备库；

3. 备库 walreceiver 进程把收到的 WAL 写入本地 WAL 段文件；

4. 备库 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）执行：

```bash

hostnamectl set-hostname fgedu-net-cn1

```