码迷,mamicode.com
首页 > 其他好文 > 详细

Exadata LVM snapshot备份失败

时间:2017-12-07 19:05:08      阅读:212      评论:0      收藏:0      [点我收藏+]

标签:order   group   nal   invalid   amp   遇到   重建   files   exce   

一台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,重新开始操作系统备份,一切顺利,成功备份完操作系统。

Exadata LVM snapshot备份失败

标签:order   group   nal   invalid   amp   遇到   重建   files   exce   

原文地址:http://www.cnblogs.com/missyou-shiyh/p/8000236.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!