【MOS】如何诊断 11.2 集群节点驱逐问题 (文档 ID 1674872.1)

简介: 【MOS】如何诊断 11.2 集群节点驱逐问题 (文档 ID 1674872.1) 文档内容 用途 适用范围 ...

【MOS】如何诊断 11.2 集群节点驱逐问题 (文档 ID 1674872.1)



文档内容

用途
适用范围
详细信息
  节点驱逐概要
  1.0 - 会导致重启的进程
  2.0 - 确认由哪个进程发起了重启
  3.0 - 诊断 OCSSD 发起的驱逐
  3.1 - OCSSD 驱逐的常见原因
  3.2 - OCSSD 驱逐时需要收集和查看的文件
  4.0 - 诊断 CSSDAGENT  或者 CSSDMONITOR 驱逐
  4.1 - CSSDAGENT 或者 CSSDMONITOR 驱逐的常见原因
  4.2 - CSSDAGENT  或者 CSSDMONITOR 驱逐需要收集和查看的文件
参考


适用于:

Oracle Database - Enterprise Edition - 版本 11.2.0.1 到 11.2.0.2 [发行版 11.2]
本文档所含信息适用于所有平台

用途

这篇文档提供了诊断 11.2 集群节点驱逐问题的参考方法。对于 11.2 之前的集群节点驱逐问题,请参考 Note: 265769.1

适用范围

受众范围是遇到了集群节点驱逐问题的 DBA 和技术支持工程师。

详细信息

节点驱逐概要

Oracle 集群在发现一些严重问题时会将一个或多个节点从集群中驱逐出去。这种严重问题包括节点没有网络心跳、节点没有磁盘心跳、服务器无响应或者有严重性能问题、或者 ocssd.bin 无响应。节点驱逐的目的是通过去除一些节点来维护整个节点的健康。

从 11.2.0.2 RAC (或者是 Exadata),节点驱逐也许并不会真正重启主机。这称为 rebootless restart。这种情况下,我们会重启大部分的集群进程来确认是否可以解决这台节点的问题。

1.0 - 会导致重启的进程


OCSSD (aka CSS daemon) - 这个进程由 cssdagent 进程所启动。对于使用第三方集群件和没有第三方集群件的环境都有这个进程。OCSSD 的主要作用是节点间的健康监控以及数据库实例的发现。健康监控包括网络心跳和磁盘心跳(针对选举盘)。OCSSD 在收到客户端(比如数据库的 LMON 进程)的 member kill escalation 请求后,也可以发起节点驱逐。OCSSD 进程是一个以 Oracle 用户身份运行的、多线程的、运行级别较高的进程。

  启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent --> ocssd --> ocssd.bin

CSSDAGENT - 这个进程由 OHASD 进程启动,CSSDAGENT 用于启动 OCSSD 进程,它可以监控节点 hang(类似于 oprocd),同时也监控 OCSSD 进程 hang(类似于 oclsomon ),而且还监控第三方集群件(类似于 vmon) 。这个进程是一个以 root 用户身份运行的、多线程的、运行级别较高的进程。

  启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdagent

CSSDMONITOR - 这个进程也会监控节点 hang(类似于 oprocd),同时也监控 OCSSD 进程 hang(类似于 oclsomon ),而且还监控第三方集群件(类似于 vmon) 。这个进程是一个以 root 用户身份运行的、多线程的、运行级别较高的进程。
  启动顺序: INIT --> init.ohasd --> ohasd --> ohasd.bin --> cssdmonitor

2.0 - 确认由哪个进程发起了重启

需要查看的重要的文件:

  • Clusterware alert log in <GRID_HOME>/log/<nodename>
  • The cssdagent log(s) in <GRID_HOME>/log/<nodename>/agent/ohasd/oracssdagent_root
  • The cssdmonitor log(s) in <GRID_HOME>/log/<nodename>/agent/ohasd/oracssdmonitor_root
  • The ocssd log(s) in <GRID_HOME>/log/<nodename>/cssd
  • The lastgasp log(s) in /etc/oracle/lastgasp 或者 /var/opt/oracle/lastgasp
  • IPD/OS 或者 OS Watcher data
  • GRID home 的'opatch lsinventory -detail'的输出
  • *Messages 文件:

