Exadata升级引发的新BUG

项目背景

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

具体情况如下：

[root@htdb01 ~]# dcli -g /tmp/cell_group -l root "df -h /"

htcel01: Filesystem Size Used Avail Use% Mounted on

htcel01: /dev/md5 9.9G 9.0G 0.9G 91% /

htcel02: Filesystem Size Used Avail Use% Mounted on

htcel02: /dev/md5 9.9G 9.0G 0.9G 91% /

......(略)

htcel10: Filesystem Size Used Avail Use% Mounted on

htcel10: /dev/md5 9.9G 5.0G 4.9G 51% /

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

问题分析

在处理这个故障之前，我们先来了解一下Exadata存储节点文件系统中的日志文件管理及删除策略。MS(ManagementServer)进程除了提供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%,说明一些大文件不在删除策略之内。

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

[root@htcel01 /]# du -sm * sort -rn head

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

下面，进一步查看/var/log/目录的内容：

[root@htcel01 log]# ls -l

total 5820

drwx------ 2 root root 4096 Mar 23 2016 aide

drwxr-xr-x 2 root root 4096 Dec 28 12:33 asrexacheck

drwxr-x--- 2 root root 4096 Nov 23 01:59 audit

-rw------- 1 root root 0 Nov 23 01:36 boot.log

-rw------- 1 root utmp 0 Jan 12 2017 btmp

drwxr-xr-x 7 root root 12288 Dec 28 15:56 cellos

-rw-r----- 1 root root 45 Dec 28 03:06 cellos.1.gz

-rw-r----- 1 root root 45 Dec 28 03:06 cellos.2.gz

drwxr----- 7 root root 4096 Dec 08 03:06 cellos.20171208_030611

drwxr----- 7 root root 4096 Dec 09 03:06 cellos.20171209_030609

drwxr----- 7 root root 4096 Dec 10 03:06 cellos.20171210_030607

drwxr----- 7 root root 4096 Dec 11 03:06 cellos.20171211_030605

drwxr----- 7 root root 4096 Dec 12 03:06 cellos.20171212_030603

drwxr----- 7 root root 4096 Dec 13 03:06 cellos.20171213_030607

drwxr----- 7 root root 4096 Dec 14 03:06 cellos.20171214_030602

drwxr----- 7 root root 4096 Dec 15 03:06 cellos.20171215_030609

drwxr----- 7 root root 4096 Dec 16 03:06 cellos.20171216_030607

drwxr----- 7 root root 4096 Dec 17 03:06 cellos.20171217_030614

drwxr----- 7 root root 4096 Dec 18 03:06 cellos.20171218_030615

drwxr----- 7 root root 4096 Dec 19 03:06 cellos.20171219_030620

drwxr----- 7 root root 4096 Dec 20 03:06 cellos.20171220_030617

drwxr----- 7 root root 4096 Dec 21 03:06 cellos.20171221_030621

drwxr----- 7 root root 4096 Dec 22 03:06 cellos.20171222_030615

drwxr----- 7 root root 4096 Dec 23 03:06 cellos.20171223_030610

drwxr----- 7 root root 4096 Dec 24 03:06 cellos.20171224_030609

drwxr----- 7 root root 4096 Dec 25 03:06 cellos.20171225_030618

drwxr----- 7 root root 4096 Dec 26 03:06 cellos.20171226_030615

drwxr----- 7 root root 4096 Dec 27 03:06 cellos.20171227_030616

drwxr----- 7 root root 4096 Dec 28 03:06 cellos.20171228_030610

-rw-r----- 1 root root 45 Dec 28 03:06 cellos.3.gz

-rw-r----- 1 root root 45 Dec 28 03:06 cellos.4.gz

-rw------- 1 root root 997009 Dec 28 18:20 cron

-rw-r----- 1 root root 99382 Nov 23 01:58 dmesg

-rw-r----- 1 root root 99626 Nov 23 01:52 dmesg.old

-rw-r----- 1 root root 199194 Nov 23 01:30 dracut.log

