openGauss从零部署 oGRAC 双节点：多写一致性与 TPCC 线性扩展实测

原创已于 2026-09-11 15:42:03 修改 · 230 阅读

本内容遵循CC 4.0 BY-SA版权协议

于 2026-09-11 15:41:03 首次发布

1. oGRAC简介

oGRAC 是 openGauss 的多主架构实现。多个数据库实例由集群统一管理，对外提供实时一致的读写能力。与传统主备架构不同，本实验中的 Node0 和 Node1 都可以承载写事务。因此，验证重点不只是“两个实例能否启动”，还包括三件事：

任一节点执行 DDL 或 DML 后，另一节点能否立即观察到结果；
两个节点并发修改同一行时，锁和事务语义是否正确；
业务连接分散到两个节点后，吞吐能否相对单节点增长。

oGRAC 架构

oGRAC 将多个可写的 openGauss 数据库实例组织为一个统一集群。业务通过兼容 JDBC 的连接入口访问集群，连接可以分布到多个实例；实例之间通过集群通信和共享存储保持全局一致。CMS 负责集群资源编排与状态管理，DSS 提供共享存储访问。下面的通用架构图展示逻辑关系，实际部署的组件数量和网络划分可按硬件规模调整。

本次不执行 RTO 故障恢复任务。该任务需要在较高、稳定的负载下触发故障，现有 DCS 虚拟机性能条件不满足任务书要求，强行测试得到的数字没有可比性。

2. 实验环境

项目	Node0	Node1
主机名	`openGauss109`	`dcs113`
运行形态	KVM 虚拟机	KVM 虚拟机
操作系统	openEuler 22.03 LTS，aarch64	openEuler 22.03 LTS，aarch64
内核	`5.10.0-60.18.0.50.oe2203.aarch64`	`5.10.0-60.18.0.50.oe2203.aarch64`
处理器	Kunpeng-920，32 vCPU，2400 MHz	Kunpeng-920，32 vCPU，2400 MHz
NUMA	1 节点，CPU 0-31	1 节点，CPU 0-31
内存	约 29 GiB	约 29 GiB
Swap	15 GiB	15 GiB
本地磁盘	系统盘 256 GB，`/data` 500 GB	系统盘 256 GB，`/data` 500 GB
oGRAC 软件包	`oGRAC-1.0.0.B001-openEuler22.03-aarch64.tgz`	由安装脚本分发
安装目录	`/opt/ograc`	`/opt/ograc`
数据目录	`/mnt/dbdata`	`/mnt/dbdata`
数据库用户	`ograc`	`ograc`
数据库端口	`1611`	`1611`

共享存储在两个节点上的 WWN 完全一致，设备用途如下：

设备	容量	用途
`/dev/dss-disk1`	2 TB	DSS 数据卷
`/dev/dss-disk2`	4 TB	Redo 卷
`/dev/dss-disk3`	2 TB	归档卷
`/dev/gcc-disk`	5 GB	CMS 仲裁盘（GCC）

客户端通过两级跳板进入 DCS 内网。BenchmarkSQL 5.0 部署在第二级跳板环境的 Docker 容器内，通过 openGauss JDBC 驱动 opengauss-jdbc-7.0.0-RC3.jar 访问数据库。压测客户端宿主机为 Huawei TaiShan 200 Model 2280，操作系统为 openEuler 22.03 LTS-SP4，内核为 5.10.0-216.0.0.115.oe2203sp4.aarch64；配备 2 路 Kunpeng-920、128 CPU、4 个 NUMA 节点和约 1.0 TiB 内存。Java 环境为 OpenJDK 1.8.0_462（BiSheng VM）。客户端资源显著高于两台 DCS 虚拟机，因此本轮测试的主要资源压力位于数据库及共享存储侧。

3 部署前检查

3.1 核对主机与共享盘

分别在两个节点执行以下检查，确认架构、CPU、内存和设备均符合预期：

