主从节点部署一键安装，然后关闭数据库会超时或者卡死

xhgushen · March 2, 2026, 12:52am

系统：欧拉20.03 软件版本：opengauss6.0.2企业版

需要通过以下步骤才能正常重启数据库集群

1.执行以下命令的前提是 opengauss 主从服务器已配置omm用户ssh互通，并且/etc/hosts 文件有配置两台服务器

cat /etc/hosts | grep “Gauss” | grep -v “127.0.0.1” | grep -v “localhost” | awk ‘{print $1}’ | xargs -I {} -P 5 ssh -t omm@{} “ps -ef|grep cm | grep -v \“color\” | awk ‘{print \$2}’ | xargs sudo kill -9”

2.直接执行gs_om 重启集群(如果执行不成功或者超时，再重新执行第一步)

gs_om -t restart

3. 重启成功后，再执行切换操作，防止vip在两边服务器都存在，导致脑裂

  cm_ctl switchover -a

4.检查集群状态是否正常

gs_om -t status --detail

cm_ctl show

请问一下这个是什么问题？

openGauss_Assistant · March 2, 2026, 12:56am

答案内容由AI生成，仅供参考：

总结

问题本质：gs_om -t stop 卡死是由于 CM 组件在跨节点通信时发生阻塞，根源在于 SSH 响应延迟、CM 自身缺陷或操作系统兼容性不足。

解决思路：

临时恢复：手动杀掉 cm_server 和 gaussdb 进程后重启集群；

长期规避：升级操作系统至 openEuler 22.03，更新 openGauss 至最新稳定版，并优化 CM 配置。

建议行动项：

将当前修复流程写成自动化脚本用于应急；

规划系统升级方案，提升整体稳定性与可维护性。

点击此处查看详细分析解答

openGauss主从节点关闭超时或卡死问题分析与解决方案

根据提供的错误现象及系统环境信息，以下是针对openGauss 6.0.2企业版在openEuler 20.03上部署后，执行gs_om -t stop时出现超时或卡死的问题的全面分析与解决建议。

问题现象描述

环境：openGauss 6.0.2 企业版 + openEuler 20.03
部署方式：一键安装脚本（gs_install）完成主从集群部署
操作：执行关闭命令
```
gs_om -t stop -h dev-opengauss-master
```
实际行为：
- 命令长时间无响应
- 最终需通过 Ctrl+C 强制中断（抛出 KeyboardInterrupt）
- 报错堆栈定位到 CM_OLAP.py 中调用 subprocess.getstatusoutput(cmd) 超时

根本原因分析

结合知识库内容和日志行为，该问题的根本原因可归结为以下几点：

1. CM（Cluster Manager）组件通信异常导致停止流程阻塞

gs_om 在执行停止操作时，会通过 CM（集群管理器） 协调各节点停止服务。

调用链路径为：

gs_om → OmImplOLAP.doStopClusterByCm() → CM_OLAP.stop_cluster() → 执行远程停止命令

若某一节点的 cm_server 进程异常、响应缓慢或网络不通，则会导致整个停止流程 卡在进程间通信环节，造成超时。

来自知识库依据：

gs_om 是用于管理 GaussDB/openGauss 集群的核心命令行工具。

cm_server 是负责监控和管理集群状态的关键组件。

gs_om 通过调用 CM 接口来执行集群级操作，包括启动、停止、状态检查等。

2. SSH 通信延迟或中断导致 subprocess 等待超时

CM_OLAP.py 使用 subprocess.getstatusoutput 执行远程 SSH 命令，但 Python 的 subprocess 模块本身不支持内置超时机制（除非显式传入 timeout 参数）。
若目标机器响应慢或 SSH 连接挂起，Python 进程将 无限等待输出，从而引发阻塞。

知识库佐证：

用户需确保主备服务器间 已配置 omm 用户的 SSH 互信，否则远程命令无法执行。

/etc/hosts 必须正确配置主机名解析，否则日志中频繁出现 could not create any HA TCP/IP sockets 报错。

3. 手动强制杀进程的必要性揭示了正常停止逻辑失效

用户通过运行以下命令手动清理由 cm_server 和 gaussdb 相关进程：

ssh omm@{} "ps -ef | grep cm | grep -v color | awk '{print \$2}' | xargs sudo kill -9"

这表明：
- 原先的 cm_server 或数据库进程未正常退出；
- 正常的优雅关闭流程（如发送 SIGTERM 并等待清理）已失效；
- 只能通过 强制终止（kill -9） 恢复系统可控性。

4. 版本兼容性与已知缺陷影响

尽管 openGauss 6.0.2 在 openEuler 22.03 上有完整支持包，但在 openEuler 20.03 上可能存在兼容性问题。
官方文档指出，部分低版本操作系统可能因内核、glibc 或 Python 版本差异导致组件行为异常。

搜索结果补充：

openGauss 6.0.0 修复了主节点宕机后，备节点 cm_server 无法接管的问题（参考：openGauss 6.0.2版本发布说明），说明旧版本 CM 在故障转移中存在风险。

此类问题极可能导致 gs_om stop 时，CM 决策混乱，进而引发阻塞。

解决方案与最佳实践

方案一：强制清理 + 重启恢复（适用于当前紧急修复）

您目前的处理流程合理，可优化为标准化操作脚本：

# Step 1: 强制终止所有 cm 相关进程（在主节点执行）
cat /etc/hosts | grep -v "127.0.0.1" | grep -v "localhost" | awk '{print $1}' | \
xargs -I {} -P 5 ssh -o StrictHostKeyChecking=no omm@{} \
"ps -ef | grep cm_server | grep -v grep | awk '{print \$2}' | xargs kill -9 2>/dev/null; \
ps -ef | grep gaussdb | grep -v grep | awk '{print \$2}' | xargs kill -9 2>/dev/null"

# Step 2: 重启集群
gs_om -t restart

# Step 3: 若存在 VIP，执行切换防止脑裂
cm_ctl switchover -a

# Step 4: 检查状态
gs_om -t status --detail
cm_ctl show

注意：kill -9 会强制终止，可能造成未提交事务丢失，请仅用于无法正常关闭的场景。

方案二：优化配置与环境以避免问题复发

1. 确保 CM 配置健壮性

检查 cluster_config.xml 中 CM 相关参数是否合理，例如：

<PARAM name="cmServerPortBase" value="21000"/>
<PARAM name="cmServerPortStep" value="100"/>

确保 cm_server 日志目录可写，查看日志排查 CM 是否频繁崩溃。

2. 启用 CM 心跳超时与故障转移策略

在配置文件中设置合理的超时时间，防止无限等待：

<PARAM name="cmHeartbeatTimeout" value="30"/>
<PARAM name="cmFaultToleranceNum" value="1"/>

3. 升级至推荐操作系统版本

openEuler 20.03 不是 openGauss 6.0.2 的最佳匹配版本。
建议升级至官方推荐的 openEuler 22.03 LTS，以获得完整兼容性支持。

4. 定期更新至稳定补丁版本

查看是否有更新的 6.0.3 或 6.1.0 版本，修复了以下类型问题：
- CM 远程调用超时缺陷
- gs_om 脚本中 subprocess 未设超时的 Bug

参考资料

总结