处理Zabbix历史数据库

  1. 云栖社区>
  2. 博客>
  3. 正文

处理Zabbix历史数据库

技术小阿哥 2017-11-26 14:41:00 浏览551
展开阅读全文

方法

主要处理的表

history,history_uint,events

1.脚本

#!/bin/bash

User="root"

Passwd="xx"

Date=`date -d $(date -d "-30 day" +%Y%m%d) +%s` 

$(which mysql) -u${User} -p${Passwd} -e "

use zabbix;

DELETE FROM history WHERE 'clock' < 1473264000;

optimize table history;

DELETE FROM history_uint WHERE 'clock' < 1473264000;

optimize table history_uint;

"


CREATE TABLE `events` (

  `eventid` bigint(20) unsigned NOT NULL,

  `source` int(11) NOT NULL DEFAULT '0',

  `object` int(11) NOT NULL DEFAULT '0',

  `objectid` bigint(20) unsigned NOT NULL DEFAULT '0',

  `clock` int(11) NOT NULL DEFAULT '0',

  `value` int(11) NOT NULL DEFAULT '0',

  `acknowledged` int(11) NOT NULL DEFAULT '0',

  `ns` int(11) NOT NULL DEFAULT '0',

  PRIMARY KEY (`eventid`),

  KEY `events_1` (`source`,`object`,`objectid`,`clock`),

  KEY `events_2` (`source`,`object`,`clock`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8


删除events碰到的问题

1.大表删除

ln evnets.ibd events.hdlk


2.删除外键关联的数据

https://stackoverflow.com/questions/1905470/cannot-delete-or-update-a-parent-row-a-foreign-key-constraint-fails


先查询父表events外键引用关系

SELECT * FROM information_schema.`KEY_COLUMN_USAGE`

WHERE referenced_table_name='events'

想要删除父表的数据,需要先禁用外键约束检查:

SET FOREIGN_KEY_CHECKS = 0; 



如果主表delete设置为RESTRICT,那么从表无法删除数据,主表可以

如果主表delete设置为CASCADE,那么主从表都可以删除数据


RESTRICT的时候,主表如果有数据,从表肯定不能删除



3.rm -rf events.hdlk



2.分区

1
2
3
4
5
6
7
8
手动增加或者删除分区
MySQL 5.6之前
ALTER TABLE `history_uint` ADD PARTITION p2011_10_23 VALUES LESS THAN (UNIX_TIMESTAMP("2011-10-24 00:00:00") ENGINE = InnoDB;
ALTER TABLE `history_uint` DROP PARTITION p2011_06;
 
MySQL5.6之后
ALTER TABLE `history_uint` ADD PARTITION (PARTITION p2016_05_16 VALUES LESS THAN (UNIX_TIMESTAMP("2016-05-17 00:00:00")) ENGINE=InnoDB);
ALTER TABLE `history_uint` DROP PARTITION p2016_05_16;

可以成功的 http://lihuipeng.blog.51cto.com/3064864/1561221

有一点需要注意,调用call如果是7天,那么7天后就不会分区了。

3.oneproxy或者mycat 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
article规则配置:
<!DOCTYPE mycat:rule SYSTEM "rule.dtd"><mycat:rule xmlns:mycat="http://org.opencloudb/">
    <!--article 分区配置,按照id进行模2.-->
    <tableRule name="mod-long">
        <rule>
            <columns>user_id</columns>
            <algorithm>mod-long</algorithm>
        </rule>
    </tableRule>
 
    <function name="mod-long" 
    class="org.opencloudb.route.function.PartitionByMod">
        <property name="count">2</property>
    </function></mycat:rule>
 
配置service.xml:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE mycat:server SYSTEM "server.dtd"><mycat:server xmlns:mycat="http://org.opencloudb/">
        <system>
            <property name="defaultSqlParser">druidparser</property>
        </system>
 
        <user name="mycat">
                <property name="password">mycat</property>
                <property name="schemas">mycat,blog_user,blog_category,blog_article</property>
        </user></mycat:server>
 
数据库sequence生成
 
or
 
http://blog.csdn.net/freewebsys/article/details/47003577
 
其中规则xml的配置如下:按照自然月进行分区,分区字段是create_date
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE mycat:rule SYSTEM "rule.dtd"><mycat:rule xmlns:mycat="http://org.opencloudb/">
    <!--msg 分区配置,按照自然月进行分区,分区字段是create_date-->
 
    <tableRule name="sharding-by-month"> <rule>
        <columns>create_date</columns>
        <algorithm>sharding-by-month</algorithm> </rule>
    </tableRule>
    <function name="sharding-by-month" class="org.opencloudb.route.function.PartitionByMonth">
        <property name="dateFormat">yyyyMMdd</property
        <property name="sBeginDate">20150101</property>
    </function></mycat:rule>
     
schema.xml配置:
 
<?xml version="1.0"?><!DOCTYPE mycat:schema SYSTEM "schema.dtd"><mycat:schema xmlns:mycat="http://org.opencloudb/">
 
        <schema name="mycat" checkSQLschema="false" sqlMaxLimit="100">
                <table name="MYCAT_SEQUENCE" primaryKey="name" type="global" dataNode="dataHost01" />
        </schema>
 
        <schema name="msg" checkSQLschema="false" sqlMaxLimit="100">
            <table name="msg" primaryKey="create_date" dataNode="nodeMsg201501,nodeMsg201502,nodeMsg201503,nodeMsg201504" rule="sharding-by-month" />
        </schema>
 
        <!--按照月份进行拆分,一次做好一年的数据库。同时数据库中,可以根据实际情况在做mysql分区。-->
        <dataNode name="nodeMsg201501" dataHost="dataHost01" database="msg_201501" />
        <dataNode name="nodeMsg201502" dataHost="dataHost01" database="msg_201502" />
 
        <dataNode name="nodeMsg201503" dataHost="dataHost01" database="msg_201503" />
        <dataNode name="nodeMsg201504" dataHost="dataHost01" database="msg_201504" />
 
        <!-- 可以一直按月分区下去。 -->
 
        <dataHost name="dataHost01" maxCon="1000" minCon="10" balance="0"
                writeType="0" dbType="mysql" dbDriver="native">
                <heartbeat>select 1</heartbeat>
                <writeHost host="hostM1" url="127.0.0.1:3306" user="root" password="root"/>
        </dataHost></mycat:schema>
     
说明:这里按自然月分区需要使用1.4的版本。里面包括规则类
或者把这个类拷贝到1.3的jar里面也行
 
使用mycat可以大大提高数据库的存储能力,对于每月自然增长的数据,按月存储是最好的办法。
同时每一个组使用自己的id自增策略,都从1开始计算,
这样在查询历史数据的适合也按月进行迭代查询,当然所有牵扯到查询的sql都要修改,
修改成按月进行查询。把日期参数传入。数据库的扩展性增强了,
可以支持数据持续增长的业务了




详细步骤

使用过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 参数。

下面,就是一次针对线上Zabbix的MySQL数据库history历史记录过多导致ibdata1文件过大的实战解决步骤
1.查看文件大小
$ sudo cd /var/lib/mysql
$ ls -lh

total 14G
-rw-r--r-- 1 root root 0 Dec 1 14:31 debian-5.1.flag
-rw-rw---- 1 mysql mysql 5.0M Jan 17 21:31 ib_logfile0
-rw-rw---- 1 mysql mysql 5.0M Jan 17 21:29 ib_logfile1
-rw-rw---- 1 mysql mysql 14G Jan 17 21:31 ibdata1
drwx------ 2 mysql root 4.0K Dec 1 14:31 mysql
-rw-rw---- 1 root root 6 Dec 1 14:31 mysql_upgrade_info
drwx------ 2 mysql mysql 4.0K Jan 17 21:29 zabbix


共享表数据空间文件ibdata1大小已经达到了14G

登陆MySQL查看哪些表占用了空间
$ mysql -uroot -p

mysql > 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               | 9678.00000000 |  123981681 |
| history_log           |    0.04687500 |          0 |
...
| history_text          |    0.04687500 |          0 |
| history_uint          | 5386.98437500 |   57990562 |
| history_uint_sync     |    0.04687500 |          0 |
...
| timeperiods           |    0.01562500 |          0 |
| trends                |   54.54687500 |     537680 |
| trends_uint           |  100.53125000 |    1035592 |
...
103 rows in set (1.46 sec)



可以看到,history表的记录已经达到了9G,123981681条,即1亿2千万条,同时history_unit也比较大,达到了5G,约6千万条;
另外就是trends,trends_uint中也存在一些数据。
由于数据量太大,按照普通的方式delete数据的话基本上不太可能。
因为我们每天会自动发送数据报表,所以决定直接采用truncate table的方式来快速清空这些表的数据,再使用mysqldump导出数据,删除共享表空间数据文件,重新导入数据。

2.停止相关服务,避免写入数据
$ sudo /etc/init.d/zabbix-server stop
$ sudo /etc/init.d/apache2 stop

3.清空历史数据
$ mysql -uroot -p

mysql > use zabbix;
Database changed

mysql > truncate table history;
Query OK, 123981681 rows affected (0.23 sec) 

mysql > optimize table history; 
1 row in set (0.02 sec)

mysql > truncate table history_uint;
Query OK, 57990562 rows affected (0.12 sec) 

mysql > optimize table history_uint;
1 row in set (0.03 sec)

mysql > truncate table trends;
Query OK, 537680 rows affected (0.04 sec) 

mysql > optimize table trends;
1 row in set (0.02 sec)

mysql > truncate table trends_uint; 
Query OK, 1035592 rows affected (0.02 sec)   

mysql > optimize table trends_uint; 
1 row in set (0.01 sec) 


4.备份数据
$ mysqldump -uroot -p zabbix > ~/zabbix.sql

5.停止数据库
$ sudo stop mysql

6.删除共享表空间数据文件
$ cd /var/lib/mysql
$ rm ib*

7.增加innodb_file_per_table参数
$ sudo vim /etc/mysql/my.cnf
在[mysqld]下设置
1 innodb_file_per_table=1

8.启动MySQL
$ sudo start mysql

9.查看参数是否生效
$ mysql -uroot -p

mysql> show variables like '%per_table%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)


10.重新导入数据
$ mysql -uroot -p zabbix < ~/zabbix.sql

11.编写每天自动清理数据的脚本,保留30天的数据
$ sudo vim /etc/cron.daily/clean_zabbix_olddata.sh

#!/bin/bash
DATE=`date -d "30 days ago"`
CLOCK=`date +%s -d "${DATE}"`
MYSQL="mysql -uroot -p zabbix"

for TABLE in history trends
do
  $MYSQL -e "DELETE FROM ${TABLE} WHERE clock < ${CLOCK};"
  $MYSQL -e "OPTIMIZE TABLE ${TABLE};"
  $MYSQL -e "DELETE FROM ${TABLE}_uint WHERE clock < ${CLOCK};"
  $MYSQL -e "OPTIMIZE TABLE ${TABLE}_uint;"
done


12.最后,恢复相关服务进程
$ sudo /etc/init.d/zabbix-server start
$ sudo /etc/init.d/apache2 start

注意  过程会报错


上面是说要求我们在启动的时候指定--skip-new或者--safe-mode选项来支持optimize功能

ALTER TABLE table.name ENGINE='InnoDB'; 

/usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/lib/mysql/122-db.err --open-files-limit=65535 --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=3306 --skip-new  




本文转自 liqius 51CTO博客,原文链接:http://blog.51cto.com/szgb17/1859326,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小阿哥
+ 关注