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

[xhgushen]

系统：欧拉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]

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

总结

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

解决思路：

1. 临时恢复：手动杀掉 cm_server 和 gaussdb 进程后重启集群；
2. 长期规避：升级操作系统至 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

---

推荐预防措施

措施	说明
配置 omm 用户免密 SSH 互信	避免远程执行命令时卡顿
完善 /etc/hosts 配置	防止主机名解析延迟
定期检查 cm_server 运行状态	使用 gs_om -t status --detail 监控
避免直接使用 kill -9	尽量使用 gs_om -t stop 优雅关闭
开启 CM 日志审计	便于定位通信失败原因

---

参考资料

• gs_om 官方文档
• CM 组件工作原理
• cm_ctl 命令参考

---

总结

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

解决思路：

1. 临时恢复：手动杀掉 cm_server 和 gaussdb 进程后重启集群；
2. 长期规避：升级操作系统至 openEuler 22.03，更新 openGauss 至最新稳定版，并优化 CM 配置。

建议行动项：

• 将当前修复流程写成自动化脚本用于应急；
• 规划系统升级方案，提升整体稳定性与可维护性。

[wzy_openGauss]

集群重启和切换都正常吗？图片中stop命令大概等了多长时间手动中断的？

[xhgushen]

重启不正常的，就会卡死，然后超时，关闭主，节点会切换到从，但原主起来后，查vip两台机器都有，要手动切换

[wzy_openGauss]

有出现dn脑裂的情况吗？各节点查gs_om -t view，节点状态对着吗？

[xhgushen]

第一张图会cm_ctl show看到两个节点都有vip，第二张图是9.164查到的信息，第三张图是9.165查到的信息

[wzy_openGauss]

两个节点带cm的情况下不建议只停一个节点，你第一个命令停了164后，cm会等待查询集群状态，但由于剩下的一个节点无法选出多数派，不能升主，导致集群状态一直不对，所以命令一直在等集群状态恢复正常，所以一直在那儿卡着。

[wzy_openGauss]

执行重启命令的时候164是停止的，165状态未知，执行restart就是把两个节点都停了然后重启，cm_ctl show看到两个节点都有vip，有可能是因为给主备的AZ都配了vip，显示的是配置情况，你可以看看刚搭起来的时候vip情况是怎么样的，如果也是两节点都显示vip，那就正常的。

[xhgushen]

问题是刚搭建起来的时候，gs_om -t restart 也会卡住超时，后面没办法重启，才尝试关闭某个节点，这种情况要怎么解决？

[xhgushen]

https://zhuanlan.zhihu.com/p/671725076 是按照这个文档部署的，刚开始部署的时候是只有一个节点是又VIP的，后面恢复后才有两个节点又VIP

[tom11 (Tom11_openGauss)]

看看电脑的资源够不，如cpu和内存

[xhgushen]

够的，16核32G

[wzy_openGauss]

看下官网指导，有啥差异吗？我试了一下搞成功了。

opengauss 5.0 CM新特性之 vip配置 | openGauss社区