假日期间常见的数据库磁盘空间处理小结

　　数据库的报警可以拆分为很多类别，但是有一点是无论如何都跑不掉的，而且花样百出，那就是磁盘空间报警。
　　在我的认知中，磁盘空间报警可以从上向下，从下向上的看待，如果从下向上看待，磁盘空间类报警的处理方法相对比较简单，只要分析了空间使用瓶颈，合理处理是按部就班的事情，重复度较高，难度适中，见效快。而从上向下看待，磁盘空间类报警是我们必须要搞定的一场硬仗，因为系统类报警，CPU，内存，磁盘，其中CPU,内存类报警的原因都不太明朗，需要做更进一步的分析，而处理方法则需要结合业务的改造或者系统层面的调整优化才能见效，磁盘类报警则相对来说属于性价比较高的，对于运维侧的需求则需要更进一步，那就是在重复度，复杂度的平衡中找到一种普适的处理办法，能够将这部分工作逐步的通过自动化方式处理，也就是从处理故障变为故障自愈模式。
　　在节假日碰到磁盘报警是一种煎熬，如果已经在旅行途中，收到一条报警短信就像吃了苍蝇一样难受，大体有如下的一些处理方式：
　　一.系统层预处理：
　　在节假日前，我们一般会做两类工作：
　　第一类是做系统的全面巡检，主要涉及如下的几个指标，我们会汇总为一个指标巡检大盘：
　　1）磁盘空间使用率，拆分为根目录使用率和数据目录使用率
　　2）内存使用率
　　3）CPU使用率
　　4）inode使用率
　　5）系统负载情况
　　6）数据库延迟
　　这份指标能够发现绝大多数明显的问题，基本扫清之后就能够杜绝大部分的隐患。
　　第二类工作，我们会把监控报警的阈值降低，比如磁盘空间的阈值为80%~85%左右，一般会降为75%左右，这样可以把一部分潜在的隐患也一并处理掉。
　　如此一来能够杜绝大部分硬伤的报警，当然这个工作的潜在问题就是人工干预较为明显，如果能够做自动适配和指标回置，整个过程会更加有弹性。
　　二.系统层处理
　　系统层处理的硬伤问题相对比较少，主要碰到几类：
　　1）查看系统层的空间使用异常，但是进程没有释放相关的句柄，导致空间没有彻底释放。
　　比如一个nohup任务生成的日志比较大，我们手工删除了生成的日志文件，但是空间却没有释放，一般来说，可以使用lsof来得到相关的句柄的明细，也可以看到磁盘空间占用较高的文件对应的进程，顺着这条线分析，
　　常用的命令为：lsof|grep deleted ，即可查找相关的进程
　　2）inode异常，inode异常会导致很多奇怪的问题，比如数据分区无法写入文件，数据库无法登陆等，有一部分原因是crontab产生的大量碎片文件导致，可以通过如下的路径：
　　/var/spool/postfix/maildrop
　　/var/spool/clientmqueue/
　　来进行快速的清理。
　　如果文件较多，可以使用xargs分批删除
　　# ls -l 2020*|wc -l
　　-bash: /bin/ls: Argument list too long
　　0
　　可以采用-n选项
　　ls | xargs -n 20 rm -f
　　如果数量达到一定程度依然会报错，可以使用find+xargs的组合方式。
　　如下效果较为稳定，可以根据find的通配模式进行匹配清理。
　　find . -name ＂20200825*＂ | xargs rm -f ＂20200825*＂
　　三.数据库层处理
　　数据库层的清理可做的空间相对比较大，前提是你给自己预留的空间要足够大，否则坑足够大处理起来会比较纠结。
　　1）binlog配置和清理
　　binlog的配置主要有参数expire_logs_days控制，如果出现空间问题，而且我们确认了主从复制等基本配置，就可以调整expire_logs_days的配置，比如从7天调整为3天等。
　　如果binlog在短时间内产生的数量比较大，参数的控制已经满足不了了，则可以使用purge binary logs to ＂xxx＂的方式进行快速处理，当然处理的核心都是主从延迟情况。
　　如果因为主从延迟较大，则可以专注于处理延迟的一些临时配置，比如双1配置调整，并行复制线程等配置。
　　2）回收站
　　数据库回收站模式在MySQL中是没有的，不代表我们不需要做，有很多敏感的数据清理任务造成的影响都具有延迟性，比如数据清理之后几天之后业务侧需要用的时候才会找过来，当然这个过程的敏感度可以更快一些，但是不能作为我们无法处理的借口。
　　数据库的回收站在MySQL的基本原理就是移形换位，把一张表通过renmae的方式快速的转移到一个独立的归档库下面，比如test_arch，在这个数据库中的表可以按照时间顺序进行数据清理，这样表中的数据就可以保存的时间就更长了，我印象中处理最长的数据是一个月，整个恢复的工作都是秒级，着实让业务同学目瞪口呆。
　　3）InnoDB表格式row_format修改为compressed
　　如果有些数据表存放的是日志数据，而且日志数据出现了爆发式增长，那么一种快速的适配方法就是使用compressed的数据格式，经过测试，在有些场景下的压缩率达到了近50%，而且查取效率依然很高，对于存储方面的收益更高，比如一个业务的数据保留需要控制在2个月，一种方式是扩容一倍的存储空间，一种是开启compressed模式，在我们已验证的业务场景中算是取得了初步的效果。
　　你们还有什么方法可以避免磁盘空间类问题的窘状，欢迎留言。