openGauss oGRAC 双节点上线：多写一致性与 TPCC 扩容实测

oGRAC 是 openGauss 的多主集群形态。Node 0 和 Node 1 都能承接写事务，验证重心落在三处：DDL/DML 跨节点可见性、并发改同一行时的锁语义、以及双节点吞吐能否相对单节点抬升。本次没有做 RTO 异常恢复，DCS 虚机负载条件不满足任务书要求，强行测出的数字没有可比性。

环境与共享存储

两台 KVM 虚机跑 openEuler 22.03 LTS aarch64，内核 5.10.0-60.18.0.50.oe2203.aarch64，各 32 vCPU（Kunpeng-920）、约 29 GiB 内存。管理地址 20.20.21.109 与 20.20.21.113，安装目录 /opt/ograc，数据目录 /mnt/dbdata，数据库端口 1611，数据库用户 ograc。软件包为 oGRAC-1.0.0.B001-openEuler22.03-aarch64.tgz，由安装脚本分发。

共享盘在两台机器上的 WWN 完全一致，用途划分：/dev/dss-disk1 2TB 作 DSS 数据卷，/dev/dss-disk2 4TB 作 Redo 卷，/dev/dss-disk3 2TB 作归档卷，/dev/gcc-disk 5GB 作 CMS 仲裁盘。

压测端跑在二级跳板的 Docker 里，用 opengauss-jdbc-7.0.0-RC3.jar 连库，宿主机是 TaiShan 200 Model 2280，openEuler 22.03 LTS-SP4，2 路 Kunpeng-920 共 128 CPU、4 NUMA、约 1.0 TiB 内存，OpenJDK 1.8.0_462（BiSheng VM）。客户端资源远高于两台 DCS 虚机，压力主要落在数据库和共享存储侧。

部署前先做两件事

第一，核对主机与共享盘。两台都执行：

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 是本次实验专用空盘。

第二，补依赖。安装脚本会调用 numactl，基础镜像没预装，两台都补：

dnf install -y numactl

缺它时部署会抛 NUMA 相关警告。本次警告没有直接中止部署，但不该忽略，否则 CPU/内存亲和设置可能没按预期生效。

双节点安装与状态确认

部署包放在 Node 0 的 /data，用官方 common-tools 里的双机脚本 install-two-node.sh。脱敏后的实际参数形式：

bash /data/install-two-node.sh \
  --cms-ip 20.20.21.109 \
  --cms-ip 20.20.21.113 \
  --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 '' \
  --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。脚本会做软件解压、配置生成、向 Node 1 分发、共享卷初始化、CMS/DSS/数据库上线和建库。Node 0 首次建库约 6 分钟，涉及共享盘初始化和建库的阶段别因为终端暂时没输出就强制中断。

验证状态切到 ograc 用户：

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

两台都执行 SELECT NAME, STATUS, OPEN_STATUS FROM DV_DATABASE; 两个实例都返回 OGRAC / OPEN / READ WRITE，CMS 里 Node 0、Node 1 的 db 资源均为 ONLINE。

日常启停顺序固定：停库先停存储支撑（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）。CMS 启停是异步的，命令返回后要用 cms stat 确认实际状态，别只看退出码。

RBPS 用于 RTO 加速，数据一致性靠 DRC 分布式资源目录、DLS 分布式锁、DCS 分布式缓存和分布式 MVCC 保证。本版本 RBPS 没注册成 CMS 资源，cms res -start rbps 会返回资源不存在，得显式执行：

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

注意配置路径是 /opt/ograc/cms/service/cfg/rbps.conf，不是别的目录。

验证一：多写一致性

两台各自开 og / as sysdba -q 会话。先开自动提交：SET AUTOCOMMIT=ON; SHOW AUTOCOMMIT;

DDL 全局同步：Node 0 建表 test_mulNode(c1 INT, c2 VARCHAR(32), c3 INT)，Node 1 立刻建同名表，返回 OG-01301, SYS.TEST_MULNODE already exists。Node 0 删表后 Node 1 再建成功，插入并查询返回 (1, abc, 11)。说明 DDL 元数据在两节点全局一致。

DML 跨节点可见：Node 0 建表插三行 (1,’aaa’,11),(2,’bbb’,22),(3,’ccc’,33)，Node 1 执行 UPDATE test_mulNode SET c3=77 WHERE c1=1，Node 0 立即查 c1=1 返回 (1, aaa, 77)。已提交改动跨节点立即可见。

