一 应用场景描述

前面介绍了两种处理Zabbix历史数据的解决办法，但是如果当监控数据继续增长的话是不足以解决问题的。

办法一适合在没有做表分区的情况下，只保留一段时间的数据，比如一个月，然后把老的数据删除再使用方法二，这种操作执行时间长。

办法二是使用MySQL自带的表分区功能，将history等表按照日期进行分区，然后只保留一段时间的数据。但是即使使用表分区功能定期删除不用的分区数据，也会有瓶颈产生。比如，监控数据量大了，一个月的历史数据都有好几百G，继续增长就会把服务器磁盘撑爆了。所以，纵向扩展不是最好的选择。由于Zabbix设计的是单库结构，所有的表操作都是在同一个数据库中执行，这样像history这样的大表操作必然会影响其他的表操作，如何将history这个几个大表隔离出来放到其他数据库服务器上才是解决问题的关键。由此想到可以使用MySQL中间件来对Zabbix数据库进行分表操作，同时可以借助于MySQL中间件提供的读写分离功能，对这些大表进行读写分离，进一步减轻压力。

二 MySQL中间件选型

在选择使用哪一款MySQL中间件之前先确定我们的需求：

最好是开源产品，同时是出于活跃开发的产品

尽量在不更改Zabbix代码的情况下可以直接使用---重点

提供分库分表的功能

提供读写分离的功能

性能稳定，线上使用案例多

SQL语句解析丰富

明白了这些需求之后，就可以开始查资料选型了。几种可选的MySQL中间件如下：

Cobar   阿里巴巴开源的产品，3年多没有维护了，直接放弃

Mycat   Cobar的改良版本，由社区维护，功能丰富，有线上案例参考。同时文档和资料齐全。

《分布式数据库架构及企业实践——基于Mycat中间件》

可以测试

OneProxy 前支付宝DBA开发的商业产品，社区版本有限制。不过，他们有现成的Zabbix数据库扩容方案。直接放弃

Kingshard 用Go语言开发的MySQL中间件，支持分库分表和读写分离等功能。可以测试

DBProxy  美团最近开源的MySQL中间件，支持分表和读写分离。 可以测试

由此我们需要测试3个MySQL中间件：Mycat，Kingshard和DBProxy

首先部署两个MySQL数据库实例

172.28.2.231:3306  默认DB1

172.28.2.227:3306   存放history几个大表的DB2

两个DB实例都建好Zabbix数据库和帐号,然后按照3个中间件的文档部署

history,history_uint,history_str,history_text,history_log,trends,trends_uint 这几张表按照文档分配到DB2,其他的表默认走DB1

1.测试Mycat

Zabbix server日志没有报错，但是Zabbix页面有报错，主要都是SELECT DISTINCT h.* 这种SQL Mycat无法解析。在终端下测试SELECT DISTINCT * 就不报错，同时如果history几个表不走DB2而是走默认的DB1也不会报错。

2.测试Kingshard

Zabbix server错误日志刷新频繁，同时Kingshard的错误日志刷新较多，Zabbix页面错误较多。

3.测试DBProxy

编译安装不成功，直接放弃

所以，接下来我们重点测试如果使用Mycat来扩容数据库。关于MySQL中间件的资料网上很多，大家可以自行查找。分表功能包括

三 使用Mycat来为Zabbix数据库分表

参考文档：