* Messages 文件路径:

  • Linux: /var/log/messages
  • Sun: /var/adm/messages
  • HP-UX: /var/adm/syslog/syslog.log
  • IBM: /bin/errpt -a > messages.out
请参考下面的文档关于如何收集上述信息:

      Document 1513912.1 - TFA Collector - Tool for Enhanced Diagnostic Gathering


在大部分情况下,11.2 集群驱逐时会在集群的 alert log 中记录有意义的诊断信息。通过这些信息,可以确认是哪个进程发起了重启。下面是集群的 alert log 的样例:

[ohasd(11243)]CRS-8011:reboot advisory message from host: sta00129, component:  cssagent, with timestamp: L-2009-05-05-10:03:25.340
[ohasd(11243)]CRS-8013:reboot advisory message text: Rebooting after limit 28500 exceeded; disk timeout 27630, network timeout 28500, last heartbeat from CSSD at epoch seconds 1241543005.340, 4294967295 milliseconds ago based on invariant clock value of 93235653


这次驱逐是由于遇到了网络超时问题所导致。CSSD 进程退出后,CSSDAGENT 发起了重启。CSSDAGENT 是从 CSSD 的本地心跳相关的错误中获得了这些信息。

如果在被驱逐的节点的集群 alert log 中没有相关信息,请检查本节点的 lastgasp 日志,以及/或者其它节点的集群 alert log。

3.0 - 诊断 OCSSD 发起的驱逐


如果遇到了 OCSSD 发起的驱逐,请参考 3.1 章节列出的常见原因:

3.1 - OCSSD 驱逐的常见原因

  • 节点间的网络失败或者延迟。在连续的30秒(默认值,由 CSS misscount 决定)心跳不通后,会导致节点驱逐。
  • 无法读写 CSS 选举盘。如果一个节点无法完成对于大多数选举盘的磁盘心跳,节点会被驱逐。
  • Member kill escalation。比如,数据库实例的 LMON 进程可能会请求 CSS 将一个实例从集群中驱逐。如果实例驱逐超时,会升级为节点驱逐。
  • OCSSD进程发生错误或者hang,这种情况会由上面任何一种情况或者其它情况引起。
  • Oracle bug.

3.2 - OCSSD 驱逐时需要收集和查看的文件


在章节 2.0 所列出的所有节点的所有文件,也许还需要更多信息。

由于选举盘问题造成的驱逐的样例:

CSS log:

2012-03-27 22:05:48.693: [ CSSD][1100548416](:CSSNM00018:)clssnmvDiskCheck: Aborting, 0 of 3 configured voting disks available, need 2
2012-03-27 22:05:48.693: [ CSSD][1100548416]###################################
2012-03-27 22:05:48.693: [ CSSD][1100548416]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread



OS messages:

Mar 27 22:03:58 choldbr132p kernel: Error:Mpx:All paths to Symm 000190104720 vol 0c71 are dead.
Mar 27 22:03:58 choldbr132p kernel: Error:Mpx:Symm 000190104720 vol 0c71 is dead.
Mar 27 22:03:58 choldbr132p kernel: Buffer I/O error on device sdbig, logical block 0
...

 

4.0 - 诊断 CSSDAGENT  或者 CSSDMONITOR 驱逐


如果遇到了 CSSDAGENT 或者 CSSDMONITOR 驱逐,请参考章节4.1列出的常见原因。

4.1 - CSSDAGENT 或者 CSSDMONITOR 驱逐的常见原因

  • OS 调度问题。比如,OS 遇到了驱动、硬件问题或者主机负载太高 (CPU 100% 被使用)等问题,会导致 OS 调度异常。
  • CSSD 的一个或多个线程 hang。
  • Oracle bug.

