一台X4-2 的计算节点进行image升级，在正式升级之前利用LVM snapshot备份操作系统时备份失败，并且报大量IO错误，提示无法找到LVM snapshot的挂载点。检查文件系统状态：
[root@crmdb02 tar]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 30963708 15650472 13740372 54% / /dev/sda1 507748 38319 443215 8% /boot /dev/mapper/VGExaDb-LVDbOra1 103212320 23380548 74588892 24% /u01 tmpfs 264225792 726492 263499300 1% /dev/shm /dev/mapper/VGExaDb-lv_oradump 516061624 273275772 216571452 56% /oradump 10.1.32.196:/dsg2/arch/haitian/ 52071587840 33339427840 18732160000 65% /root/tar df: `/root/mnt/u01': No such file or directory |
发现无法找到/root/mnt/u01挂载点。
怎么在备份的过程中，挂载点突然就自动umount掉了呢？很奇怪，以前也没遇到过啊，还是先看看操作系统的message日志吧:
Nov 26 22:16:02 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 5865474 Nov 26 22:16:02 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:02 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 5898242 Nov 26 22:16:02 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:03 crmdb02 kernel: EXT3-fs error (device dm-7): ext3_get_inode_loc: unable to read inode block - inode=3276801, block=6553602 Nov 26 22:16:03 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 0 Nov 26 22:16:03 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): I/O error while writing superblock Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): error: ext3_journal_start_sb: Detected aborted journal Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): error: remounting filesystem read-only |
看到最新的message日志，心里不由地紧张了起来，I/O错误，还是写superblock时失败，不会这么点背吧，继续看message日志，看看刚出问题时，系统的错误日志，如下：
Nov 26 21:50:25 crmdb02 lvm[87105]: Monitoring snapshot VGExaDb-u01_snap Nov 26 21:50:44 crmdb02 kernel: EXT3-fs: barriers not enabled Nov 26 21:50:44 crmdb02 kernel: kjournald starting. Commit interval 5 seconds Nov 26 21:50:44 crmdb02 kernel: EXT3-fs (dm-10): using internal journal Nov 26 21:50:44 crmdb02 kernel: EXT3-fs (dm-10): mounted filesystem with ordered data mode Nov 26 22:10:28 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 80% full. Nov 26 22:11:58 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 85% full. Nov 26 22:13:18 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 90% full. Nov 26 22:14:38 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 95% full. Nov 26 22:15:53 crmdb02 kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception. Nov 26 22:15:53 crmdb02 lvm[87105]: Unmounting invalid snapshot VGExaDb-root_snap from /root/mnt. Nov 26 22:15:53 crmdb02 kernel: EXT3-fs error (device dm-7): ext3_get_inode_loc: unable to read inode block - inode=2965505, block=5931010 Nov 26 22:15:53 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 0 Nov 26 22:15:53 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:15:53 crmdb02 kernel: EXT3-fs (dm-7): I/O error while writing superblock |
从22：10分开始，系统提示snapshot VGExaDb-root_snap已经占用了80%的空间。22：14分后，snapshot占用近100%，接着就出来大量的IO错误。到了这里，我基本上就知道整个故障的原因了，由于大量的文件变化占用了snapshot，导致划分的1GB的snapshot空间占满，从而自动将文件系统unmount掉。
现在需要解决的是，/(根)文件系统中怎么会出现这么大的文件变化，能在很短的时间内就撑爆1GB的snapshot空间。这些文件变化肯定不是操作系统自己产生的，操作系统自身不会有这么大的文件变化。以前对其他客户的Exadata也备份过很多次，还从没遇到过这种故障。我此时的第一反应是可能存在定时任务，如果定时任务写了日志文件，则很可能会出来这样的情况。
立即检查操作系统用户的crontab情况，发现了如下内容:
[oracle@crmdb02 ~]$ crontab -l 0 * * * * /home/oracle/weihu/scripts/check_db_status.sh >> /home/oracle/weihu/scripts/check_db_status.log 2>&1 & [oracle@crmdb02 ~]$ |
Oracle用户下的确存在定时任务，且该脚本为每分钟执行一次，把输入追加到/home/oracle下的check_db_status.log文件中，而这个文件其实就是/(根)文件系统中。
最终，注释该定时任务，重建该lvm snapshot，重新开始操作系统备份，一切顺利，成功备份完操作系统。