node evict

最新推荐文章于 2022-03-02 17:35:11 发布
最新推荐文章于 2022-03-02 17:35:11 发布
阅读量145 收藏
点赞数

一、主机环境

OS REDHAT EL 6.6

 

二、故障现象：

 

一套系统4+6一体机集群出现驱逐实例故障：

 

主机yxfkdb2的Grid alert日志在2016年10月16日的10：17分点，出现如下报警：

 

2016-10-16 10:17:18.871:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb1 (1) missing for 50% of timeout interval. Removal of this node from cluster in 14.540 seconds

2016-10-16 10:17:18.872:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb3 (3) missing for 50% of timeout interval. Removal of this node from cluster in 14.020 seconds

2016-10-16 10:17:18.872:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb4 (4) missing for 50% of timeout interval. Removal of this node from cluster in 14.700 seconds

2016-10-16 10:17:25.875:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb3 (3) missing for 75% of timeout interval. Removal of this node from cluster in 7.010 seconds

2016-10-16 10:17:26.876:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb1 (1) missing for 75% of timeout interval. Removal of this node from cluster in 6.530 seconds

2016-10-16 10:17:26.877:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb4 (4) missing for 75% of timeout interval. Removal of this node from cluster in 6.690 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb1 (1) missing for 90% of timeout interval. Removal of this node from cluster in 2.530 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb3 (3) missing for 90% of timeout interval. Removal of this node from cluster in 2.010 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb4 (4) missing for 90% of timeout interval. Removal of this node from cluster in 2.690 seconds

 

从日志中看到节点2与其他三个节点网络心跳丢失在规定的时间内会被驱逐，此情况多数为RAC私网心跳问题，但从oswatch中分析私有网络不存在异常；

 

三、故障原因分析

私有网络心跳丢失导致节点2驱逐；

2016-10-16 10:17:18.871:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb1 (1) missing for 50% of timeout interval. Removal of this node from cluster in 14.540 seconds

2016-10-16 10:17:18.872:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb3 (3) missing for 50% of timeout interval. Removal of this node from cluster in 14.020 seconds

2016-10-16 10:17:18.872:

[cssd(18931)]CRS-1612:Network communication with node yxfkdb4 (4) missing for 50% of timeout interval. Removal of this node from cluster in 14.700 seconds

2016-10-16 10:17:25.875:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb3 (3) missing for 75% of timeout interval. Removal of this node from cluster in 7.010 seconds

2016-10-16 10:17:26.876:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb1 (1) missing for 75% of timeout interval. Removal of this node from cluster in 6.530 seconds

2016-10-16 10:17:26.877:

[cssd(18931)]CRS-1611:Network communication with node yxfkdb4 (4) missing for 75% of timeout interval. Removal of this node from cluster in 6.690 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb1 (1) missing for 90% of timeout interval. Removal of this node from cluster in 2.530 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb3 (3) missing for 90% of timeout interval. Removal of this node from cluster in 2.010 seconds

2016-10-16 10:17:30.878:

[cssd(18931)]CRS-1610:Network communication with node yxfkdb4 (4) missing for 90% of timeout interval. Removal of this node from cluster in 2.690 seconds

 

在集群日志alertyxfkdb2.log出现节点心跳丢失，2号节点和1，3,4号无法通讯，30S后2节点在2016-10-16 10:17:30.878:节点驱逐。

 

网络心跳丢失一般原因如下：

1、私网网络问题2、OCCSD进程以及其子进程无法调度3、OS BUG 4、数据库HANG

 

1、私网的心跳问题：通过部署了OSW，

 zzz ***Sun Oct1610:10:12CST2016

tracerouteto172.16.131.33 (172.16.131.33),30hopsmax,60bytepackets

 1 yxfkdb1-priv2 (172.16.131.33) 0.067ms 0.055ms 0.047ms

tracerouteto172.16.131.37 (172.16.131.37),30hopsmax,60bytepackets

 1 yxfkdb3-priv2 (172.16.131.37) 0.073ms 0.087ms 0.102ms

