oGRAC 单节点部署：CMS 启动失败与数据库异常退出的排查与修复

适用现象：执行cms server -start报invalid argument无法拉起；或 CMS 进程存活但集群不可用，运行日志持续输出can't establish an connection to 192.168.86.2；或ogracd进程异常退出。

根本原因：安装模板默认按双节点配置生成，单节点部署后残留项未完全收敛。残留存在于两个层面——cluster.ini文本配置层与GCC 二进制元数据中的NODE_COUNT。仅处理文本层将导致问题复发。

一、故障传导链

GCC 中 NODE_COUNT = 2（实际仅存在 node0） ↓ CMS 初始化 MES 时按 for i in 0..NODE_COUNT-1 遍历，访问到不存在的 instance 1 ↓ node def is invalid → MES profile 初始化失败 → CMS 进程退出 ↓ ogracd 无法连接 CMS 的 UDS socket，重试 5 次均失败 ↓ 触发 CMS_CLI ABORT 机制 → 数据库实例主动终止

需要建立的核心认知：数据库实例退出通常并非数据库自身故障，而是 CMS 异常的连带结果。因此无论表象如何，排查应从 CMS 入手。

二、状态查询

source~/.bashrc cmsstat-server# ① CMS 服务端状态cmsstat-resdb# ② 数据库资源状态cms gcc-exp/tmp/c.exp&&head-6/tmp/c.exp# ③ GCC 元数据grep-E"CLUSTER_SIZE|\[1\]"~/data/cfg/cluster.ini# ④ 文本层残留ls~/data/res_disable2>/dev/null# ⑤ 资源禁用标记

结果研判：

GCC 元数据研判

第 ③ 项为排查重点，其输出结构如下：

#GCC_HEAD# META_VER,NODE_COUNT,DATA_VER,CHECKSUM 0,2,6,0 ← 声明节点数为 2 #GCC_NODE# NODE_ID,NAME,IP,PORT 0,node0,127.0.0.1,14587 ← 实际仅定义 1 个节点

判定规则：NODE_COUNT取值必须与#GCC_NODE#段实际节点记录数一致。上例声明 2 个而实际 1 个，二者不一致将导致 CMS 无法启动。

此处存在三项易被忽略的特性：

• cms node -list输出正常并不足以排除故障。该命令仅读取节点列表，不校验头部计数字段，容易造成误判。
• cms node -del不会同步递减NODE_COUNT。执行删除后节点记录已移除，但计数字段仍保留原值。
• 历史备份均包含相同的错误取值，因此cms gcc -restore无法修复该问题，须手工修正。

日志辅助定位

tail-30~/data/log/run/cms_srv.rlog|grep-E"ERROR|invalid"tail-20~/data/log/run/ogracd.rlog|grep-E"ABORT|ERROR"

三、停止服务

配置变更须在服务停止后方可生效，残留进程将持续占用锁文件与端口。

source~/.bashrc cms res-stopdb# 先停止数据库资源cms server-stop# 再停止 CMSsleep5# 未完全停止时的兜底处理pkill-9-f"ogracd -D";pkill-9-f"cms server"rm-f~/data/cms_server.lck ~/data/oGRAC.ogd.cms.uds_0ps-ef|grep-E"cms server|ogracd"|grep-vgrep||echo"✓ 已停止"

停止顺序不可颠倒。须先停数据库资源，再停 CMS；顺序颠倒将触发数据库 ABORT 机制，遗留异常状态。

四、配置变更

变更前执行备份：

cd~/data/cfg&&TS=$(date+%Y%m%d%H%M%S)cp-pcluster.ini cluster.ini.bak_$TS&&cp-pcms.ini cms.ini.bak_$TScd~/data&&cms gcc-backup

①cluster.ini：清除双节点残留项

