MySQL空间报警后的一揽子解决方案

　　这是学习笔记的第2261篇文章
　　读完需要
　　5hr分钟
　　速读仅需7分钟
　　昨天下午的时候，收到一条报警信息，提示是一个异机房的从库出现了磁盘空间问题，这类问题看起来蛮好处理的，空间不够清理就是了，比如清理binlog，比如清理一些周期表等等。
　　但是在经过分析之后，发现这个问题比预想的要严重。
　　这是一套一主两从的环境，Slave2的配置相对较低，存储配置也略低一些，目前发生了磁盘空间的报警。
　　经过分析发现，原来是里面的一张表的数据量有了很大的变化，之前相对来说比较稳定，每天会生成50M100M左右的数据，但是从近几天来看，数据量翻了好几百倍，每天乎有2030G左右的数据写入，这样一来原来的存储模式就显得捉襟见肘了。
　　怎么处理呢，一种模式就是磁盘扩容，这个时候我和业务侧做了沟通，准备细致了解一下。大体的需求是因为一些业务调整，需要记录的数据内容更全更丰富了，而这也是最近的一个新需求（此处的一个明显问题就是这个需求竟然和DBA没有任何沟通），因为目前采用的是日表，日表的保留周期是20天左右，最后能存储1个月，而从业务使用的角度来说，长期来看希望保留半年，这样一个需求，在目前的情况下几乎是不可实现的。我们来简单算算，如果是保留20天，那么就需要至少600G以上的空间，外加一些冗余空间，差不多得在700800G左右，而如果保留1个月就需要1T左右，而如果保留半年就需要大约6T左右。
　　所以脑海里闪出几个方案：
　　1）对InnoDB的表进行压缩存储，压缩率高的话差不多能有4050左右，但是不能根本解决问题
　　2）使用数据库数据仓库结合的方案，比如MySQLInfobright的方案，MySQL中保留近2天的数据，数据按照T1转储到数据仓库中，业务统计查询都从数仓中提取，优点是查询效率较高，缺点是查询复杂度比较高，比如有1个月的表，按照月，天的维度统计还是有些复杂的。
　　3）使用基于中间件的分布式集群来进行数据写入水平扩展，整个集群的资源需求至少需要主从9个实例。
　　4）考虑使用MySQL大数据流转的方案，即在MySQL中实时写入，数据通过Maxwell流转到Kafka中，然后进入大数据体系中进行消费，比如使用Impla等方案，可以做到比较高效的数据统计效果
　　整体经过讨论，最后采用了第4中方案，毕竟第2种方案需要重新配置和构建脚本逻辑，方案3没有解决统计查询的瓶颈问题，方案4解决了存储和统计查询的大问题。
　　QQ群号