Gaussdb分布式集群状态为degraded，其中2个CN节点状态为Deleted（上）

最新推荐文章于 2024-09-27 23:54:01 发布
最新推荐文章于 2024-09-27 23:54:01 发布
阅读量830 收藏 15
点赞数 18
文章标签： gaussdb 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Oliviahome/article/details/142338205
版权

问题描述

服务器卡顿的厉害，xshell工具不能访问，联系服务器管理员后，其对服务器进行了重启，恢复访问后查看集群状态显示状态异常，出现了CN服务异常告警，查询集群状态， CN组件状态为Deleted。
详情如下：

--查看集群状态
[omm@node01 ~]$ cm_ctl query -Cvipd
[  CMServer State   ]

node             node_ip         instance                                state
--------------------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   1    /gaussdb/cluster/data/cm/cm_server Primary
2  192.168.30.52 192.168.30.52   2    /gaussdb/cluster/data/cm/cm_server Standby
3  192.168.30.53 192.168.30.53   3    /gaussdb/cluster/data/cm/cm_server Standby

[    ETCD State     ]

node             node_ip         instance                        state
------------------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   7001 /gaussdb/cluster/data/etcd StateFollower
2  192.168.30.52 192.168.30.52   7002 /gaussdb/cluster/data/etcd StateFollower
3  192.168.30.53 192.168.30.53   7003 /gaussdb/cluster/data/etcd StateLeader

[   Cluster State   ]

cluster_state   : Degraded  降级
redistributing  : No
balanced        : No
current_az      : AZ_ALL

[ Coordinator State ]

node             node_ip         instance                             state
----------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   5001 8000   /gaussdb/cluster/data/cn Deleted
2  192.168.30.52 192.168.30.52   5002 8000   /gaussdb/cluster/data/cn Normal
3  192.168.30.53 192.168.30.53   5003 8000   /gaussdb/cluster/data/cn Deleted

[ Central Coordinator State ]

node             node_ip         instance                      state
----------------------------------------------------------------------
2  192.168.30.52 192.168.30.52   5002 /gaussdb/cluster/data/cn Normal

[     GTM State     ]

node             node_ip         instance                       state                    sync_state
-------------------------------------------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   1001 /gaussdb/cluster/data/gtm P Primary Connection ok  Sync
2  192.168.30.52 192.168.30.52   1002 /gaussdb/cluster/data/gtm S Standby Connection ok  Sync
3  192.168.30.53 192.168.30.53   1003 /gaussdb/cluster/data/gtm S Standby Connection ok  Sync

[  Datanode State   ]

node             node_ip         instance                                     state            | node             node_ip         instance                                     state            | node             node_ip         instancestate
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   6001 33100  /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2  192.168.30.52 192.168.30.52   6002 33100  /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3  192.168.30.53 192.168.30.53   6003 33100  /gaussdb/cluster/data/dn/dn_6003S Standby Normal
2  192.168.30.52 192.168.30.52   6004 33120  /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1  192.168.30.51 192.168.30.51   6005 33120  /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3  192.168.30.53 192.168.30.53   6006 33120  /gaussdb/cluster/data/dn/dn_6006S Standby Normal
3  192.168.30.53 192.168.30.53   6007 33140  /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2  192.168.30.52 192.168.30.52   6008 33140  /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1  192.168.30.51 192.168.30.51   6009 33140  /gaussdb/cluster/data/dn/dn_6009S Standby Normal

连接工具也只能访问30.52节点，访问30.51和30.53节点提示如下报错：

问题原因

可能原因有以下：
1、 虚拟机重启，断网等故障导致CN被剔除。
2、 CN与主DN断连导致CN被剔除。
3、 CN组件Down导致CN被剔除。
4、 CN组件频繁重启导致CN被剔除。
5、 CN组件被主动剔除。

分析过程

build相关日志路径：$GAUSSLOG/bin/gs_ctl

cm_agent日志路径：$GAUSSLOG/cm

实例日志路径：$GAUSSLOG/gs_log/dn_xx

cn日志路径：$GAUSSLOG/gs_log/cn_5001

系统日志（仅root用户）：/var/log/message

查看磁盘空间

df -h 查看磁盘空间，3个节点磁盘空间剩余还有不少。

查询集群状态

