刚过完年,在日常检查服务器备份数据的时候发现zabbix的MySQL备份文件异常庞大,考虑到zabbix会在日常监控服务器状态时定期发送一些告警信息以及监控时保存的SQL记录,所以查看了下zabbix的数据库表,发现mysql系统库文件下zabbix的数据库目录本身并不是很大,也就几百M,但发现同目录下的ibdata1文件异常庞大,达到了4.7G.
zabbix本身日常的监控数据量很大是事实,但为什么感觉没保存在zabbix目录下?且ibdata1为什么这么巨大?
网上查阅了zabbix的数据库存储原理,发现zabbix库是使用的innodb引擎的共享表空间,innodb把数据和索引都放在ibdata1下,随着数据增长,ibdata1会越来越大。性能方面会有影响。
然后就很好奇zabbix为什么会使用innodb的共享表空间存储数据,网上查看到一段资料写到
----------------------------------------------------------------------------------------
使用过MySQL的同学，刚开始接触最多的莫过于MyISAM表引擎了，这种引擎的数据库会分别创建三个文件：表结构、表索引、表数据空间。我们可以将某个数据库目录直接迁移到其他数据库也可以正常工作。
然而当你使用InnoDB的时候，一切都变了。InnoDB 默认会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中：ibdata1，这样就感觉不爽，增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。通常只能将数据使用mysqldump 导出，然后再导入解决这个问题。
在MySQL的配置文件[mysqld]部分，增加innodb_file_per_table参数，可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。
独立表空间
优点：
1.每个表都有自已独立的表空间。
2.每个表的数据和索引都会存在自已的表空间中。
3.可以实现单表在不同的数据库中移动。
4.空间可以回收（drop/truncate table方式操作表空间不能自动回收）
5.对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
缺点：
单表增加比共享空间方式更大。
结论：
共享表空间在Insert操作上有一些优势，但在其它都没独立表空间表现好。
当启用独立表空间时，请合理调整一下 innodb_open_files 参数。
----------------------------------------------------------------------------------------
原来默认情况下innodb会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中ibdata1,而且增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。
所以决定将innodb的共享表空间改成独立表空间,然后以后单独备份zabbix数据库时就不会备份整个数据库文件,导致系统资源浪费,最后再做一个定期的清理zabbix历史记录脚本,这样就不会担心以后备份文件过大,导致服务器硬盘容量紧张.
OK,开始干活....
系统环境:
-------------------------------
SYSYTEM: CentOS 6.3 x64
APACHE: httpd-2.4.4
MYSQL: mysql-5.6.10
PHP: php-5.4.13
ZABBIX: Zabbix 2.2.0rc2
-------------------------------
1.查看bdata1文件大小
# cd /usr/local/mysql/data
# du -sh *
-------------------------------------
4.0K file-test.xxx.cn.pid
4.0K file-test-relay-bin.000001
4.0K file-test-relay-bin.index
4.7G ibdata1
5.0M ib_logfile0
5.0M ib_logfile1
780K mysql
146M Syslog
4.0K webserver01.xxx.cn.pid
43M zabbix
--------------------------------------
共享表数据空间文件ibdata1大小已经达到了4.7G
登陆MySQL查看哪些表占用了空间
# mysql -uroot -p
-----------------------------------------
> select table_name, (data_length+index_length)/1024/1024 as total_mb, table_rows from information_schema.tables where table_schema='zabbix';
-----------------------------------------
+-----------------------+---------------+------------+
| table_name | total_mb | table_rows |
+-----------------------+---------------+------------+
| acknowledges | 0.06250000 | 0 |
....
| help_items | 0.04687500 | 103 |
| history | 2841.00000000 | 34957883 |
| history_log | 0.04687500 | 0 |
...
| history_text | 0.04687500 | 0 |
| history_uint | 1563.98437500 | 23940661 |
| history_uint_sync | 0.04687500 | 0 |
...
| timeperiods | 0.01562500 | 0 |
| trends | 17.89564700 | 145780 |
| trends_uint | 25.567894000 | 271256 |
...
103 rows in set (1.46 sec)
可以看到，history表的记录已经达到了3G，34957883条，即3千多万条，同时history_unit也比较大，达到了1G，约2百多万条；
另外就是trends,trends_uint中也存在一些数据。
由于数据量太大，按照普通的方式delete数据的话基本上不太可能。