跨节点行锁：两个会话 SET AUTOCOMMIT=OFF。Node 0 建表、插入 (2,’bbb’,22),(3,’ccc’,33),(4,’ddd’,44) 并 COMMIT，然后 UPDATE c3=55 WHERE c1=4 暂不提交。Node 1 更新同一行，实测阻塞至少 15 秒。Node 0 COMMIT 后，Node 1 的 UPDATE 立即返回 1 rows affected，Node 1 再提交，Node 0 查到最终值 (4, ddd, 66)。锁不局限在单实例，锁释放后等待事务继续，两端最终一致。

验证二：TPCC 扩容测试

先建压测用户并放开远程访问（口令仅为示例，按环境密码策略设置）：

CREATE USER TPCC IDENTIFIED BY '';
GRANT CREATE SESSION TO TPCC;
GRANT CREATE TABLE TO TPCC;
GRANT DBA TO TPCC;
GRANT INHERIT PRIVILEGES ON USER SYS TO 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，只适用于隔离实验网；生产环境应收窄到业务网段并配合防火墙控制来源。

BenchmarkSQL 公共参数：db=postgres、driver=org.opengauss.Driver、user=TPCC、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://20.20.21.109:1611；双节点 conn=jdbc:oGRAC://20.20.21.109:1611,20.20.21.113:1611?autoBalance=roundrobin。数据只装一次：cd /home/workshop/benchmark/run，./runDatabaseBuild.sh props_ograc_21.og。200 仓、100 装载线程跑完后校验：WAREHOUSE_COUNT=200、ITEM_COUNT=100000、CONFIG_COUNT=4。

50 终端补充验证在独立窗口做，避免其他集群并行压测干扰。链路：单机预热 3 分钟、正式 15 分钟；冷却 2 分钟；双机预热 3 分钟、正式 15 分钟。除连接串外，数据量、终端数和事务权重完全一致。每个正式场景从 result.csv 剔除前 3 分钟，按剩余 12 分钟算稳态吞吐、逐分钟变异系数和延迟分位数。两台 DCS 同时以 5 秒间隔采集 vmstat -t 和 iostat -x -t，BenchmarkSQL 错误数均为 0。

结果：单机全程 tpmC 98,156.33、稳态 98,695.61、分钟变异系数 4.46%、New-Order p50/p95/p99 16/31/42 ms、事务数 3,271,005、错误 0；双机全程 166,586.06、稳态 168,816.90、变异系数 1.76%、p50/p95/p99 9/17/23 ms、事务数 5,552,254、错误 0。

按稳态口径：scale = 168,816.90 / 98,695.61 = 1.7105（约 1.71 倍），uplift = 71.05%，efficiency = 168,816.90 / (2 × 98,695.61) = 85.52%。双机 12 个完整稳态分钟 tpmC 在 164,353 至 174,527 之间，变异系数 1.76%，低于单机的 4.46%，p95 从 31ms 降到 17ms。与共享存储同时承载其他集群负载时的测试相比，本轮吞吐和稳定性都明显更好，所以正文只采用本轮结果。

资源侧：单机 50 稳态时 Node 0 I/O wait 27.62%、Node 1 0.00%，Node 0 sdb util/队列 99.89%/75.77，Node 1 1.93%/0.01；双机稳态时 Node 0 I/O wait 14.01%、Node 1 11.22%，Node 0 sdb 99.83%/43.52，Node 1 99.58%/37.09。负载已摸到本集群磁盘上限，但在无其他集群并行压测的窗口里双机逐分钟吞吐平稳。共享存储上的外部争用会直接影响扩容验证的可重复性，性能对比务必记录存储占用窗口和机器级 I/O 指标。

DCS 虚机时钟在采集期间出现多次向后校时。分析时按每机连续 480 个样本和固定 5 秒间隔重建单调时间轴，再映射回测试时段，原始记录不动。正式容量报告建议先排除存储饱和，再把预热拉长到 10 分钟，按单机→双机→双机→单机交叉顺序各跑至少三轮 30 分钟，并报告均值、标准差和置信区间。

踩坑记录

基础镜像缺 numactl，部署前两机补齐，否则 NUMA 绑定相关流程可能失效。CMS 启停异步，命令返回后继续用 cms stat 确认实际状态。RBPS 未注册为 CMS 资源，cms res -start rbps 报资源不存在，需显式 rbps_ctl start，配置路径 /opt/ograc/cms/service/cfg/rbps.conf。双节点连接不等于逐事务随机路由，JDBC 的 roundrobin 作用于连接选择；BenchmarkSQL 启动日志会交替输出两个节点的 Load Balance Result，说明 50 个终端连接已分散到两个实例。