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

青衣

　　每天忙的博客都没时间更新，（近期会更新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）工作交接，处理过程，以及建议等后续问题。
　　

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