sed-i'/^\s*LSNR_PORT\[1\]/d; /^\s*CMS_PORT\[1\]/d; /^\s*NODE_IP\[1\]/d; /^\s*LSNR_NODE_IP\[1\]/d'~/data/cfg/cluster.inised-i's/^CLUSTER_SIZE.*/CLUSTER_SIZE = 1/'~/data/cfg/cluster.ini

将CLUSTER_SIZE置为 1，并删除四项[1]配置的整行。

关于采用删除而非改写为127.0.0.1的说明
早期资料多建议单节点场景下将NODE_IP[1]指向回环地址。该方式仅为表层规避——使 CMS 得以建链，却掩盖了NODE_COUNT仍为 2 的事实。后续一旦执行cms node -del 1，原本"可连通的占位节点"变为"完全不存在的节点"，故障即由"集群假死"升级为"进程无法启动"。同一环境先后发生两次故障，其成因正在于此。

②cms.ini：共享路径指向实际目录

模板预置的ogracdba账户在本机并不存在，将导致 io-fence 相关操作报错。

③ GCC 元数据NODE_COUNT：关键变更项

source~/.bashrc&&cd~/data cms gcc-exp/tmp/gcc.expsed-i'3s/^0,2,/0,1,/'/tmp/gcc.exp# NODE_COUNT 由 2 修正为 1head-6/tmp/gcc.exp# 确认第 3 行已变更为 0,1,x,xecho"y"|cms gcc-imp/tmp/gcc.exp# 导入需应答确认rm-f/tmp/gcc.exp

两项操作要点：gcc -imp为交互式命令，脚本化执行时须通过echo "y" |传入确认；该操作将整体替换 GCC 数据且不可回滚，执行前务必完成cms gcc -backup。变更范围仅限NODE_COUNT字段，资源定义部分保持原样。

④ 删除资源禁用标记

rm-f~/data/res_disable

该文件存在时，即使 CMS 运行正常亦不会拉起数据库资源。通常为此前人工维护操作所遗留。

⑤ 删除残留锁文件

rm-f~/data/cms_server.lck

进程已停止但锁文件残留时，新实例启动将报Another cms server is running。

五、启动服务

source~/.bashrc&&cd~nohupcms server-start>~/data/log/cms_startup.log2>&1&sleep8cmsstat-server# 须确认 SRV_READY = TRUE 后方可继续nohupogracd-D~/data>~/data/log/ogracd_startup.log2>&1&sleep25cmsstat-resdb# 预期为 ONLINE

启动顺序不可颠倒。ogracd依赖 CMS 提供的 UDS socket，若 CMS 尚未就绪即启动数据库，重试 5 次后将触发 ABORT 机制终止进程，因此须确认SRV_READY = TRUE后再执行下一步。

正常状态输出：

NODE_ID SRV_READY 0 TRUE NODE_ID RESOURCE_NAME STAT TARGET_STAT 0 db ONLINE ONLINE

补充 SQL 连通性验证：

printf'y\nselect name, status, open_status from dv_database;\nexit;\n'\|ogsql"<用户>/<密码>@127.0.0.1:1611"# 预期输出 OGRAC / OPEN / READ WRITE

历史日志中累积的192.168.86.2连接报错属故障发生前的存量记录，无须清理，确认修复后不再新增即可。

六、经验要点

1. 单节点部署不等同于单节点配置。安装完成后须手工完成配置收敛，安装模板默认按双节点生成。
2. 收敛须覆盖两个层面。文本配置层与 GCC 二进制元数据层缺一不可，仅处理前者将导致故障复发。
3. cms node -list输出正常不足以排除隐患，须通过cms gcc -exp校验NODE_COUNT；且历史备份均带有相同缺陷，gcc -restore无法修复。
4. 数据库异常退出应优先排查 CMS。ogracd会因 CMS 失联而主动触发 ABORT，其通常是受影响方而非故障源。

附：变更清单（便于回滚）

配置文件回滚使用cp覆盖原文件；GCC 回滚使用cms gcc -restore，但须注意恢复后NODE_COUNT仍为错误值 2，须按变更项 ③ 重新处理。