tracerouteto172.16.131.39 (172.16.131.39),30hopsmax,60bytepackets

 1 yxfkdb4-priv2 (172.16.131.39) 0.071ms 0.060ms 0.071ms

zzz ***Sun Oct1610:10:17CST2016

tracerouteto172.16.131.33 (172.16.131.33),30hopsmax,60bytepackets

 1 yxfkdb1-priv2 (172.16.131.33) 0.067ms 0.060ms 0.071ms

tracerouteto172.16.131.37 (172.16.131.37),30hopsmax,60bytepackets

 1 yxfkdb3-priv2 (172.16.131.37) 0.107ms 0.096ms 0.089ms

tracerouteto172.16.131.39 (172.16.131.39),30hopsmax,60bytepackets

 1 yxfkdb4-priv2 (172.16.131.39) 0.097ms 0.092ms 0.090ms

zzz ***Sun Oct1610:10:22CST2016

tracerouteto172.16.131.33 (172.16.131.33),30hopsmax,60bytepackets

 1 yxfkdb1-priv2 (172.16.131.33) 0.075ms 0.061ms 0.062ms

tracerouteto172.16.130.37 (172.16.130.37),30hopsmax,60bytepackets

connect:Networkisunreachable

tracerouteto172.16.131.37 (172.16.131.37),30hopsmax,60bytepackets

 1 yxfkdb3-priv2 (172.16.131.37) 0.121ms 0.092ms 0.101ms

tracerouteto172.16.130.39 (172.16.130.39),30hopsmax,60bytepackets

可以看到私网通讯正常，没有丢包发生。

 

2、OCCSD进程以及其子进程无法调度

在日志alertyxfkdb2.log和ocssd.log未发现not scheduled for等信息 

 

3、数据库HANG

可以看到AWR中CPU消耗很低，等待事件均正常，且平均等待时间大多数在0毫秒。AAS不到2个.

在AWR中可以发现数据库CPU ,AAS等值均正常。

2Q==

 

ZZ

 在DB ALERT和GI ALERT中可以看到是先发生节点驱逐，后导致实例重启。

1.     DB ALERT

Sun Oct 16 10:17:35 2016

NOTE: ASMB terminating

Errors in file /opt/oracle/diag/rdbms/sbycfkdb/sbycfkdb2/trace/sbycfkdb2_asmb_37372.trc:

ORA-15064: communication failure with ASM instance

ORA-03113: end-of-file on communication channel

Process ID:

Session ID: 1770 Serial number: 7

Errors in file /opt/oracle/diag/rdbms/sbycfkdb/sbycfkdb2/trace/sbycfkdb2_asmb_37372.trc:

ORA-15064: communication failure with ASM instance

ORA-03113: end-of-file on communication channel

Process ID:

Session ID: 1770 Serial number: 7

ASMB (ospid: 37372): terminating the instance due to error 15064

Instance terminated by ASMB, pid = 37372

Sun Oct 16 10:19:05 2016

Starting ORACLE instance (normal)

 

GI ALERT

[cssd(18931)]CRS-1610:Network communication with node yxfkdb4 (4) missing for 90% of timeout interval. Removal of this node from cluster in 2.690 seconds

2016-10-16 10:17:33.861:

[cssd(18931)]CRS-1608:This node was evicted by node 3,

数据库HANG的问题可以排除。

 

4、OS BUG

1.     在6.6 REDHAT内核2.6.32-504.el6.x86_64中存在一个BUG，进程存在无故HANG的情况，BUG具体描述如下：

“The impact of this kernel bug is very simple: user processes can deadlock and hang in seemingly impossible situations. A futex wait call (and anything using a futex wait) can stay blocked forever, even though it had been properly woken up by someone. Thread.park() in Java may stay parked. Etc. If you are lucky you may also find soft lockup messages in your dmesg logs. If you are not that lucky (like us, for example), you'll spend a couple of months of someone's time trying to find the fault in your code, when there is nothing there to find.”

 

RHEL 6 (and CentOS 6, and SL 6): 6.0-6.5 are good. 6.6 is BAD. 6.6.z is good.

