solaris平台11gR2 RAC节点异常重启案例分享

Bertha 。 2023-10-04 22:53 18阅读 0赞

客户solaris平台上的一套11.2.0.4 RAC近日连续2次重启，原来也会重启，最近频率偏高，要求调查一下原因。

<因为现场在客户环境中做的操作，有些日志和命令输出只能找类似的放在文章中。solaris不熟，除了unix通用的命令外一无所知，很多命令在现场上网查。>

故障时间点，在/var/adm/messages中有panic, crash dump的相关信息，检查/var/crash目录下有生成dump，序号已经到了38（说明这是个老问题）。这些dump文件是压缩文件，执行savecore -f dumpfile.38后，得到vmcore.38和unix.38文件，这个和AIX KDB工作原理一样。

执行mdb -k 38调入当日的crash dump文件，::msgbuf没有超出messages的额外信息；::memstat显示大约还有30G的剩余内存，所以不像是内存耗尽；::ps看没有状态异常的进程；$c查看故障线程的堆栈，大概是类似下面的信息：

d50a2f4c genunix:kadmin+10c (5, 0, 0, db325400)

d50a2f84 genunix:uadmin+8e (5, 0, 0, d50a2fac, )

查了一下，这是手工发起crash dump的调用堆栈，类似AIX的sysdumpstart命令，进一步查::cpuinfo -v发现导致panic的进程是cssdagent（实际上可以用<kthread\_t的地址>::thread子命令直接看，因为在文章的下面，没用上:-(）。现在明了了，服务器的异常重启是Oracle Cluster进行fence的结果。

查看节点的cssdagent日志，没有异常信息，但是在对端节点上的群集alert文件中有下面的信息（非原始信息）：

\[ohasd(11243)\]CRS-8011:reboot advisory message from host: racnode01, 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

这说明节点1因为心跳超时导致驱逐，上面cssdagent没有日志，可能是没有来得及写入到日志文件？

如果真的是网络方面的原因，节点2上应该也有告警，而节点1上也应该有渐进的心跳丢失提示，所以比较合理的解释是，节点1当时出现性能过载，或者个别高优先级的异常进程占据了CPU不释放，导致cluster心跳侦测线程无法获得调度执行，引发超时，包括其他写入日志文件的线程也均受到干扰无法完成执行。

针对这个思路，两个解决方案：

1.   避免这种异常情形的出现，这种高优先级的进程通常是IO相关，例如在核心层运行的磁盘驱动，客户环境比较复杂，IBM和曙光的存储并存，不排除存在驱动程序Bug或者冲突导致IO挂起、性能异常。从数据库软件层面，我们尽量避免突发的IO访问触发这种异常，建议关闭direct path read，现场我们用alter system set "\_serial\_direct\_read"=never scope=both sid='\*'动态关闭。
2.   可以考虑增加心跳侦测的超时时间，让群集对隔离驱逐更迟钝一些，事后查了一下，在10.0.1 with Fix for unpublished Bug 4896338之后主要是2个参数控制：
    
    1.   misscount（MC）控制网络超时，默认是30秒；
    2.   disktimeout（DTO）控制到vote disk的访问超时，默认是200秒。

其中对misscount/disktimeout的修改，需要停止群集的其他节点，用crsctl set css misscount|disktimeout <newvalue>进行修改。