uname -m
lscpu | grep -E 'CPU\(s\)|Model name'
free -h
lsblk -o NAME,SIZE,TYPE
ls -l /dev/dss-disk* /dev/gcc-disk

共享盘必须按 WWN 映射，不能只根据容易变化的 /dev/sdX 名称判断。部署前还要确认设备没有旧文件系统、挂载或残留的 SCSI-3 PR 注册与预留。由于格式化会破坏盘上数据，这一步必须先明确 LUN 确实为本次实验专用空盘。

3.2 补齐依赖

安装脚本调用了 numactl，但基础镜像没有预装。两个节点均补装该依赖：

dnf install -y numactl

缺少它时安装过程会出现 NUMA 相关警告。本次警告没有直接中止安装，但不应忽略，否则 CPU/内存亲和设置可能没有按预期生效。

4 双节点安装

安装包已放在 Node0 的 /data 目录。本次使用官方 common-tools 中的双节点脚本 install-two-node.sh。下面是脱敏后的实际参数形式：

bash /data/install-two-node.sh \
  --cms-ip node0-ip \
  --cms-ip node1-ip \
  --vg1 /dev/dss-disk1 \
  --vg2 /dev/dss-disk2 \
  --vg3 /dev/dss-disk3 \
  --gcc-home /dev/gcc-disk \
  --package-path /data/oGRAC-1.0.0.B001-openEuler22.03-aarch64.tgz \
  --node1-root-password '<NODE1_ROOT_PASSWORD>' \
  --password '<OGRAC_PASSWORD>' \
  --no-ask-extra

本次采用的主要安装参数为：

deploy_mode=dss
db_type=1
auto_tune=1
redo_num=6
redo_size=5G
cms_port=14587
dss_port=1811
ograc_port=1611
interconnect_port=1601,1602
ograc_home=/opt/ograc
data_root=/mnt/dbdata

脚本完成软件解压、配置生成、软件包向 Node1 分发、共享卷初始化、CMS/DSS/数据库部署和建库。Node0 首次建库约耗时 6 分钟。涉及共享盘初始化和建库的阶段不要因终端暂时没有新输出而强制中断。

4.1 状态验证

数据库相关操作切换到 ograc 用户：

su -s /bin/bash ograc
cms stat -res db
ogsql / as sysdba -q

在两个节点执行：

SELECT NAME, STATUS, OPEN_STATUS FROM DV_DATABASE;

两个实例均返回 OGRAC / OPEN / READ WRITE，CMS 中 Node0、Node1 的 db 资源均为 ONLINE。

4.2 日常启停顺序

# 停止数据库，再停止存储服务

cms res -stop db
cms res -stop dss

# 启动时先 DSS，等待在线后再启动数据库

cms res -start dss
cms stat -res dss
cms res -start db
cms stat -res db

4.3 RBPS

RBPS的作用是RTO加速，oGRAC的数据一致性是通过DRC分布式资源目录，DLS分布式锁服务、DCS分布式缓存服务以及分布式MVCC这些来保证的，在需要RTO加速时开启这一功能（还需要打开USE_RBP参数）:

/opt/ograc/ograc/server/bin/rbps_ctl start \
  -c /opt/ograc/cms/service/cfg/rbps.conf

5 测试一：验证多写一致性

以下测试在两个节点分别打开 ogsql / as sysdba -q 会话执行。

5.1 DDL 全局同步

两个会话先开启自动提交：

SET AUTOCOMMIT=ON;
SHOW AUTOCOMMIT;

Node0 创建表：

DROP TABLE IF EXISTS test_mulNode;
CREATE TABLE test_mulNode(c1 INT, c2 VARCHAR(32), c3 INT);

Node1 随即创建同名表，返回：

OG-01301, SYS.TEST_MULNODE already exists

Node0 删除该表后，Node1 再次创建成功，并能完成插入和查询：

