记一次删除大文件后磁盘大小异常的故障

起因

日前,收到监控系统邮件告警,告知MySQL备份盘磁盘可用率不足20%,故而通过SSH远程上去,发现是因为保留的备份数据副本(全备)过多的原因,因为手动删除了较早的全备副本,然后,惊奇的是,几分钟后磁盘可用比仍居高不下,故进行故障排查。

处理过程

检查磁盘相关信息

  • 查看磁盘空间大小,我们发现输出的备份盘已用2.2T,可用0
[root@bogon bak]# df -HT
Filesystem           Type     Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                     ext4      28G   24G  3.1G  89% /
tmpfs                tmpfs    4.2G  2.2G  2.0G  52% /dev/shm
/dev/sda1            ext4     500M   42M  432M   9% /boot
/dev/mapper/bak_vg0-bak_lv0
                     ext4     2.2T  2.2T     0 100% /bak
/dev/sr0             iso9660  3.9G  3.9G     0 100% /media/RHEL-6.8 Server.x86_64
  • 查看Inode信息(磁盘空间告警实质上和Inode并无直接关系,如若Inode不足,将触发Inode节点不足告警,这里仅是排查步骤和习惯的问题)
[root@bogon bak]# df -i
Filesystem              Inodes  IUsed     IFree IUse% Mounted on
/dev/mapper/VolGroup-lv_root
                       1738080 208630   1529450   13% /
tmpfs                  1007800    279   1007521    1% /dev/shm
/dev/sda1               128016     39    127977    1% /boot
/dev/mapper/bak_vg0-bak_lv0
                     131072000     20 131071980    1% /bak
/dev/sr0                     0      0         0     - /media/RHEL-6.8 Server.x86_64
  • 检查数据备份盘,查看备份数据大小,输出显示使用中的备份盘大小为1.0T
[root@bogon bak]# du -sh /bak/
1.0T    /bak/

查看异常进程

lsof被誉为Unix/Linux界的瑞士军刀,其用于查看哪些文件被哪些进程所打开,又因lsof需要访问核心内存和各种文件,因此需要root用户或具有执行该命令权限的sudo用户执行。 注:在Unix/Linux中,一切皆文件,故这里的文件包括硬件设备所对应的文件描述符和TCP/UDP端口等

[root@bogon bak]# lsof | less
COMMAND     PID      USER   FD      TYPE             DEVICE      SIZE/OFF                 NODE NAME
init          1      root  cwd       DIR              253,0          4096                    2 /
init          1      root  rtd       DIR              253,0          4096                    2 /
init          1      root  txt       REG              253,0        150352               913981 /sbin/init
init          1      root  mem       REG              253,0         66432              1305647 /lib64/libnss_files-2.12.so
init          1      root  DEL       REG              253,0                            1305631 /lib64/libc-2.12.so
init          1      root  DEL       REG              253,0                            1305602 /lib64/libgcc_s-4.4.7-20120601.so.1.#prelink#.e8mfMB
init          1      root  DEL       REG              253,0                            1305659 /lib64/librt-2.12.so
init          1      root  DEL       REG              253,0                            1305655 /lib64/libpthread-2.12.so.#prelink#.CEboiG
init          1      root  DEL       REG              253,0                            1305681 /lib64/libdbus-1.so.3.4.0.#prelink#.ACI0Uelsof
  • 过滤备份盘关键字,我们发现有4条打开备份盘相关文件的进程被标记为deleted的记录
[root@bogon bak]# lsof | grep /bak
bash       1692      root  cwd       DIR              253,2          4096                    2 /bak
su         1718      root  cwd       DIR              253,2          4096                    2 /bak
bash       5190      root  cwd       DIR              253,2          4096                    2 /bak
lsof       5332      root  cwd       DIR              253,2          4096                    2 /bak
grep       5333      root  cwd       DIR              253,2          4096                    2 /bak
lsof       5334      root  cwd       DIR              253,2          4096                    2 /bak
bash      16311    oracle  cwd       DIR              253,2          4096                    2 /bak
bash      24371      root  cwd       DIR              253,2             0             64618497 /bak/dumpbak (deleted)
su        29121      root  cwd       DIR              253,2             0             64618497 /bak/dumpbak (deleted)
oracle    29334    oracle   25w      REG              253,2          1078             64618500 /bak/dumpbak/import.log (deleted)
oracle    29336    oracle   35u      REG              253,2 1014089334784             64618498 /bak/dumpbak/expdp-20190302.dmp (deleted)
  • 将这些名义上的活动进程Kill掉(实质上已是僵尸进程)
[root@bogon bak]# kill -9 24371 29121 29334 29336
  • 再次查看打开备份盘相关文件的进程,我们发现已不再存在标记为deleted的记录
[root@bogon bak]# lsof | grep /bak
su         1718      root  cwd       DIR              253,2      4096                    2 /bak
bash       5190      root  cwd       DIR              253,2      4096                    2 /bak
lsof       5344      root  cwd       DIR              253,2      4096                    2 /bak
grep       5345      root  cwd       DIR              253,2      4096                    2 /bak
lsof       5346      root  cwd       DIR              253,2      4096                    2 /bak
bash      16311    oracle  cwd       DIR              253,2      4096                    2 /bak
  • 再次检查系统磁盘信息,可用剩余磁盘可用比为36%,故障排除,监控告警恢复正常
[root@bogon bak]# df -HT
Filesystem           Type     Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                     ext4      28G   24G  3.1G  89% /
tmpfs                tmpfs    4.2G  2.2G  2.0kG  52% /dev/shm
/dev/sda1            ext4     500M   42M  432M   9% /boot
/dev/mapper/bak_vg0-bak_lv0
                     ext4     2.2T  1.3T  723G  64% /bak
/dev/sr0             iso9660  3.9G  3.9G     0 100% /media/RHEL-6.8 Server.x86_64

总结

  • 当进程意外被杀死,或临时删除较大体积的文件时,系统获取最新磁盘信息可能会有一定出入,此时应结合监控系统,深入排查,通过lsof或组合使用ps命令,发现异常进程,以此来排除故障,解决问题。
  • 无监控,不运维。不难看出,监控是整个运维乃至整个产品生命周期中最重要的一环。事前及时预警发现故障,事后提供详实的数据用于追查定位问题,监控已不再是可有可无的技能,而是与运维职业身份息息相关。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券