4.2 - CSSDAGENT  或者 CSSDMONITOR 驱逐需要收集和查看的文件


章节 2.0 所列出的所有节点的所有文件,也许还需要更多信息。

 

参考

NOTE:1053147.1  - 11gR2 Clusterware and Grid Home - What You Need to Know
NOTE:736752.1  - Introducing Cluster Health Monitor (IPD/OS)
NOTE:1513912.1  - TFA Collector - Tool for Enhanced Diagnostic Gathering 


NOTE:301137.1  - OSWatcher (Includes: [Video])
NOTE:265769.1  - Troubleshooting 10g and 11.1 Clusterware Reboots





About Me

...............................................................................................................................

● 本文来自MOS

● 本文在itpub(http://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号(xiaomaimiaolhr)上有同步更新

● 本文itpub地址:http://blog.itpub.net/26736162/abstract/1/

● 本文博客园地址:http://www.cnblogs.com/lhrbest

● 本文pdf版及小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答:http://blog.itpub.net/26736162/viewspace-2134706/

● QQ群:230161599     微信群:私聊

● 联系我请加QQ好友(646634621),注明添加缘由

● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

...............................................................................................................................

拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号:xiaomaimiaolhr,扫描右边的二维码加入小麦苗的QQ群,学习最实用的数据库技术。

img_e3029f287d989cd04bd75432ecc1c172.png
DBA笔试面试讲解
欢迎与我联系

目录
相关文章
|
2月前
|
Kubernetes Perl 容器
K8s查看集群 状态事件描述以及Pod日志信息
K8s查看集群 状态事件描述以及Pod日志信息
86 3
|
12天前
|
Kubernetes API 调度
Pod无法调度到可用的节点上(K8s)
完成k8s单节点部署后,创建了一个pod进行测试,后续该pod出现以下报错: Warning FailedScheduling 3h7m (x3 over 3h18m) default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
50 0
|
2月前
|
Kubernetes 容器
k8s集群部署成功后某个节点突然出现notready状态的问题原因分析和解决办法
k8s集群部署成功后某个节点突然出现notready状态的问题原因分析和解决办法
68 0
|
7月前
|
Kubernetes Cloud Native 调度
k8s 服务升级为啥 pod 会部署到我们不期望的节点上??看来你还不懂污点和容忍度
k8s 服务升级为啥 pod 会部署到我们不期望的节点上??看来你还不懂污点和容忍度
|
12月前
|
存储 Prometheus Cloud Native
FinOPS之 节点内存态统计和计算Node-metrics
董江,容器技术布道者及实践者,中国移动高级系统架构专家,曾担任华为云核心网技术专家,CloudNative社区核心成员,KubeServiceStack社区发起者,Prometheus社区PMC,Knative Committer,Grafana社区Contributer。 欢迎关注:https://kubeservice.cn/
FinOPS之 节点内存态统计和计算Node-metrics
|
Arthas 监控 Java
一个迷惑性很高的生产故障-Elasticsearch日志rotate导致节点CPU激增
Elasticsearch CPU很高的场景很常见,优化读写以及扩容即可解决问题。 如果只有一个节点CPU高,那可能的情况就比较多了,节点机器异常?读写不均匀?GC过高?forcemerge? 这里描述一个极具迷惑性的case。
443 0
一个迷惑性很高的生产故障-Elasticsearch日志rotate导致节点CPU激增
|
Kubernetes 监控 网络协议
实验记录:PolarDB-X集群kill POD自动恢复实验
实验记录:PolarDB-X集群kill POD自动恢复实验
177 0
实验记录:PolarDB-X集群kill POD自动恢复实验
|
Kubernetes 算法 API
Node工作负载异常,一部分pod状态为Terminating
Node工作负载异常,一部分pod状态为Terminating
Node工作负载异常,一部分pod状态为Terminating