CREATE TABLE test_mulNode(c1 INT, c2 VARCHAR(32), c3 INT);
INSERT INTO test_mulNode VALUES(1, 'abc', 11);
SELECT * FROM test_mulNode;

查询结果为 (1, abc, 11)。这说明 DDL 元数据在两个节点之间保持全局一致。

5.2 DML 跨节点可见

Node0 建表并插入三行：

DROP TABLE IF EXISTS test_mulNode;
CREATE TABLE test_mulNode(c1 INT, c2 VARCHAR(32), c3 INT);
INSERT INTO test_mulNode VALUES
  (1, 'aaa', 11), (2, 'bbb', 22), (3, 'ccc', 33);

Node1 更新 Node0 写入的数据：

UPDATE test_mulNode SET c3=77 WHERE c1=1;

Node0 立即查询：

SELECT * FROM test_mulNode WHERE c1=1;

返回 (1, aaa, 77)。两个节点都能读写同一份数据，已提交变更可以跨节点立即观察。

5.3 跨节点行锁

两个会话关闭自动提交：

SET AUTOCOMMIT=OFF;

Node0 准备数据并提交，然后更新 c1=4，暂不提交：

DROP TABLE IF EXISTS test_mulNode;
CREATE TABLE test_mulNode(c1 INT, c2 VARCHAR(32), c3 INT);
INSERT INTO test_mulNode VALUES
  (2, 'bbb', 22), (3, 'ccc', 33), (4, 'ddd', 44);
COMMIT;


UPDATE test_mulNode SET c3=55WHERE c1=4;

Node1 更新同一行：

UPDATE test_mulNode SET c3=66 WHERE c1=4;

Node1 会话实测阻塞至少 15 秒。Node0 执行 COMMIT 后，Node1 的 UPDATE 立即返回 1 rows affected。Node1 再提交，Node0 查询到最终值 (4, ddd, 66)。

这个过程验证了锁不局限于单个实例。Node0 持有的行锁能阻止 Node1 修改相同行，锁释放后等待事务继续执行，最终提交结果在两端一致。

6 测试二：TPCC 线性扩展测试

6.1 准备测试用户与远程访问

以下口令仅为占位符，应按环境密码策略设置：

CREATE USER TPCC IDENTIFIEDBY'<TPCC_PASSWORD>';
GRANT CREATE SESSION TO TPCC;
GRANT CREATE TABLE TO TPCC;
GRANT DBA TO TPCC;
GRANT INHERIT PRIVILEGES ON USERS YSTO TPCC;

ALTER SYSTEM SET ENABLE_SYSDBA_REMOTE_LOGIN = TRUE;
ALTER SYSTEM SET ENABLE_SYS_REMOTE_LOGIN = TRUE;
ALTER SYSTEM ADD HBA ENTRY 'host * 0.0.0.0/0';
ALTER SYSTEM RELOAD HBA CONFIG;

任务书要求两节点均执行参数设置。本次随后按“DB → DSS 停止、DSS → DB 启动”的顺序重启集群，并确认两个数据库资源恢复为 ONLINE。

示例 HBA 放开了 0.0.0.0/0，只适合隔离实验网。生产环境应缩小为应用网段，并结合防火墙控制来源。

6.2 BenchmarkSQL 配置与数据装载

配置中的公共参数如下：

db=postgres
driver=org.opengauss.Driver
user=TPCC
password=<TPCC_PASSWORD>
warehouses=200
loadWorkers=100
terminals=50
runTxnsPerTerminal=0
runMins=5
limitTxnsPerMin=0
terminalWarehouseFixed=true
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4

单节点连接串：

conn=jdbc:oGRAC://node0-ip:1611

双节点连接串：

conn=jdbc:oGRAC://node0-ip:1611,node1-ip:1611?autoBalance=roundrobin

数据只装载一次：

cd /home/workshop/benchmarksql/run
./runDatabaseBuild.sh props_ograc_21.og

200 仓、100 个装载线程完成后，数据库校验结果为：

