Exadata升级引发的新BUG

项目背景

一套X4-2半配的Exadata,因为存储空间不够,新增了三台X6的存储节点,同时将存储软件版本升级到了12.1.2.3.4,升级完成一段时间后发现以前X4-2的7台存储节点的/根文件系统使用率超过90%,而新增的三台X6存储节点不受影响。

具体情况如下:

从以上命令输出可以看出,以前X4的几台存储节点的/根文件系统使用率的确非常高,而新增的三台X6存储节点的/根文件系统不受影响。

问题分析

在处理这个故障之前,我们先来了解一下Exadata存储节点文件系统中的日志文件管理及删除策略。MS(Management Server)进程除了提供Exadata存储服务器配置的功能之外,还会负责存储服务器上日志的删除操作。

当存储节点的文件系统使用率比较高时会触发文件删除策略,不同的文件系统触发文件删除策略的比例不同。例如:/根文件系统和/var/log/oracle文件系统的触发标准为该文件系统的使用率达到80%,而/opt/oracle文件系统的触发标准为该文件系统的使用率达到90%。删除策略具体如下:

  • /var/log/oracle文件系统,简单来说,在ADR、LOG_HOME 和METRIC 目录下的文件会基于一定的规则删除,直到文件系统系统的使用率低于75%。
  • /opt/oracle文件系统的删除策略类似于/var/log/oracle文件系统,直到文件系统系统的使用率低于85%。
  • 对于/根文件系统,cellmonirot和celladmin用户主目录中的文件、/tmp、/var/crash和/var/pool目录中那些超过5MB的一天前的文件将被删除。

从以上的删除策略可以看出,对于存储节点的/根文件系统,当文件系统使用率超过80%时,就应该删除相应的日志文件,但目前的文件系统使用率仍然超过90%,说明一些大文件不在删除策略之内。

下面,使用命令检查存储节点的/根文件系统里每一个目录占用的大小:

通过以上命令,可以看检查/根文件系统内每个子目录占用的空间,最终确认是/var/log/目录占用了绝大部分空间,导致/根文件系统使用率超过90%。

下面,进一步查看/var/log/目录的内容:

从以上的命令输出可以看出有大量的cellos.*日期结尾的目录,而且很有规律,每天一个目录,都是在凌晨3点产生。

查看新增的三台存储节点的/var/log/目录的内容:

这新增的三台存储节点的/var/log/目录中也有这个cellos目录的备份,只是它并不是每天都进行了备份,同时该备份的目录也非常小,才20MB左右。

这里其实有一个知识点,那就是这些目录是由/etc/cron.daily/cellos脚本产生的,下面,我们直接看这个脚本内容,以下内容为截取的一部分内容:

从这部分代码可以看出,只是将/var/log/cellos目录中的内容复制到一个以cellos.开头,日期结尾的新目录中,但没有删除以前备份的目录,造成cellos目录的备份越来越多,最终导致/根文件系统使用率接近100%。

我们继续来看这段代码,cellos目录的备份其实是有触发条件的,也即那条if条件判断。

|| 表示:或 ;&& 表示:而且。

简单来说,就是cellos目录的大小如果大于163840KB,或者cellos目录的大小如果大于16384KB同时不存在/etc/exadata/DISABLE_VAR_LOG_CELLOS_CLEANUP文件,则进行备份工作。

检查发现,X4老存储节点上的/var/log/cello目录在160MB左右,而新X6新存储节点上的/var/log/cellos目录在12MB左右,所以X4老存储节点上每天都会备份,而X6新存储节点只是偶尔备份。

针对该问题,已经在存储软件12.1.2.3.5版本中修复,cellos目录的备份只会保留几份,多余的会进行删除。在12.1.2.3.4版本中,只能手动删除这些备份目录。

未经允许不得转载:Oracle一体机用户组 » Exadata升级引发的新BUG

相关推荐