登录任一节点，切换到数据库用户，查询集群状态 ，集群状态变成了Cluster State：Degraded，30.51和30.53节点上的CN节点被剔除，状态变成了Deleted。

su - omm
cm_ctl query -Cvipd

输出如下：

[  CMServer State   ]

node             node_ip         instance                                state
--------------------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   1    /gaussdb/cluster/data/cm/cm_server Primary
2  192.168.30.52 192.168.30.52   2    /gaussdb/cluster/data/cm/cm_server Standby
3  192.168.30.53 192.168.30.53   3    /gaussdb/cluster/data/cm/cm_server Standby
......
[   Cluster State   ]

cluster_state   : Degraded
redistributing  : No
balanced        : No
current_az      : AZ_ALL

[ Coordinator State ]

node             node_ip         instance                             state
----------------------------------------------------------------------
1  192.168.30.51 192.168.30.51   5001 8000   /gaussdb/cluster/data/cn Deleted
2  192.168.30.52 192.168.30.52   5002 8000   /gaussdb/cluster/data/cn Normal
3  192.168.30.53 192.168.30.53   5003 8000   /gaussdb/cluster/data/cn Deleted 
......

查看主节点的cm_server日志

登录到CMS主节点查集群状态获取主节点信息

任一个节点登录到CMS主节点(显示节点30.51的实例状态是Primary)，查看cm_server日志。 CMS主节点，可通过查询集群状态获取 。

su - omm 
cm_ctl query -Cv

输出如下：

[omm@node01 ~]$ cm_ctl query -Cv
[  CMServer State   ]

node             instance state
---------------------------------
1  192.168.30.51 1        Primary  --显示节点30.51的实例状态是Primary
2  192.168.30.52 2        Standby
3  192.168.30.53 3        Standby
......

查看主节点的cm_server日志

打开对应时间点的cm_server-***.log日志，如对应时间点的日志已被压缩，则查看对应的cm_server-****.log.gz日志。

su - omm
cd $GAUSSLOG/cm/cm_server
vi cm_server-2024-08-26_100433-current.log

输出如下：

2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5001) heartbeat timeout, heartbeat:6191, threshold:6
2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5003) heartbeat timeout, heartbeat:6191, threshold:6
2024-08-26 11:32:58.143 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5)
2024-08-26 11:32:58.567 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5)
2024-08-26 11:32:58.577 tid=24770 STORAGE ASYN LOG: [ReadOnlyActRecordInitState] instance 5001 in the initial state, disk_usage:8, read_only:0, read_only_threshold:85
2024-08-26 11:32:59.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5)
2024-08-26 11:32:59.568 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:00.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:00.569 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:01.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:01.571 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:02.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5)
2024-08-26 11:33:02.570 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5)
场景1：cm_server日志中搜索有关键词cn_down_to_delete=1

在cm_server日志中搜索有关键词cn_down_to_delete=1:
● 如对应时间点存在该信息，则原因为CN组件Down 导致，参考CN状态Down排查详细原因。
● 确认故障节点是否发生断网。
● 确认故障节点操作系统是否发生过重启。
● 故障处理后执行节点修复加回被剔除的CN。
● 如不涉及继续场景2。

场景2：cm_server日志中搜索有关键词isCnDnDisconnected=1

在cm_server日志中搜索有关键词： isCnDnDisconnected=1：
● 如对应时间点存在该信息，则原因为CN组件与主DN断链导致，此时需要排查CN与主DN之间的网络，待网络恢复后，执行节点修复加回被剔除的CN。
● 如不涉及继续场景3。

场景3：cm_server日志中搜索有关键词cmd_disable_cn=1

在cm_server日志中搜索有关键词： cmd_disable_cn=1：
● 如对应时间点存在该信息，则原因为CN组件被主动剔除，确认剔除原因后，后执行节点修复加回被剔除的CN。
● 如不涉及继续场景4。

场景4：cm_server日志中搜索有关键词cnReadonly=1

在cm_server日志中搜索有关键词： cnReadonly=1：
● 如对应时间点存在该信息，则原因为CN组件readonly 导致，参考CN状态为readonly排查详细原因。
● 如不涉及继续场景5。

场景5：cm_server日志中搜索有关键词cn instance restarts within ten minutes is more
than