RHEL 7 (and CentOS 7, and SL 7): 7.1 is BAD. As of yesterday. there does not yet appear to be a 7.x fix.  [May 13, 2015]

RHEL 5 (and CentOS 5, and SL 5): All versions are good (including 5.11).

 

 

这个BUG描述，用户进程在看似不可能的情况下出现死锁或者夯住，影响的版本是6.6和7.1。

 该BUG的修复在6.6.z中已经修复。

 综上分析：此次节点驱逐定位到OS的BUG,建议升级KERNEL来解决该问题。

 

四、解决办法

升级OS KERNEL解决OS的BUG

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31134212/viewspace-2127487/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31134212/viewspace-2127487/

congmo2314
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
心跳长时间missing，导致2节点被驱逐
az65381973的博客
02-15 947
当发现一个集群其中一个节点宕机，比如+ASM2在集群里offline，immediate，要重新拉起来所要做的步骤 一、停干净当前宕机节点集群/oragrid/app/11.2.0/grid/bin/crsctl stop crs -f  二、ps -ef |grep d.bin ----查看集群是否停干净，grep d.bin是因为有很多集群资源都是这个结尾的，例如 ohasd.bin,mdns...
circular-queue:Node.js的轻量级循环队列
05-16
循环队列 轻量级的循环队列，对于丢失陈旧数据比未经检查的内存增长更可取的情况很有用。 安装 克隆此存储库： $ npm install circular-queue 现在，实例化一个具有固定最大大小的队列： ... 'evict' -将过时
Oracle Clusterware Cannot Start on all Nodes: Network communication with node <NAME> missing for 90%
bruce
11-26 2002
Oracle Clusterware Cannot Start on all Nodes: Network communication with node missing for 90% of timeout interval (Doc ID 1507482.1) In this Document   Purpose   Troublesho
Oracle 12.2新特性 | 基于权重的节点驱逐
Enmotech的博客
01-26 827
前言在Oracle Clusterware需要从集群中逐出特定节点或一组节点的情况时，基于服务器权重的节点驱逐可充当断裂机制，通过服务器上的负载附加信息来识别要驱逐的节点或节点组。其中所有节点被驱逐的可能性是一样的。本课程视频，点击阅读原文即可下载基于权重的集群驱逐介绍基于权重的集群驱逐（Server Weight-Based Node Eviction）是一项Oracle 12.2版本引入的一项
遇到问题--k8s--pod的状态为evicted
热门推荐
直到世界的尽头
11-06 6万+
转载请注明出处：遇到问题–k8s–pod的状态为evicted 遇到问题 使用 kubectl get pods 发现很多pod的状态为evicted。 原因 eviction，即驱赶的意思，意思是当节点出现异常时，kubernetes将有相应的机制驱赶该节点上的Pod。 多见于资源不足时导致的驱赶。 更多详情参考 kubernetes的eviction机制 解决方案 排查资源和异常原因，防止新...
kubernetes清除状态为Evicted的pod
weixin_30894389的博客
01-04 1018
kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod 　　 清除脚本 #!/bin/bash for pod in $(kubectl get pods|grep Evicted|awk '{print $1}'); do kubectl delete p...
今天会是有Offer的一天么：面试时不要再问我LinkedHashMap了
12-21
- **双向链表**：LinkedHashMap的每个条目（entry）都是一个节点，该节点扩展了HashMap的Node类，并增加了before和after两个引用，分别指向当前节点的前一个节点和后一个节点。 - **属性详解**： - `head`：双向...
LRU.rar_LRU
09-14
Node* newNode = new Node{key, value, nullptr, list_.front()}; list_.front()->prev = newNode; list_.splice(list_.begin(), list_, newNode); hash_map[key] = newNode; } void evict() { hash_map....
lru.zip_visual c
09-20
Node* newNode = new Node{key, value, currentTime++, nullptr, nullptr}; cache[key] = newNode; addToListHead(newNode); } } private: int _capacity; int currentTime; std::unordered_map, Node*> ...
java基础类型源码解析之多角度讲HashMap
08-25
首先，HashMap的核心数据结构是`Node`数组，即`table`。每个`Node`代表一个存储位置，也称为“桶”。当一个键值对（Key-Value）加入HashMap时，会根据Key的哈希值来确定它应该存放在哪个桶中。桶的定义如下： ```...
一次kuberneets evicted的历险
weixin_30933531的博客
06-05 96
一、概述 　　kubernetes 的eviction检测diskpresure，检测的是kubelet的root-dir。kubelet的默认root-dir是/var/lib/kubelet,可以使用参数--root-dir进行修改，源码： kubernetes/cmd/kubelet/app/options/options.go const defaultRoot...
Oracle OS Watcher 工具 使用详解
David Dai -- Focus on Oracle
03-03 3万+
一.OSWatcher 说明OSWatcher 是Oracle 提供的一个用于操作系统监控的工具包，分Windows 和Linux 2个版本。 Linux 下的下载参考：OS Watcher Black Box UserGuide [ID 301137.1]Windows平台下载：OSWatcher For Windows (OSWFW) User Guide [ID 433472.1] 也可以从
mysql innodb monitor_MySQL 5.6 遭遇 OS bug INNODB MONITOR OUTPUT 事件
weixin_39606118的博客
01-19 253
We had this one bite us hard and scare the %$^! out of us, so I figured I'd share the fear...The linux futex_wait call has been broken for about a year (in upstream since 3.14, around Jan 2014), and h...
Kubernetes Pod Evicted
烧饼不夹蛋
05-14 3027
一、背景以及措施 近日 Kubernetes 测试集群 Pod 状态出现 Evicted 现象 , 但是项目还是能正常提供服务 , 最先的解决办法是手动将 Evicted 状态的 Pod 删除。 # 查看 Evicted 状态的 Pod [ops@dev-gate ~]# kubectl get pods -n staging-services | grep Evicted eureka-server-02-7f658c4dfc-zwtqk 0/1 Evicted
k8s 驱逐node节点
chuiyanyou9920的博客
08-07 4653
kubectl drain ip --delete-local-data --force --ignore-daemonsets kubectl uncordon ip 转载于:htt...
k8s节点状态Evicted被驱逐
cxclll的博客
06-23 1700
使用k8s搭建服务集群，发现有服务正常启动之后，过一会就被驱逐了 可以看到，容器被驱逐之后无限重启，一直都是失败，直到最后切换了节点才成功。被驱逐的节点，都是一台服务器172.16.0.32，我们看一下详情 上图是一个被驱逐节点的事件，红框标出来的意思是节点资源不足。问题很明确了，我们去看一下这台服务器的监控信息 发现这台服务器的磁盘使用率很高，k8s有种机制，当服务器磁盘使用超过85%之后就不允许节点再次创建了，所以节点创建之后就被驱逐了，目前这个云盘是40G，我们直接扩容一下。
记一次kubernetes Evicted的处理
saynaihe的博客
03-02 1236
背景： 事情这样的：kubernetes1.21.3集群。容器运行时containerd。除了K8s-node-06节点。 保留这个docker节点有很多原因。比如当时没有想好用什么打包镜像。默认让jenkins打包镜像。还有就是我的gitlab 10.8.7版本contarinerd运行时下无法启动。就保留了这个节点运行gitlab pod。当然了也把这个节点设置为了不可调度。不相其他应用调度到这个节点上来！最近一段时间gitlab应用频繁出现Evicted的问题： 这样就陷入了一个死循环：我的k8s-
k8s批量删除Evicted Pods
运维那些事儿
03-08 1万+
1、查询pod状态 [root@k8s_master prom]# kubectl -n kube-system get pods | grep Evicted coredns-67cb7b5f46-2crxg 0/1 Evicted 0 4h56m coredns-67cb7b5f46-2ds7n 0/1 ...
cache evict
最新发布
08-12
引用提供了清除缓存时具体执行的方法，即调用Redis缓存实现类的evict方法。在执行清除缓存方法时，可以在相应的方法处设置断点进行调试。 所以，"cache evict"是使用@CacheEvict注解进行缓存清除操作的一部分。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值