WAREHOUSE_COUNT = 200
ITEM_COUNT      = 100000
CONFIG_COUNT    = 4

6.3 50 终端补充测试与稳态结果

本轮把并发固定为 50 个终端，在未观察到其他集群并行压测的独立测试窗口中，重新执行可直接比较的单节点和双节点测试。测试于 2026 年 9 月 8 日完成，流程如下：

单节点预热 3 分钟，正式运行 15 分钟；
冷却 2 分钟；
双节点预热 3 分钟，正式运行 15 分钟。

除连接串外，数据规模、终端数和事务权重完全一致。每个正式场景从 result.csv 中剔除前 3 分钟，按剩余 12 分钟计算稳态吞吐、逐分钟变异系数和延迟分位数。两台 DCS 同时以 5 秒间隔采集 vmstat -t 和 iostat -x -t，BenchmarkSQL 错误数均为 0。

场景	全程 tpmC	稳态 tpmC	分钟变异系数	New-Order p50/p95/p99	事务数	错误
单节点，50 终端	98,156.33	98,695.61	4.46%	16/31/42 ms	3,271,005	0
双节点，50 终端	166,586.06	168,816.90	1.76%	9/17/23 ms	5,552,254	0

按稳态口径计算双节点扩展结果：

scale = 168,816.90 / 98,695.61 = 1.7105（约 1.71 倍） uplift = (1.7105 - 1) × 100% = 71.05% efficiency = 168,816.90 / (2 × 98,695.61) = 85.52%

本轮双节点稳态吞吐较单节点提升 71.05%，两节点线性度为 85.52%。双节点 12 个完整稳态分钟的 tpmC 位于 164,353 至 174,527 之间，分钟变异系数仅 1.76%，低于单节点的 4.46%；New-Order p95 也从 31 ms 降至 17 ms。与共享存储同时承载其他集群负载时的测试相比，本轮吞吐和稳定性均明显改善，因此正文只采用本轮结果。

节点监控给出了可量化的资源边界：

场景	Node0 I/O wait	Node1 I/O wait	Node0 `sdb` util/队列	Node1 `sdb` util/队列
单节点 50 稳态	27.62%	0.00%	99.89% / 75.77	1.93% / 0.01
双节点 50 稳态	14.01%	11.22%	99.83% / 43.52	99.58% / 37.09

单节点负载集中在 Node0，其 sdb 接近持续满载；双节点运行时两侧 sdb 也接近满载，并伴随显著 I/O wait 和磁盘队列。当前测试仍触及本集群的磁盘能力上限，但在没有其他集群并行压测的窗口中，双节点逐分钟吞吐保持稳定。由此可见，共享存储上的外部争用会直接影响扩展测试的可重复性；性能对比必须记录存储占用窗口和节点级 I/O 指标。

DCS 虚机时钟在资源采集期间出现多次向后校时。分析时依据每节点连续 480 个样本和固定 5 秒间隔重建单调时间轴，再映射测试阶段，原始日志保持不变。正式容量报告仍应先排除存储饱和，再将预热提高到 10 分钟，按 单节点 → 双节点 → 双节点 → 单节点 的交叉顺序各运行至少三轮 30 分钟，并报告均值、标准差和置信区间。

7 踩坑记录

基础镜像缺少 numactl
安装前在两个节点补齐，避免 NUMA 绑定相关步骤失效。
CMS 启停是异步的
命令返回后继续用 cms stat 确认实际状态，不要只看命令退出码。
RBPS 未注册为 CMS 资源
本版本的 cms res -start rbps 返回资源不存在，需要显式指定配置执行 rbps_ctl start。
RBPS 配置路径不同
有效配置位于 /opt/ograc/cms/service/cfg/rbps.conf。
双节点连接不等于逐事务随机路由
JDBC 的 roundrobin 作用于连接选择。BenchmarkSQL 启动日志实际交替输出两个节点的 LoadBalanceResult，说明 50 个终端连接已分散到两个实例。