11月云和恩墨技术通讯：OCR无法正常读取导致节点宕机
墨墨导读：为了及时共享行业案例，通知共性问题，达成共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。
墨天轮文档：《云和恩墨技术通讯（11月刊）》：https://www.modb.pro/doc/6950
这里推荐一个常见的问题，希望对大家有借鉴作用。
故障：OCR无法正常读取导致节点宕机-陆发圣
“OCR存储了所有与集群，RAC数据库相关的配置信息。并且这种配置信息都是多个节点进行共享。所以OCR会存放在共享磁盘上。OCR包含了节点成员信息，数据库实例，节点，以及其他映射关系，资源配置信息等。本文主要介绍的是OCR磁盘异常，导致节点宕机。
1. 问题概述
数据库系统节点1集群资源突然故障，在通过重启集群资源也未能恢复（无法找到表决磁盘）。
2. 过程分析
2.1 故障根源
通过与主机工程师的交流和日志分析，由于hba光纤口断掉，而且由于主机上只配了一块HBA卡，没有冗余，从而导致主机无法与存储磁盘正常通信。因此节点1无法读取OCR表决盘，导致节点1集群资源宕机，从而引发数据库意外宕机。
|
Nov 16 10:04:33 gzfpdb1 kernel: rport-1:0-2: blocked FC remote port time out: removing target and saving binding Nov 16 10:04:33 gzfpdb1 kernel: lpfc 0000:0e:00.0: 0:(0):0203 Devloss timeout on WWPN 50:00:00:e0:d4:6f:2d:80 NPort x010500 Data: x0 x8 x0 |
3. 日志分析
3.1 数据库日志
在16日10点04分33秒数据库无法正常对磁盘组GROUP 1的DISK 0正常进行读操作：
|
Mon Nov 16 10:04:33 2020 WARNING: Read Failed. group:1 disk:0 AU:4247 offset:0 size:1048576WARNING: Read Failed. group:1 disk:0 AU:40598 offset:0 size:1048576 |
随后也出现大量IO报错：
|
ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 5: Input/output error Additional information: -1 Additional information: 8192 Errors in file /u01/app/oracle/diag/rdbms/gzfpdb/gzfpdb1/trace/gzfpdb1_dbw6_22402.trc: ORA-15080: synchronous I/O operation to a disk failed ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 5: Input/output error Additional information: -1 Additional information: 8192 Errors in file /u01/app/oracle/diag/rdbms/gzfpdb/gzfpdb1/trace/gzfpdb1_dbw2_22394.trc: ORA-15080: synchronous I/O operation to a disk failed ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 5: Input/output error Additional information: -1 Additional information: 8192 Errors in file /u01/app/oracle/diag/rdbms/gzfpdb/gzfpdb1/trace/gzfpdb1_dbw0_22390.trc: ORA-15080: synchronous I/O operation to a disk failed ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 5: Input/output error Additional information: -1 Additional information: 8192 |
于16日10点04分34秒基于自我保护机制，集群自行杀掉了DBWR进程，因此数据库宕机：
|
Mon Nov 16 10:04:34 2020 ORA-1092 : opitsk aborting process Instance terminated by DBW7, pid = 22404 |
3.2 系统日志
同样是10点04分33秒，磁盘:sdc、sdd、sde存在大量I/O错误：
3.3 集群告警日志
无法找到表决磁盘，导致集群无法正常启动：
3.4 故障处置
确认了数据库已经异常宕机的前提下，于10点57分左右进行了主机重启，主机启动完毕之后11点00分集群随主机启动，之后数据库于11点00分37秒恢复正常：
|
Mon Nov 16 11:00:37 2020 QMNC started with pid=51, OS id=7015 Completed: ALTER DATABASE OPEN * db agent *//* {1:41562:2} */ |
4. 根本解决方案
故障根本原因为：节点1表决磁盘无法正常读写导致节点1集群异常宕机；
临时解决方法：重启1节点主机，集群、数据库恢复正常；
建议：重要系统应配置双HBA卡、双网卡、双电源等冗余配置，避免这些组件成为单点故障来源。
墨天轮文档：《云和恩墨技术通讯（11月刊）》：https://www.modb.pro/doc/6950