您现在的位置是:首页 > 文章详情

一次核心线上磁盘差点爆满坑人事件...

日期:2017-08-26点击:373

每天忙的博客都没时间更新,(近期会更新rac,ods等方面)此刻的我可以下班了(夜班一周一两次吧),因为换了工作,对整体系统架构及业务都没特别熟悉。本想现在回家休息,可是心情不怎么美丽,刚刚经历了一场核心磁盘差点爆满事件,有点不痛快,吐槽一下,也算是分享一下自己的经验吧!


情况是这样的:

夜晚做一个核心跑批(涉及到几万用户的账户资金扣款,不容出错),在二次逻辑导库(Oracle)的时候,突然接到数据中心的电话,两台 主机1 主机2 应用服务器下的/fns目录96%了,说可不可以快点清理一下。(数据中心有集中式监控,但是操作大部分我们处理,何况是夜晚,技术支持不在)


于是尽快排查,因为应用服务不知道root,而且磁盘空间都很紧张,权限很严格。找到数据库备份目录后,判断了一下dmp文件大小,当前备份增长很快,一会儿%98了。还有8G空间,但是根据备份文件比较,还有20G才备份完。此刻和时间赛跑...

不爽1:

1)%96了才告警,这不是坑人么,阈值怎么设置的啊!

2)核心应用恰好在导库,删错东西,影响批扣,领导肯定不高兴,甚至追责任。


目前发现仅仅/tmp下有可怜的空间,和数据中心打电话问有没有之前备份,貌似不是和数据库相关的人值班,给不了我确切答案,想和领导打电话确认可不可以临时删除之前备份,电话不通。

不爽2:

1)为什么磁盘空间那么小,真的怀疑我在操作假的核心服务器,短时间还扩容不了。(机房异地)

2)直属领导联系不通,虽然知道有上个月的归档,但是没得到允许不敢删除啊。


于是告诉自己冷静,冷静。此刻只剩下4G空间,如果影响批量,就麻烦了。紧急在/tmp下创建临时目录,将一些dmp.gz mv过去,剩余空间在增长(gz文件 2-3G,dmp文件,40-50G),还好先缓解一下,但是我得至少腾出20G,才能解决问题。想想可不可以用tar 压缩,然后加参数删除源文件,刚执行压缩到tmp下,立马觉得不行,ctrl+c,同时立刻报警 /tmp 使用率 %100。因为文件太大了。

不爽3:

1)脚本被修改,为什么没有接到通知,临时压缩有风险啊 哎。。。

2)脑子已经不敢确定xz gzip tar压缩,压缩过程会不会有临时处理文件,那样死的更快。


两台应用挂载同一个目标主机盘,gpfs文件系统格式,还没有确定用的什么方式挂载。(nfs或者其它),但是我已经没时间想这些了,空间又不够了 %98了。先在/tmp下创建临时目录,缓解一下压力。

评估了一下,两个/tmp各分担一下,恰好批量完成,剩下4G空间。

不爽4:

1)如果两台tmp空间不够的话,大家如果是我怎么办?(后期尝试密码碰运气进入oracle用户进去了)


此刻,批量完成,心里松了口气。看着可怜的4G空间,心里不知道该说些什么。然后我想了一下,gzip,xz压缩是应该可以的(因为之前从来没有遇到过磁盘空间不够的情况,没深入理解这两个命令压缩原理),压缩之后,空间恢复。

不爽5:

1)脚本被修改没通知,领导肯定会问。不确定是不是同事,还是厂家 哎。。。万一是前者,又涉及到    工作没交接清楚问题,我也不好说。

2)因为和领导打了电话,领导肯定会问情况,还没想好怎么说。

3)工作交接,处理过程,以及建议等后续问题。


然后,我困了,要回家休息了,也许这只是一个意外吧!不知道大家遇到这种情况,该怎么处理!因为公司东西是机密,不可以透露,这里仅仅分析我的个人经历吧,个人情感,经验博客,谢绝转载!

原文链接:https://blog.51cto.com/renzhiyuan/1959660
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章