drwx------ 6 root root 4096 Dec 28 12:32 exadatatmp

-rw-r----- 1 root root 0 Nov 23 01:35 genlsisnmp.log

-rw-r----- 1 root root 292584 Dec 28 15:46 lastlog

drwxr-xr-x 6 root root 4096 Dec 28 03:06 lsidiag

drwxr-xr-x 2 root root 4096 Nov 23 01:29 mail

-rw------- 1 root root 2664 Dec 28 17:47 maillog

-rw------- 1 root root 1394626 Dec 28 18:01 messages

drwxr-xr-x 3 root root 4096 Dec 28 03:06 mrdiag

drwxr-xr-x 2 ntp ntp 4096 Sep 1 2016 ntpstats

drwxr-xr-x 7 root root 4096 Dec 28 18:20 oracle

-rw-r----- 1 root root 156 Nov 23 01:58 rdma_script.log

drwxr-xr-x 2 root root 4096 Dec 28 00:00 sa

-rw------- 1 root root 1012646 Dec 28 16:44 secure

-rw------- 1 root root 0 Nov 23 01:29 spooler

drwxr-xr-x 2 root root 4096 Nov 23 01:31 ssm

-rw------- 1 root root 64 Dec 28 16:44 tallylog

-rw-r--r-- 1 root root 6446 Dec 28 18:19 typescript

-rw-r----- 1 root adm 1942803 Dec 28 18:07 uptrack.log

-rw-rw---- 1 root utmp 12288 Dec 28 18:19 wtmp

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

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

[root@htcel08 log]# du -sm *

1 aide

1 asrexacheck

11 audit

0 boot.log

1 btmp

13 cellos

1 cellos.1.gz

21 cellos.20171114_200614

17 cellos.20171204_030626

17 cellos.20171220_030624

1 cellos.2.gz

1 cellos.3.gz

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

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

# Use the ten times size to force cleanup in case of issues from left over inhibitors of cleanup.

# Maximum size of /var/log/cellos/ directory in kb

declare -i SIZE_MAX=16384

declare -i TEN_TIMES_SIZE_MAX=163840

# do not clean up the /var/log/cellos if cell or databaser patch is in progress

if [ $size -gt $TEN_TIMES_SIZE_MAX ] ( [ $size -gt $SIZE_MAX ] && [ ! -e /etc/exadata/DISABLE_VAR_LOG_CELLOS_CLEANUP ] ); then

# copy old content to be rotated. Do not do a move it can break things.

datetime=$(date '+%Y%m%d_%H%M%S')

rm -rf $.$datetime

mkdir -p $.$datetime

cp -a $OCLOG/* $.$datetime

# preserve SerialNumbers file, any checkconfigs stuff and lock files and the ExaWatcher start up log that will get removed above

find $OCLOG \( -type f -a ! -name \*checkconfig\* -a ! -name \*\.lock -a ! -name SerialNumbers -a ! -name start_ExaWatcher.log \) xargs /bin/rm -f

# Rotate possible old logs

for ((rotate=$ROTATE_MAX; rotate > 1; rotate--)); do

rotate_minus_one=$((rotate - 1))

if [ -f $OCLOG.$rotate_minus_one.gz ]; then

rm -f $OCLOG.$rotate.gz

cp -f $OCLOG.$rotate_minus_one.gz $OCLOG.$rotate.gz

rm -f $OCLOG.$rotate_minus_one.gz

fi

done

# Archive first log

pushd /var/log >/dev/null

tar -czp --one-file-system -f cellos.1.gz cellos.old

popd >/dev/null

# Remove old dir

rm -rf $.old

fi

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

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

if [ $size -gt $TEN_TIMES_SIZE_MAX ] ( [ $size -gt $SIZE_MAX ] && [ ! -e/etc/exadata/DISABLE_VAR_LOG_CELLOS_CLEANUP ] );

表示：或 ；&& 表示：而且。

简单来说，就是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一体机用户组