前言本章主要介绍 GBase 8c 9gbase database多模多态数据库在启动过程中出现夯住卡住现象并在 5 分钟后因启动超时导致失败的全链路排查思路与处理方法。在实际环境中当数据库启动夯住时往往不会立即产生明确的错误信息而是表现为进程长时间无响应最终因超时而失败。此时可查看的日志种类繁多包括 cm_server、cm_agent、om_monitor、pg_log 等如何在有限时间内快速定位问题避免在海量日志中迷失方向是运维实践中的典型问题。本文提供一套高效的排查思路帮助运维人员快速缩小问题范围并给出针对性的处理方式以尽快恢复集群正常运行。本文以主备式为例。集群架构该架构属于集群模式至少有2个dn节点1主1备部署时一般都会带cm_server支持高可用。另外GBase 8c 提供vip能力即虚拟IP。当主机出现故障时无需人工干预VIP在原主上卸载会自动将VIP绑定至新的主节点上。以完成集群自动切换并对上层应用无感知避免数据库发生主备倒换对客户端的影响。对于1主1备带cm_server集群数据库实例主要分四个部分安装目录数据目录环境变量数据库进程gbased。其中启动顺序遵循OM 工具 → CM 组件 → 数据库实例 的路径。第一步OM 工具层 (gs_om)执行 gs_om -t start在操作系统用户 gbase 下执行该命令时OM 工具开始运行。检测超时此时工具会启动一个 300秒5分钟 的计时器。如果之前遇到 5 分钟后启动失败正是这个 OM 层的超时机制生效 。调用底层OM 根据集群静态配置去触发目标服务器上的 cm_agent 进程。第二步CM 高可用层 (核心仲裁)启动的核心环节分为 CM Server 和 CM Agent 的协作CM Server 先决条件gs_om 会确保集群的仲裁节点cm_server先就绪。拉起 CM Agent主机的 OM 会通过网络启动各节点上的 cm_agent 进程。Agent 接管启动一旦 cm_agent 启动成功gs_om 的任务就完成了后续将由 cm_agent 来拉起数据库进程。第三步数据库进程层 (gbased)Agent 发起拉起cm_agent 根据 CM Server 的指令尝试启动本机的 gbased 数据库进程。启动目录与参数gbased 进程启动时会读取数据目录 ($PGDATA) 下的配置文件如 postgresql.conf并依赖环境变量如 PATH, LD_LIBRARY_PATH来定位二进制文件和依赖库。实例状态流转进程开始启动会经历starting → Unknown/catchup/Need repair/Pending /Offline/normal等多个状态的情况。cm_server 会持续检测主备状态。启动“夯住”5min超时如何排查第一步检查集群状况。操作参考如下su - gbase gs_om -t status --detail # 如果dn状态均正常启动直接跳转到文章《第三步》 # 如果dn状态均启动失败停止数据库集群 gs_om -t stop gs_ssh -c ps -ux # 检查所有节点后台数据库进程若存在om_monitor、cm_agent、cm_server、gbased 进程kill -9第二步单独拉起数据库dn节点 -- 判断是dn是否存在问题#主节点执行 gs_ctl start -D $PGDATA -M primary #备节点执行 gs_ctl start -D $PGDATA -M standby ##启动后如果最后两行显示以下内容说明dn启动正常。 [2026-06-10 11:53:03.476][3797645][][gs_ctl]: done [2026-06-10 11:53:03.476][3797645][][gs_ctl]: server started (/data/gbase/database/install/data/dn) #主节点验证方式 gsql -d postgres -r -p 15400 select * from pg_replication_slots ; # 关注active 字段t为正常f说明备机未启动成功或者同步存在问题此时假如单机启动主dn存在问题优先查看单机启动时窗口返回日志重点关注FATAL/ERROR内容。1.端口占用netstat -lnutp|grep 15400 ps -ef|grep pid # 排查那个进程占用数据库端口2.权限问题# 报Permission denied 检查报错数据目录的属组或者属主是否为安装用户 # 报Permissions should be urwx (0700). 检查目前的读写执行权限默认必须是0700若存在批量把数据目录$PGDATA改成777的操作,恢复文件权限600目录700find $PGDATA -perm 777 -type d | xargs chmod 700 find $PGDATA -perm 777 -type f | xargs chmod 6003.参数/参数值问题参数/参数值问题报错很清晰直接在配置文件修改后再次启动即可。4.信号量问题#优化信号量参数 vim /etc/sysctl.conf kernel.shmall 1152921504606846720 kernel.shmmax 18446744073709551615 kernel.sem 40960 2048000 40960 20480 sysctl -p5.若窗口返回日志没有明确报错信息需检查对应节点的数据库日志 pg_logcd $GAUSSLOG cd pg_log/dn_6001 # 主要搜 ERROR、FATAL、PANIC 类型的报错。例如 ## 控制文件损坏、磁盘坏道、启动时关键文件缺失 PANIC: could not open control file ## 共享内存不足 FATAL: could not create shared memory segment ## 备库查询与主库日志清理冲突 ERROR: canceling statement due to conflict with recovery第三步dn可以单独启动时则判定高可用OM/CM或者集群间故障1.集群间检查点测试集群间免密 时间时间差异小于1s# 集群中所有集群都免密检查 验证时间 ssh 主机名1 date ssh 主机名2 date处理方式su - gbase rm -rf /home/gbase/.ssh mkdir ~/.ssh chmod 700 ~/.ssh ssh-keygen -t rsa ssh-copy-id gbase主机名1 ssh-copy-id gbase主机名2 echo StrictHostKeyChecking no ~/.ssh/config echo UserKnownHostsFile ~/.ssh/known_hosts ~/.ssh/config chmod 644 ~/.ssh/config #免密测试 ssh 主机名1 date ssh 主机名2 date查看单个进程打开的文件最大数(必须大于64w)# 主备都检查 ulimit -n处理方式vim /etc/security/limits.conf * soft nofile 1000000 * hard nofile 1000000该问题在 cm/om_monitor/om_monitor-xxx-current.log 日志会报检查防火墙(策略)# 主备都检查 systemctl status firewall /etc/selinux/config iptables -nL # 如果防火墙开启的情况下检查策略是否正确检查sudo权限# 主备都检查 sudo -l sudo systemctl status firewalld检查网关# 主备都检查 ip route|grep via ping 网关地址2.高可用OM/CM检查点定时任务# 主备都检查 su - gbase crontab -l # 两行内容需要打开注释高可用启动单节点vip# 主节点操作 gs_om -t start -h 主机名1 gs_om -t status --detail此时业务可以正常连接vip地址。# 备节点操作 gs_om -t start -h 主机名2 gs_om -t status --detail若出现主节点启动成功启动备节点后状态不对按照以下步骤检查# 检查所有节点网关配置 egrep -i ^third_party_gateway_ip /xxx/cm/cm_server/cm_server.conf # 检查vip 配置 cat /xxx/cm/cm_agent/cm_resource.json # 若vip 配置存在问题删除重新配置 cm_ctl res --del --res_nameCM_VIP# 主备检查 postgresql.conf 配置文件 replconninfo。备份恢复后未替换配置文件重灾区 egrep -i ^replconninfo postgresql.conf启动集群,查看集群状态gs_om -t start gs_om -t status --detail若出现cm_server 单个或者多个节点都无法启动的情况按照以下步骤检查# 那个节点状态有问题处理那个节点 cd cm rm -rf dcf_data gstor gs_om -t restart --componentCM
GBase 8c运维管理场景之集中式集群启动全链路排查
前言本章主要介绍 GBase 8c 9gbase database多模多态数据库在启动过程中出现夯住卡住现象并在 5 分钟后因启动超时导致失败的全链路排查思路与处理方法。在实际环境中当数据库启动夯住时往往不会立即产生明确的错误信息而是表现为进程长时间无响应最终因超时而失败。此时可查看的日志种类繁多包括 cm_server、cm_agent、om_monitor、pg_log 等如何在有限时间内快速定位问题避免在海量日志中迷失方向是运维实践中的典型问题。本文提供一套高效的排查思路帮助运维人员快速缩小问题范围并给出针对性的处理方式以尽快恢复集群正常运行。本文以主备式为例。集群架构该架构属于集群模式至少有2个dn节点1主1备部署时一般都会带cm_server支持高可用。另外GBase 8c 提供vip能力即虚拟IP。当主机出现故障时无需人工干预VIP在原主上卸载会自动将VIP绑定至新的主节点上。以完成集群自动切换并对上层应用无感知避免数据库发生主备倒换对客户端的影响。对于1主1备带cm_server集群数据库实例主要分四个部分安装目录数据目录环境变量数据库进程gbased。其中启动顺序遵循OM 工具 → CM 组件 → 数据库实例 的路径。第一步OM 工具层 (gs_om)执行 gs_om -t start在操作系统用户 gbase 下执行该命令时OM 工具开始运行。检测超时此时工具会启动一个 300秒5分钟 的计时器。如果之前遇到 5 分钟后启动失败正是这个 OM 层的超时机制生效 。调用底层OM 根据集群静态配置去触发目标服务器上的 cm_agent 进程。第二步CM 高可用层 (核心仲裁)启动的核心环节分为 CM Server 和 CM Agent 的协作CM Server 先决条件gs_om 会确保集群的仲裁节点cm_server先就绪。拉起 CM Agent主机的 OM 会通过网络启动各节点上的 cm_agent 进程。Agent 接管启动一旦 cm_agent 启动成功gs_om 的任务就完成了后续将由 cm_agent 来拉起数据库进程。第三步数据库进程层 (gbased)Agent 发起拉起cm_agent 根据 CM Server 的指令尝试启动本机的 gbased 数据库进程。启动目录与参数gbased 进程启动时会读取数据目录 ($PGDATA) 下的配置文件如 postgresql.conf并依赖环境变量如 PATH, LD_LIBRARY_PATH来定位二进制文件和依赖库。实例状态流转进程开始启动会经历starting → Unknown/catchup/Need repair/Pending /Offline/normal等多个状态的情况。cm_server 会持续检测主备状态。启动“夯住”5min超时如何排查第一步检查集群状况。操作参考如下su - gbase gs_om -t status --detail # 如果dn状态均正常启动直接跳转到文章《第三步》 # 如果dn状态均启动失败停止数据库集群 gs_om -t stop gs_ssh -c ps -ux # 检查所有节点后台数据库进程若存在om_monitor、cm_agent、cm_server、gbased 进程kill -9第二步单独拉起数据库dn节点 -- 判断是dn是否存在问题#主节点执行 gs_ctl start -D $PGDATA -M primary #备节点执行 gs_ctl start -D $PGDATA -M standby ##启动后如果最后两行显示以下内容说明dn启动正常。 [2026-06-10 11:53:03.476][3797645][][gs_ctl]: done [2026-06-10 11:53:03.476][3797645][][gs_ctl]: server started (/data/gbase/database/install/data/dn) #主节点验证方式 gsql -d postgres -r -p 15400 select * from pg_replication_slots ; # 关注active 字段t为正常f说明备机未启动成功或者同步存在问题此时假如单机启动主dn存在问题优先查看单机启动时窗口返回日志重点关注FATAL/ERROR内容。1.端口占用netstat -lnutp|grep 15400 ps -ef|grep pid # 排查那个进程占用数据库端口2.权限问题# 报Permission denied 检查报错数据目录的属组或者属主是否为安装用户 # 报Permissions should be urwx (0700). 检查目前的读写执行权限默认必须是0700若存在批量把数据目录$PGDATA改成777的操作,恢复文件权限600目录700find $PGDATA -perm 777 -type d | xargs chmod 700 find $PGDATA -perm 777 -type f | xargs chmod 6003.参数/参数值问题参数/参数值问题报错很清晰直接在配置文件修改后再次启动即可。4.信号量问题#优化信号量参数 vim /etc/sysctl.conf kernel.shmall 1152921504606846720 kernel.shmmax 18446744073709551615 kernel.sem 40960 2048000 40960 20480 sysctl -p5.若窗口返回日志没有明确报错信息需检查对应节点的数据库日志 pg_logcd $GAUSSLOG cd pg_log/dn_6001 # 主要搜 ERROR、FATAL、PANIC 类型的报错。例如 ## 控制文件损坏、磁盘坏道、启动时关键文件缺失 PANIC: could not open control file ## 共享内存不足 FATAL: could not create shared memory segment ## 备库查询与主库日志清理冲突 ERROR: canceling statement due to conflict with recovery第三步dn可以单独启动时则判定高可用OM/CM或者集群间故障1.集群间检查点测试集群间免密 时间时间差异小于1s# 集群中所有集群都免密检查 验证时间 ssh 主机名1 date ssh 主机名2 date处理方式su - gbase rm -rf /home/gbase/.ssh mkdir ~/.ssh chmod 700 ~/.ssh ssh-keygen -t rsa ssh-copy-id gbase主机名1 ssh-copy-id gbase主机名2 echo StrictHostKeyChecking no ~/.ssh/config echo UserKnownHostsFile ~/.ssh/known_hosts ~/.ssh/config chmod 644 ~/.ssh/config #免密测试 ssh 主机名1 date ssh 主机名2 date查看单个进程打开的文件最大数(必须大于64w)# 主备都检查 ulimit -n处理方式vim /etc/security/limits.conf * soft nofile 1000000 * hard nofile 1000000该问题在 cm/om_monitor/om_monitor-xxx-current.log 日志会报检查防火墙(策略)# 主备都检查 systemctl status firewall /etc/selinux/config iptables -nL # 如果防火墙开启的情况下检查策略是否正确检查sudo权限# 主备都检查 sudo -l sudo systemctl status firewalld检查网关# 主备都检查 ip route|grep via ping 网关地址2.高可用OM/CM检查点定时任务# 主备都检查 su - gbase crontab -l # 两行内容需要打开注释高可用启动单节点vip# 主节点操作 gs_om -t start -h 主机名1 gs_om -t status --detail此时业务可以正常连接vip地址。# 备节点操作 gs_om -t start -h 主机名2 gs_om -t status --detail若出现主节点启动成功启动备节点后状态不对按照以下步骤检查# 检查所有节点网关配置 egrep -i ^third_party_gateway_ip /xxx/cm/cm_server/cm_server.conf # 检查vip 配置 cat /xxx/cm/cm_agent/cm_resource.json # 若vip 配置存在问题删除重新配置 cm_ctl res --del --res_nameCM_VIP# 主备检查 postgresql.conf 配置文件 replconninfo。备份恢复后未替换配置文件重灾区 egrep -i ^replconninfo postgresql.conf启动集群,查看集群状态gs_om -t start gs_om -t status --detail若出现cm_server 单个或者多个节点都无法启动的情况按照以下步骤检查# 那个节点状态有问题处理那个节点 cd cm rm -rf dcf_data gstor gs_om -t restart --componentCM
