MySQL空间报警后的一揽子解决方案
这是学习笔记的第 2261 篇文章
读完需要
5
分钟速读仅需7分钟
昨天下午的时候，收到一条报警信息，提示是一个异机房的从库出现了磁盘空间问题，这类问题看起来蛮好处理的，空间不够清理就是了，比如清理binlog,比如清理一些周期表等等。
但是在经过分析之后，发现这个问题比预想的要严重。
这是一套一主两从的环境，Slave2的配置相对较低，存储配置也略低一些，目前发生了磁盘空间的报警。
经过分析发现，原来是里面的一张表的数据量有了很大的变化，之前相对来说比较稳定，每天会生成50M~100M左右的数据，但是从近几天来看，数据量翻了好几百倍，每天乎有20~30G左右的数据写入，这样一来原来的存储模式就显得捉襟见肘了。
怎么处理呢，一种模式就是磁盘扩容，这个时候我和业务侧做了沟通，准备细致了解一下。大体的需求是因为一些业务调整，需要记录的数据内容更全更丰富了，而这也是最近的一个新需求（此处的一个明显问题就是这个需求竟然和DBA没有任何沟通），因为目前采用的是日表，日表的保留周期是20天左右，最后能存储1个月，而从业务使用的角度来说，长期来看希望保留半年，这样一个需求，在目前的情况下几乎是不可实现的。 我们来简单算算，如果是保留20天，那么就需要至少600G以上的空间，外加一些冗余空间，差不多得在700~800G左右，而如果保留1个月就需要1T左右，而如果保留半年就需要大约6T左右。
所以脑海里闪出几个方案：
1）对InnoDB的表进行压缩存储，压缩率高的话差不多能有40~50%左右，但是不能根本解决问题
2）使用数据库+数据仓库结合的方案，比如MySQL+Infobright的方案，MySQL中保留近2天的数据，数据按照T+1转储到数据仓库中，业务统计查询都从数仓中提取，优点是查询效率较高，缺点是查询复杂度比较高，比如有1个月的表，按照月，天的维度统计还是有些复杂的。
3）使用基于中间件的分布式集群来进行数据写入水平扩展，整个集群的资源需求至少需要主从9个实例。
4）考虑使用MySQL+大数据流转的方案，即在MySQL中实时写入，数据通过Maxwell流转到Kafka中，然后进入大数据体系中进行消费，比如使用Impla等方案，可以做到比较高效的数据统计效果
整体经过讨论，最后采用了第4中方案，毕竟第2种方案需要重新配置和构建脚本逻辑，方案3没有解决统计查询的瓶颈问题，方案4解决了存储和统计查询的大问题。
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
订阅我的微信公众号“杨建荣的学习笔记”，第一时间免费收到文章更新。别忘了加星标，以免错过新推送提示。
近期热文
你可能也会对以下话题感兴趣。点击链接就可以查看。
职场建议：给新人和老鸟的几点建议
对于新技术栈落地和架构思维的建议
你到底关注了哪些公众号？我做了一通分析
如何优化MySQL千万级大表，我写了6000字的解读
说说我的新书《MySQL DBA工作笔记》
使用Python分析北京积分落户数据，分析完我陷入了深思
MySQL的主键命名挺任性，就这么定了
华裔教授发现二次方程极简解法,我默默的做了下验算
回答:我不小心把公司的数据库给删了，该不该离职？
迁移到MySQL的业务架构演进实战
数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考
MySQL业务双活的初步设计方案
一道经典的MySQL面试题，答案出现三次反转
业务双活的数据切换思路设计（下）
业务双活的数据切换思路设计（一）
MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意