在cm_server日志中搜索有关键词” cn instance restarts within ten minutes is more than”：
● 如对应时间点存在此信息，则原因为CN组件频繁重启导致，出现此种情况，参考
CN 启动失败进一步定位，故障处理后执行节点修复加回被剔除的CN。
● 如不涉及继续场景6

场景6：联系华为工程师提供技术支持

若以上均不涉及，则联系华为工程师提供技术支持

本文档属于场景6的情况。

Gaussdb分布式集群状态为degraded，其中2个CN节点状态为Deleted - 墨天轮 (modb.pro)

如清风一般
关注
Longhorn 云原生容器分布式存储 - 故障排除指南
o__cc的博客
10-19 2485
内容来源于官方 Longhorn 1.1.2 英文技术手册。 系列 Longhorn 是什么? Longhorn 云原生容器分布式存储 - 设计架构和概念 Longhorn 云原生容器分布式存储 - 部署篇 Longhorn 云原生容器分布式存储 - 券和节点 Longhorn 云原生容器分布式存储 - K8S 资源配置示例 Longhorn 云原生容器分布式存储 - 监控(Promethe...
ALM-5012947 云数据库 GaussDB ETCD服务异常
Cui_Yuan_666的博客
09-18 478
如果半数以下的ETCD节点异常，则无影响，如果有半数以上的ETCD节点异常，则数据库不可用。因为是沙箱环境，所以需要在查询到的ETCD数据目录前加上/var/chroot。此告警修复后，系统会自动清除此告警，无需手工清除。如果授权文件不可以访问，执行如下指令，添加权限。如以上步骤未定位出问题，请继续执行。执行如下指令，查看集群状态。如果可以访问，则执行。
【深入浅出etcd系列】3. 日志同步
华为云官方博客
06-20 2859
概论 分布式共识算法(consensus algorithm)通常的做法就是在多个节点上复制状态机。分布在不同服务器上的状态机执行着相同的状态变化，即使其中几台机器挂掉，整个集群还能继续运作。 复制状态机正确运行的核心的同步日志，日志是保证各节点状态同步的关键，日志中保存了一系列状态机命令，共识算法的核心是保证这些不同节点上的日志以相同的顺序保存相同的命令，由于状态机是确定的，所以相同的命令以相...
实例解读丨关于GaussDB ETCD服务异常
华为云官方博客
11-02 1674
本文通过对ETCD服务异常问题分析，代码展示解决方案。
GaussDB分布式集群状态为degraded，其中2个CN节点状态为Deleted（下）
Oliviahome的博客
09-18 418
分别在已剔除的CN节点上操作，修复过程会有些漫长，大概5分钟左右。
GaussDB(分布式)实例故障处理
华为云官方博客
03-19 901
GaussDB Kernel实例出现故障时，可以按照本节的办法进行实例快速修复。
Kubernetes 集群分布式存储插件 Rook Ceph部署
Mo小泽的技术博客
10-31 1590
文章目录Kubernetes 集群分布式存储插件 Rook Ceph部署前言Rook 介绍简介Rook 架构Rook 部署前期规划准备工作获取 YAML部署 Rook Operator部署 cluster部署 Toolbox测试 Rook设置 dashboard部署 Node SVC确认验证遇到问题dashboard 点击概述`500 Internal Server Error` Kubernetes 集群分布式存储插件 Rook Ceph部署 前言 我们经常会说：容器和 Pod 是短暂的。其含义是它们的生
1.24版本k8s集群安装部署rook-ceph存储集群
极客海哥
06-02 2125
一、初始花基本环境 1.主机环境信息2.部署k8s集群 参见；https://blog.csdn.net/lic95/article/details/125044136二、部署rook ceph 1.参考rook-ceph说明 https://rook.github.io/docs/rook/latest/Getting-Started/quickstart/#deploy-the-rook-operator2.确认none节点硬盘情况，本文5个node节点共10块硬盘 3.部署证书管理器 4.安装lvm包
分布式存储Ceph中PG各种状态详解.docx
10-13
例如，如果一个拥有三个副本的PG其中一个副本所在的OSD失效，则该PG状态会变为“degraded”。 **3.1.2 故障模拟** 假设有一个名为`osd.1`的OSD被停止： ``` $ systemctl stop ceph-osd@1 ``` 此时，通过`ceph pg...
R软件代码转换为matlab-wv2-processing:在Worldview2影像上处理决策树土地用途分类的脚本
05-21
在WorldView-2图像上处理决策树土地用途分类的脚本。 栖息地覆盖物类 以下是此代码创建的栖息地类别。 wv_classification_colormap.txt提供具有相似值和关联颜色的色图，以用于QGIS（及其他）。 BA = bare soil WA =...
分布式存储Ceph之PG状态详解
didi_cloud的博客
05-07 1912
1. PG介绍这次主要来分享Ceph中的PG各种状态详解，PG是最复杂和难于理解的概念之一，PG的复杂如下： 在架构层次上，PG位于RADOS层的中间。a. 往上负责接收和处理来自客户端的请求。b. 往下负责将这些数据请求翻译为能够被本地对象存储所能理解的事务。是组成存储池的基本单位，存储池中的很多特性，都是直接依托于PG实现的。面向容灾域的备份策略使得一般而言的PG需要执行跨节点的分布式写，因此...
分布式存储系统之Ceph集群存储池、PG 与 CRUSH
「 虚幻私塾」
10-06 1287
前文我们了解了ceph集群状态获取常用命令以及通过ceph daemon、ceph tell动态配置ceph组件、ceph.conf配置文件相关格式的说明等，回顾请参考https://blog.csdn.net/qiuhom-1874/p/16727820.html；今天我们来聊一聊ceph的存储池、PG以及CRUSH相关话题；一、关于存储池我们知道ceph客户端存储对象数据到RADOS集群上，不是客户端直接存储到osd上；首先客户端会根据ceph集群的配置，将客户端存储的对象数据切分多个固定大小的对象数据
华为GaussDB数据库之Yukon安装与使用
非法小恋
09-27 703
Yukon（禹贡），基于openGauss、PostgreSQL、GaussDB数据库扩展地理空间数据的存储和管理能力，提供专业的GIS（Geographic Information System）功能，赋能传统关系型数据库。Yukon 支持二三维一体化的空间数据存储能力:官网地址,此次我们基于华为GaussDB安装Yukon。
【分布式微服务云原生】windows+docker+mysql5.7.44一主一从主从复制
最新发布
Dylaniou的博客
09-27 724
在Windows系统上通过Docker部署MySQL主从复制，以下是详细的步骤和命令，帮助你设置一主一从的MySQL复制环境。
10KV并网分布式光伏电力监控解决方案
yxy2881578426的博客
09-23 914
针对用户新能源接入后存在安全隐患、缺少有效监控、发电效率无法保证、收益计算困难、运行维护效率低等通点，提出的Acrel-1000DP分布式光伏监控系统平台，对整个用户电站全面监控，为用户实现降低能源。逆变器选用组串式逆变器，光伏发电逆变器电源电压为800V，经室内升压变升压至10kV后,通过高压电缆接入新增的10kV光伏高压柜,并入原10kV市电高压柜。屋面建设17.99985MWp分布式光伏发电项目，采用“自发自用，余电上网”模式，采用XGF10-Z-1国网典型。、减轻变压器负载、余电上网，提高收益；
探索分布式IO模块的介质冗余：赋能工业自动化的稳健之心
Mindtech_link的博客
09-25 350
在日新月异的工业自动化领域，每一个细微环节的稳定性都直接关系到生产线的效率与安全。随着智能制造的深入发展，分布式IO（Input/Output）模块作为连接现场设备与控制系统的关键桥梁，其重要性日益凸显。我们自主研发的带有介质冗余功能的MR30分布式IO模块，正以其独特的优势，为工业自动化系统构建起一道坚不可摧的防护网。
jenkins分布式构建
weixin_50464533的博客
09-23 586
Jenkins分布式构建是一种将构建任务分散到多个机器上的方法，以提高构建效率和并行处理能力
MR30分布式IO模块：革新纸巾包装，引领智能化绿色生产新纪元
Mindtech_link的博客
09-24 374
EtherCAT（以太网控制自动化技术）协议以其高带宽、低延迟特性，在工业自动化领域占据重要地位。我们自主研发的MR30分布式IO模块作为EtherCAT协议的杰出应用，集成了多种输入输出功能，通过EtherCAT总线实现与主站的高效通信与控制，为纸巾包装行业带来革新。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值