上一篇文章介绍的Zabbix数据表使用TokuDB引擎及分区表，同时需要每个月为这些表新建一个分区，及删除历史分区。由于MySQL不会自动新建及删除分区，所以需要额外创建一个定时任务，来进行表分区的管理。这里采用MySQL的event来做。

实现的思路是：定时任务每个月执行一次，在执行的时候，创建下个月的分区，及删除大于保留时长的历史分区，并将操作记录到log表里，便于查询历史操作记录。

实现方式

相关表结构

总共创建两个表：

• partition_management：将需要进行分区管理的表信息、历史数据保留时长存储在该表
• partition_logs：记录表分区操作记录

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

USE `zabbix`;

-- Table: partition_management
DROP TABLE IF EXISTS `partition_management`;
CREATE TABLE `partition_management` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `schema_name` VARCHAR(64) NOT NULL COMMENT '库名',
  `table_name` VARCHAR(64) NOT NULL COMMENT '表名',
  `keep_period` INT(10) UNSIGNED NOT NULL COMMENT '历史数据保留时长(单位:月)',
  `is_del_partition` TINYINT(4) NOT NULL DEFAULT '0' COMMENT '是否删除历史分区(0:不删除, 1:删除)',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` DATETIME DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `un_partition_management_1` (`schema_name`,`table_name`)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT='分区管理表';

-- Table: partition_logs
DROP TABLE IF EXISTS `partition_logs`;
CREATE TABLE `partition_logs` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `schema_name` VARCHAR(64) NOT NULL COMMENT '库名',
  `table_name` VARCHAR(64) NOT NULL COMMENT '表名',
  `maintenance_type` ENUM('ADD','DROP') NOT NULL COMMENT '分区维护类型',
  `partition_name` VARCHAR(200) NOT NULL COMMENT '分区名称',
  `execute_sql` VARCHAR(200) NOT NULL COMMENT '执行的SQL',
  `message` VARCHAR(100) NOT NULL COMMENT '备注信息',
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` DATETIME DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `ix_partition_logs_1` (`schema_name`,`table_name`,`partition_name`),
  KEY `ix_partition_logs_2` (`create_time`)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT='表分区定时任务执行记录';

-- Initialization data
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','history',6,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','history_log',6,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','history_str',6,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','history_text',6,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','history_uint',6,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','trends',24,1);
INSERT  INTO `partition_management`(`schema_name`,`table_name`,`keep_period`,`is_del_partition`) VALUES ('zabbix','trends_uint',24,1);

相关存储过程

总共创建以下3个存储过程：

• prc_partition_create：新建表分区
• prc_partition_drop：删除表分区
• prc_partition_maintenance：调用以上两个存储过程，进行表分区的新建与删除

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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221

-- Procedure: prc_partition_create
DELIMITER $$

USE zabbix$$

DROP PROCEDURE IF EXISTS prc_partition_create$$
CREATE DEFINER = 'root'@'localhost' PROCEDURE prc_partition_create(
    IN i_schema_name VARCHAR(64)    -- 分区表所在的库名
    ,IN i_table_name VARCHAR(64)    -- 分区表名
    ,IN i_partition_name VARCHAR(64)    -- 当前分区名称
    ,IN i_partition_value VARCHAR(50)    -- 当前分区值范围
)
    COMMENT '新建表分区'
BEGIN
    DECLARE v_partition_count INT DEFAULT 0;
    DECLARE v_is_maxvalue INT DEFAULT 0;
    
    SET @maintenance_type = 'ADD';    -- 进行表分区操作的类型
    
    /*
      校验是否存在大于当前分区范围值的分区，
      如果存在，则不创建该分区。
    */
    SELECT COUNT(1) INTO v_partition_count
    FROM information_schema.partitions
    WHERE table_schema = i_schema_name
    AND table_name = i_table_name
    AND partition_description <> 'MAXVALUE'
    AND partition_description >= i_partition_value;
    
    
    -- 创建分区，并将相关信息记录到日志表
    IF v_partition_count = 0 THEN
        SET @message = '';
        
        -- 判断是否存在MAXVALUE分区，并使用相应的SQL添加分区
        SELECT COUNT(1) INTO v_is_maxvalue
        FROM information_schema.partitions
        WHERE table_schema = i_schema_name
        AND table_name = i_table_name
        AND partition_description = 'MAXVALUE';
        
        IF v_is_maxvalue = 1 THEN
            SET @execute_sql = CONCAT('ALTER TABLE ', i_schema_name, '.', i_table_name
                ,' REORGANIZE PARTITION pmore INTO (PARTITION ', i_partition_name, ' VALUES LESS THAN (', i_partition_value, ')'
                ,', PARTITION pmore VALUES LESS THAN MAXVALUE);');
        ELSE
            SET @execute_sql = CONCAT('ALTER TABLE ', i_schema_name, '.', i_table_name
                ,' ADD PARTITION (PARTITION ', i_partition_name, ' VALUES LESS THAN (', i_partition_value, '));');
        END IF;
        
        INSERT INTO partition_logs(schema_name, table_name, partition_name, maintenance_type, execute_sql, message)
            VALUES(i_schema_name, i_table_name, i_partition_name, @maintenance_type, @execute_sql, @message);
        
        PREPARE execute_sql FROM @execute_sql;
        EXECUTE execute_sql;
        DEALLOCATE PREPARE execute_sql;
        
    ELSE
        SET @message = CONCAT('Partition value greater than or equal to the given value(', IFNULL(i_partition_value, 'NULL'), ') already exists.');
        SET @execute_sql = '';
        
        INSERT INTO partition_logs(schema_name, table_name, partition_name, maintenance_type, execute_sql, message)
            VALUES(i_schema_name, i_table_name, i_partition_name, @maintenance_type, @execute_sql, @message);
    END IF;
    
END$$

DELIMITER ;


-- Procedure: prc_partition_drop
DELIMITER $$

USE zabbix$$

DROP PROCEDURE IF EXISTS prc_partition_drop$$
CREATE DEFINER = 'root'@'localhost' PROCEDURE prc_partition_drop(
    IN i_schema_name VARCHAR(64)    -- 分区表所在的库名
    ,IN i_table_name VARCHAR(64)    -- 分区表名
    ,IN i_del_below_part_value VARCHAR(50)    -- 删除小于此分区值的分区(不包含此分区值)
)
    COMMENT '删除历史表分区'
BEGIN
    DECLARE v_drop_part_name VARCHAR(64);
    DECLARE v_done INT DEFAULT FALSE;
    
    -- 获取小于给定分区值的所有分区名称
    DECLARE cur_get_partition_names CURSOR FOR
        SELECT partition_name
        FROM information_schema.partitions
        WHERE table_schema = i_schema_name
        AND table_name = i_table_name
        AND partition_description <> 'MAXVALUE'
        AND partition_description < i_del_below_part_value;
    
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done = TRUE;
    
    SET @maintenance_type = 'DROP';    -- 进行表分区操作的类型
    SET @alter_header = CONCAT('ALTER TABLE ', i_schema_name, '.', i_table_name, ' DROP PARTITION ');
    SET @drop_partitions = '';
    SET @message = '';
    SET @execute_sql = '';
    
    
    -- 将所有需要删除的分区拼接起来
    OPEN cur_get_partition_names;
    loop_1: LOOP
        FETCH cur_get_partition_names INTO v_drop_part_name;
        
        IF v_done THEN
            LEAVE loop_1;
        END IF;
        
        SET @drop_partitions = IF(@drop_partitions = '', v_drop_part_name, CONCAT(@drop_partitions, ',', v_drop_part_name));
    END LOOP loop_1;
    
    
    -- 删除小于给定分区值的所有分区，并将相关信息记录到日志表
    IF @drop_partitions != '' THEN
        SET @execute_sql = CONCAT(@alter_header, @drop_partitions, ';');
        
        INSERT INTO partition_logs(schema_name, table_name, partition_name, maintenance_type, execute_sql, message)
            VALUES(i_schema_name, i_table_name, @drop_partitions, @maintenance_type, @execute_sql, @message);
        
        PREPARE execute_sql FROM @execute_sql;
        EXECUTE execute_sql;
        DEALLOCATE PREPARE execute_sql;
        
    ELSE
        SET @message = CONCAT('No partition less than the given value(', IFNULL(i_del_below_part_value, 'NULL'), ') exists.');
        
        INSERT INTO partition_logs(schema_name, table_name, partition_name, maintenance_type, execute_sql, message)
            VALUES(i_schema_name, i_table_name, @drop_partitions, @maintenance_type, @execute_sql, @message);
    END IF;
    
END$$

DELIMITER ;


-- Procedure: prc_partition_maintenance
DELIMITER $$

USE zabbix$$

DROP PROCEDURE IF EXISTS prc_partition_maintenance$$
CREATE DEFINER = 'root'@'localhost' PROCEDURE prc_partition_maintenance(
    IN i_current_year_month VARCHAR(10)    -- 执行添加、删除分区的年月，如：'201611'
)
  -- DETERMINISTIC
  COMMENT '管理表分区（新建分区及删除历史分区）'
BEGIN
    DECLARE v_schema_name VARCHAR(64);    -- 分区表所在的库名
    DECLARE v_table_name VARCHAR(64);    -- 分区表名
    DECLARE v_partition_type VARCHAR(18);    -- 分区类型
    DECLARE v_keep_period INT;    -- 分区表需要保留的历史数据时长（月）
    DECLARE v_del_partition TINYINT;    -- 是否删除历史分区
    DECLARE v_done INT DEFAULT FALSE;
    
    -- 获取所有的表名，对应的库名，及相应的分区详情
    DECLARE cur_get_partition_details CURSOR FOR
        SELECT DISTINCT schema_name
            ,table_name
            ,keep_period
            ,is_del_partition
        FROM partition_management
        ORDER BY schema_name, table_name;
    
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done = TRUE;
    
    -- 如果没有指定执行添加、删除分区的年月，则默认为当前年月
    IF i_current_year_month IS NULL OR i_current_year_month = '' THEN
        SET i_current_year_month = DATE_FORMAT(CURRENT_DATE(), '%Y%m');
    END IF;
    
    SET @current_part_name = CONCAT('p', i_current_year_month);
    SET @less_than_date = CONCAT(PERIOD_ADD(i_current_year_month, 1), '01');    -- 当前分区的值范围对应的日期（1号）
    
    
    -- 读取分区管理表数据，并进行新分区创建和历史分区删除
    OPEN cur_get_partition_details;
    
    loop_1: LOOP
        FETCH cur_get_partition_details INTO v_schema_name, v_table_name, v_keep_period, v_del_partition;
        
        IF v_done THEN
            LEAVE loop_1;
        END IF;
        
        
        -- 获取当前表的分区类型，如果为RANGE，则需要将日期转换为整数（UNIX_TIMESTAMP）。Zabbix表使用的此种分区类型。
        -- 如果分区类型为RANGE COLUMNS，则不需要转换日期格式。日志库的表使用的此种分区类型。
        SELECT DISTINCT partition_method INTO v_partition_type
        FROM information_schema.partitions
        WHERE table_schema = v_schema_name
        AND table_name = v_table_name;
        
        SET @del_below_part_date = DATE_ADD(@less_than_date, INTERVAL -v_keep_period MONTH);    -- 需要删除的分区的值对应的日期（删除小于此值的分区）
        
        IF v_partition_type = 'RANGE' THEN
            SET @less_than_value = UNIX_TIMESTAMP(@less_than_date);    -- 当前分区的值范围
            SET @del_below_part_value = UNIX_TIMESTAMP(@del_below_part_date);    -- 删除小于此分区值的分区
        ELSEIF v_partition_type = 'RANGE COLUMNS' THEN
            SET @less_than_value = CONCAT("'", DATE_FORMAT(@less_than_date, '%Y-%m-%d %H:%i:%s'), "'");
            SET @del_below_part_value = CONCAT("'", DATE_FORMAT(@del_below_part_date, '%Y-%m-%d %H:%i:%s'), "'");
        END IF;
        
        
        -- 新建分区。如果需要删除历史分区，则进行删除
        CALL prc_partition_create(v_schema_name, v_table_name, @current_part_name, @less_than_value);
        
        IF v_del_partition = 1 THEN
            CALL prc_partition_drop(v_schema_name, v_table_name, @del_below_part_value);
        END IF;
        
    END LOOP loop_1;
    CLOSE cur_get_partition_details;
END$$

DELIMITER ;

相关定时任务

创建一个event(event_partition_maintenance)，每月执行一次，通过调用存储过程prc_partition_maintenance，来达到管理分区的目的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

-- Event: event_partition_maintenance
DELIMITER $$

USE zabbix$$

DROP EVENT IF EXISTS event_partition_maintenance$$
CREATE DEFINER='root'@'localhost' EVENT event_partition_maintenance
    ON SCHEDULE EVERY 1 MONTH STARTS '2016-12-28 20:00:00'
    ON COMPLETION PRESERVE
    ENABLE
    COMMENT '定期执行Procedure(prc_partition_maintenance)，管理表分区'
DO
BEGIN
    -- 每月执行该任务，创建下一个月的分区表
    DECLARE v_current_year_month VARCHAR(10);
    DECLARE v_next_year_month VARCHAR(10);
    
    SET v_current_year_month = DATE_FORMAT(CURRENT_DATE(), '%Y%m');
    SET v_next_year_month = PERIOD_ADD(v_current_year_month, 1);
    
    CALL prc_partition_maintenance(v_next_year_month);
END$$

DELIMITER ;

脚本共享

以上所有脚本的完整文件，可以从以下GitHub源获取：
https://github.com/tyoungcn/mysql_operations/tree/master/zabbix_auto_partition

参考文档

• 处理Zabbix历史数据库办法二——使用MySQL表分区：
  http://john88wang.blog.51cto.com/2165294/1771557

线上的Zabbix库的数据表默认使用的是InnoDB存储引擎，随着时间的增长，数据量和占用的存储空间越来越多，单表数据达到了3亿之多。同时，Zabbix的Housekeeping每次在定期清理历史数据时，执行时间都超过了1分多钟，严重影响数据库的性能。

TokuDB引擎的高压缩比、高INSERT性能，正好适用于Zabbix这种INSERT多、UPDATE少，而且数据量大的环境。所以准备把相关的数据表修改为TokuDB引擎。
对Zabbix数据表根据时间字段进行分区后，可以通过删除旧的分区，来达到快速清除历史数据的目的。而且，查询Zabbix最近的数据时，只需要查询单个或几个分区即可，而不需要访问整张表，这样查询性能也得到了提升。

通过查看Zabbix数据库各表数据的存储大小，可以发现，主要是history和trends相关的表所占的存储空间比较大。因此，只对这些表使用TokuDB引擎及分区表。
以下是需要分区的表：

• history
• history_log
• history_str
• history_text
• history_uint
• trends
• trends_uint

将这些表按照clock时间字段进行分区，每个分区包含一个月的数据。

系统环境

• OS: CentOS 7
• DB: MariaDB Enterprise 10.0.23
• Zabbix Version: 3.0.1

开启TokuDB引擎

关于MariaDB如何开启TokuDB引擎，可参考之前的文章《MariaDB开启TokuDB存储引擎》。

修改存储引擎及开启分区表

注意事项

1. 由于TokuDB不支持外键，且InnoDB分区表也不支持外键，所以只要有使用TokuDB引擎或分区表，肯定不支持相关的表的外键。
   以上7个history和trends相关的表，都没有外键，因此可以使用TokuDB引擎和分区表。
2. 由于分区表的限制，分区表所使用的列必须是主键和唯一键的一部分或全部。存在以下四种情况：
   1. 分区表只有主键，没有唯一键。则分区表所使用的列必须是主键的一部分或全部。
   2. 分区表没有主键，只有唯一键。则分区表所使用的列必须是唯一键的一部分或全部。
   3. 分区表既有主键也有唯一键。则分区表所使用的列必须是主键和唯一键的共同部分，如果主键和唯一键没有共同部分，则表无法进行分区。
   4. 分区表既没有主键也没有唯一键。则分区表所使用的列不受上述条件限制。

由于history_log、history_text表结构具有主键和唯一键，且主键和唯一键都不包含分区使用的clock字段，所以需要调整这两个表，以进行表分区。

表history_log、history_text的原始结构如下：

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

mysql> SHOW CREATE TABLE history_log\G
*************************** 1. row ***************************
       Table: history_log
Create Table: CREATE TABLE `history_log` (
  `id` bigint(20) unsigned NOT NULL,
  `itemid` bigint(20) unsigned NOT NULL,
  `clock` int(11) NOT NULL DEFAULT '0',
  `timestamp` int(11) NOT NULL DEFAULT '0',
  `source` varchar(64) NOT NULL DEFAULT '',
  `severity` int(11) NOT NULL DEFAULT '0',
  `value` text NOT NULL,
  `logeventid` int(11) NOT NULL DEFAULT '0',
  `ns` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `history_log_2` (`itemid`,`id`),
  KEY `history_log_1` (`itemid`,`clock`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> SHOW CREATE TABLE history_text\G
*************************** 1. row ***************************
       Table: history_text
Create Table: CREATE TABLE `history_text` (
  `id` bigint(20) unsigned NOT NULL,
  `itemid` bigint(20) unsigned NOT NULL,
  `clock` int(11) NOT NULL DEFAULT '0',
  `value` text NOT NULL,
  `ns` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `history_text_2` (`itemid`,`id`),
  KEY `history_text_1` (`itemid`,`clock`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

表history_log、history_text的主键和索引调整如下：

1
2

mysql> ALTER TABLE history_text DROP PRIMARY KEY, ADD INDEX (id), DROP INDEX history_text_2, ADD INDEX history_text_2 (itemid, id);
mysql> ALTER TABLE history_log DROP PRIMARY KEY, ADD INDEX (id), DROP INDEX history_log_2, ADD INDEX history_log_2 (itemid, id);

由于表的数据量比较多，如果直接在原表上执行以上调整主键和索引的SQL、修改存储引擎、及开启分区表的话，耗时会比较长。这里采取的是先将各表数据分月份导出，然后重建已经修改的分区表结构，再将数据导入到修改后的表里，这样稍微会快些。

重建表结构

将原表进行重命名，并使用新的已分区的表结构创建新表。这样可以保证在数据导入导出，修改表结构的时候，不会导致Zabbix丢失这段时间的监控数据。

重建表结构脚本：

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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127

USE zabbix;

-- history
RENAME TABLE history TO history_old;
CREATE TABLE `history` (
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `value` DOUBLE(16,4) NOT NULL DEFAULT '0.0000',
  `ns` INT(11) NOT NULL DEFAULT '0',
  KEY `history_1` (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- history_log
RENAME TABLE history_log TO history_log_old;
CREATE TABLE `history_log` (
  `id` BIGINT(20) UNSIGNED NOT NULL,
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `timestamp` INT(11) NOT NULL DEFAULT '0',
  `source` VARCHAR(64) NOT NULL DEFAULT '',
  `severity` INT(11) NOT NULL DEFAULT '0',
  `value` TEXT NOT NULL,
  `logeventid` INT(11) NOT NULL DEFAULT '0',
  `ns` INT(11) NOT NULL DEFAULT '0',
  KEY (`id`),
  KEY `history_log_2` (`itemid`,`id`),
  KEY `history_log_1` (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- history_str
RENAME TABLE history_str TO history_str_old;
CREATE TABLE `history_str` (
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `value` VARCHAR(255) NOT NULL DEFAULT '',
  `ns` INT(11) NOT NULL DEFAULT '0',
  KEY `history_str_1` (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- history_text
RENAME TABLE history_text TO history_text_old;
CREATE TABLE `history_text` (
  `id` BIGINT(20) UNSIGNED NOT NULL,
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `value` TEXT NOT NULL,
  `ns` INT(11) NOT NULL DEFAULT '0',
  KEY (`id`),
  KEY `history_text_2` (`itemid`,`id`),
  KEY `history_text_1` (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- history_uint
RENAME TABLE history_uint TO history_uint_old;
CREATE TABLE `history_uint` (
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `value` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
  `ns` INT(11) NOT NULL DEFAULT '0',
  KEY `history_uint_1` (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- trends
RENAME TABLE trends TO trends_old;
CREATE TABLE `trends` (
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `num` INT(11) NOT NULL DEFAULT '0',
  `value_min` DOUBLE(16,4) NOT NULL DEFAULT '0.0000',
  `value_avg` DOUBLE(16,4) NOT NULL DEFAULT '0.0000',
  `value_max` DOUBLE(16,4) NOT NULL DEFAULT '0.0000',
  PRIMARY KEY (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

-- trends_uint
RENAME TABLE trends_uint TO trends_uint_old;
CREATE TABLE `trends_uint` (
  `itemid` BIGINT(20) UNSIGNED NOT NULL,
  `clock` INT(11) NOT NULL DEFAULT '0',
  `num` INT(11) NOT NULL DEFAULT '0',
  `value_min` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
  `value_avg` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
  `value_max` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
  PRIMARY KEY (`itemid`,`clock`)
) ENGINE=TokuDB DEFAULT CHARSET=utf8
PARTITION BY RANGE(clock)
(PARTITION p201609 VALUES LESS THAN (UNIX_TIMESTAMP('2016-10-01')) ENGINE = TokuDB,
 PARTITION p201610 VALUES LESS THAN (UNIX_TIMESTAMP('2016-11-01')) ENGINE = TokuDB,
 PARTITION p201611 VALUES LESS THAN (UNIX_TIMESTAMP('2016-12-01')) ENGINE = TokuDB,
 PARTITION pmore VALUES LESS THAN (MAXVALUE) ENGINE = TokuDB
);

导出表数据

使用SELECT ... INTO OUTFILE ...命令将旧表数据分月份导出到文件。

数据导出脚本：

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

-- history
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_old_201609' FROM zabbix.history_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_old_201610' FROM zabbix.history_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_old_201611' FROM zabbix.history_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- history_log
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_log_old_201609' FROM zabbix.history_log_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_log_old_201610' FROM zabbix.history_log_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_log_old_201611' FROM zabbix.history_log_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- history_str
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_str_old_201609' FROM zabbix.history_str_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_str_old_201610' FROM zabbix.history_str_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_str_old_201611' FROM zabbix.history_str_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- history_text
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_text_old_201609' FROM zabbix.history_text_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_text_old_201610' FROM zabbix.history_text_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_text_old_201611' FROM zabbix.history_text_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- history_uint
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_uint_old_201609' FROM zabbix.history_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_uint_old_201610' FROM zabbix.history_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/history_uint_old_201611' FROM zabbix.history_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- trends
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_old_201609' FROM zabbix.trends_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_old_201610' FROM zabbix.trends_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_old_201611' FROM zabbix.trends_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

-- trends_uint
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_uint_old_201609' FROM zabbix.trends_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-09-01') AND clock < UNIX_TIMESTAMP('2016-10-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_uint_old_201610' FROM zabbix.trends_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-10-01') AND clock < UNIX_TIMESTAMP('2016-11-01');
SELECT * INTO OUTFILE '/opt/tmp_zabbix/trends_uint_old_201611' FROM zabbix.trends_uint_old WHERE clock >= UNIX_TIMESTAMP('2016-11-01') AND clock < UNIX_TIMESTAMP('2016-12-01');

导入表数据

使用LOAD DATA INFILE命令将各表数据分月份导入到新表。
由于在导出时，已按照月份将每月数据分别导出到对应的单独文件，所以在导入时可以指定每个数据文件对应的分区，以加快导入速度。

在导入时，可以临时禁用当前session的binlog，设置sync_binlog = 0，tokudb_commit_sync = 0，以加快导入速度。同时，也可以增大tokudb_lock_timeout的值，以避免在导入本月分区的数据时，Zabbix写入数据等待超时而导致的这段时间的监控数据丢失。具体操作如下：

1. 首先设置以下GLOBAL变量：

   1 2 3

   SET GLOBAL sync_binlog = 0; SET GLOBAL tokudb_commit_sync = 0; SET GLOBAL tokudb_lock_timeout = 3600000; -- 这里设置为1小时

2. Kill掉Zabbix的数据库连接，以使刚才设置的全局变量生效；

3. 退出当前登录的MySQL会话，重新登录以使刚才设置的全局变量生效。并设置以下SESSION变量，临时禁用binlog：

   1	SET SESSION sql_log_bin = 0;

4. 执行以下数据导入脚本；

5. 导入数据完成后，再恢复设置以上更改的变量值；

数据导入脚本：

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

-- history
LOAD DATA INFILE '/opt/tmp_zabbix/history_old_201609' INTO TABLE zabbix.history PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/history_old_201610' INTO TABLE zabbix.history PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/history_old_201611' INTO TABLE zabbix.history PARTITION (p201611);

-- history_log
LOAD DATA INFILE '/opt/tmp_zabbix/history_log_old_201609' INTO TABLE zabbix.history_log PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/history_log_old_201610' INTO TABLE zabbix.history_log PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/history_log_old_201611' INTO TABLE zabbix.history_log PARTITION (p201611);

-- history_str
LOAD DATA INFILE '/opt/tmp_zabbix/history_str_old_201609' INTO TABLE zabbix.history_str PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/history_str_old_201610' INTO TABLE zabbix.history_str PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/history_str_old_201611' INTO TABLE zabbix.history_str PARTITION (p201611);

-- history_text
LOAD DATA INFILE '/opt/tmp_zabbix/history_text_old_201609' INTO TABLE zabbix.history_text PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/history_text_old_201610' INTO TABLE zabbix.history_text PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/history_text_old_201611' INTO TABLE zabbix.history_text PARTITION (p201611);

-- history_uint
LOAD DATA INFILE '/opt/tmp_zabbix/history_uint_old_201609' INTO TABLE zabbix.history_uint PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/history_uint_old_201610' INTO TABLE zabbix.history_uint PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/history_uint_old_201611' INTO TABLE zabbix.history_uint PARTITION (p201611);

-- trends
LOAD DATA INFILE '/opt/tmp_zabbix/trends_old_201609' INTO TABLE zabbix.trends PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/trends_old_201610' INTO TABLE zabbix.trends PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/trends_old_201611' INTO TABLE zabbix.trends PARTITION (p201611);

-- trends_uint
LOAD DATA INFILE '/opt/tmp_zabbix/trends_uint_old_201609' INTO TABLE zabbix.trends_uint PARTITION (p201609);
LOAD DATA INFILE '/opt/tmp_zabbix/trends_uint_old_201610' INTO TABLE zabbix.trends_uint PARTITION (p201610);
LOAD DATA INFILE '/opt/tmp_zabbix/trends_uint_old_201611' INTO TABLE zabbix.trends_uint PARTITION (p201611);

删除旧表

将表数据导入到新表后，查看Zabbix数据、图表展示是否正常。如果正常，即可删除旧表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

-- truncate table
TRUNCATE TABLE zabbix.history_old;
TRUNCATE TABLE zabbix.history_log_old;
TRUNCATE TABLE zabbix.history_str_old;
TRUNCATE TABLE zabbix.history_text_old;
TRUNCATE TABLE zabbix.history_uint_old;
TRUNCATE TABLE zabbix.trends_old;
TRUNCATE TABLE zabbix.trends_uint_old;

-- drop table
DROP TABLE zabbix.history_old;
DROP TABLE zabbix.history_log_old;
DROP TABLE zabbix.history_str_old;
DROP TABLE zabbix.history_text_old;
DROP TABLE zabbix.history_uint_old;
DROP TABLE zabbix.trends_old;
DROP TABLE zabbix.trends_uint_old;

禁用Zabbix的Housekeeping

进行表分区后，通过删除表的历史分区即可清除历史数据，而Zabbix的Housekeeping默认会每隔一小时执行清除历史数据操作，所以需要关闭Housekeeping的定时清理任务。

进入Zabbix菜单：Administration -> General，选择右上角下拉菜单的“Housekeeping”，取消勾选“History”和“Trends”栏目下的“Enable internal housekeeping”，保存既可。

参考文档

• Zabbix官方文档：
  http://zabbix.org/wiki/Docs/howto/mysql_partition
• 处理Zabbix历史数据库办法二——使用MySQL表分区：
  http://john88wang.blog.51cto.com/2165294/1771557
• 迁移Zabbix数据库到TokuDB：
  http://imysql.com/2014/06/24/migrate-zabbix-db-to-tokudb.shtml

由于运维及存档分析需要，需要将某些程序、文件调用日志导入到本地MariaDB数据库存储。同时为了节省磁盘空间，决定使用TokuDB存储引擎。

在MariaDB5.5.34及10.0.6之后的版本已经包含了TokuDB存储引擎，只是默认没有开启，可以根据需要手动进行开启。开启方式也很简单，方法如下文介绍。

MariaDB的二进制包版本中，只有名称中带有glibc_214的压缩包版本，才包含TokuDB引擎。

系统环境

• OS: CentOS 7
• DB Version: MariaDB Enterprise 10.0.23

禁用Transparent Huge Pages(THP)

检查Linux是否开启Transparent Huge Pages。如果有开启，则需要关闭，否则MariaDB无法开启TokuDB引擎。

原因：

Transparent Huge Pages is a feature in newer linux kernel versions that causes problems for the memory usage tracking calculations in TokuKV and can lead to memory overcommit. If you have this feature enabled, TokuKV will not start, and you should turn it off.

如果没有禁用Transparent Huge Pages，则开启TokuDB后启动MariaDB时，错误日志记录如下，不过mysqld服务仍是可以正常启动的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Transparent huge pages are enabled, according to /sys/kernel/mm/transparent_hugepage/enabled
160517 11:40:22 [ERROR] TokuDB: Huge pages are enabled, disable them before continuing

160517 11:40:22 [ERROR] ************************************************************
160517 11:40:22 [ERROR]
160517 11:40:22 [ERROR]                         @@@@@@@@@@@
160517 11:40:22 [ERROR]                       @@'         '@@
160517 11:40:22 [ERROR]                      @@    _     _  @@
160517 11:40:22 [ERROR]                      |    (.)   (.)  |
160517 11:40:22 [ERROR]                      |             ` |
160517 11:40:22 [ERROR]                      |        >    ' |
160517 11:40:22 [ERROR]                      |     .----.    |
160517 11:40:22 [ERROR]                      ..   |.----.|  ..
160517 11:40:22 [ERROR]                       ..  '      ' ..
160517 11:40:22 [ERROR]                         .._______,.
160517 11:40:22 [ERROR]
160517 11:40:22 [ERROR] TokuDB will not run with transparent huge pages enabled.
160517 11:40:22 [ERROR] Please disable them to continue.
160517 11:40:22 [ERROR] (echo never > /sys/kernel/mm/transparent_hugepage/enabled)
160517 11:40:22 [ERROR]
160517 11:40:22 [ERROR] ************************************************************
160517 11:40:22 [ERROR] Plugin 'TokuDB' init function returned error.
160517 11:40:22 [ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.

未禁用Transparent Huge Pages时，在MySQL命令行，开启TokuDB时，报错信息如下：

1
2

mysql> INSTALL SONAME 'ha_tokudb';
ERROR 1123 (HY000): Can't initialize function 'TokuDB'; Plugin initialization function failed.

检查是否开启Transparent Huge Pages

1

shell> cat /sys/kernel/mm/transparent_hugepage/enabled

执行以上命令，如果提示路径不存在，或返回以下信息，则表示没有开启Transparent Huge Pages。

1

always madvise [never]

如果返回以下信息，则表示已开启Transparent Huge Pages，需要将其禁用。

1

[always] madvise never

禁用Transparent Huge Pages

临时禁用

以下更改立即生效，在重启后失效：

1

shell> echo never > /sys/kernel/mm/transparent_hugepage/enabled

永久禁用

以下更改在重启后生效，且仅限CentOS或RedHat系统。

在文件/etc/default/grub添加以下内容：

1

GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=never"

更新grub (boot loader)：

1

shell> grub2-mkconfig -o /boot/grub2/grub.cfg "$@"

以上是MariaDB官方文档介绍的方法。
在公司的测试机上按照以上修改，重启电脑后，Transparent Huge Pages和预料中的一样，被禁用掉了。可是，当我在自己的虚拟机和本地开发机器上，按照以上修改重启系统后，Transparent Huge Pages并没有被禁用掉。如下：

1
2

shell> cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

参考MongoDB官方文档，在禁用Transparent Huge Pages时提到，如果有在Red Hat或者CentOS(6+)系统使用tuned或ktune，还需要添加额外的配置，以防止THP被重新启用。

tuned和ktune是Red Hat和CentOS系统上的动态调优工具，通过其能够禁用transparent huge pages。如果要通过tuned和ktune来禁用transparent huge pages，需要创建一个配置文件设置THP的值为never。

以下是CentOS 7系统通过添加tuned配置文件来禁用transparent huge pages的方法，CentOS 6系统的配置方法与此有些不同，可以参考MongoDB官方文档。

1. 新建tuned配置文件夹

   1	shell> mkdir /etc/tuned/no-thp

2. 添加配置文件tuned.conf

   1	shell> vim /etc/tuned/no-thp/tuned.conf

   并添加以下配置内容：

   1 2 3 4

   [main]   include=virtual-guest   [vm]   transparent_hugepages=never

3. 使新的配置文件生效

   1	shell> tuned-adm profile no-thp

以上配置添加完成后，再次重启系统，查看及确认Transparent Huge Pages已经被禁用，如下。

1
2

shell> cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

修改MariaDB配置文件，启用TokuDB

在配置文件my.cnf中添加以下配置，在每次启动时都启用TokuDB存储引擎，重启生效。

1

plugin-load = ha_tokudb

当然，也可以在不重启MariaDB的情况下，执行以下MySQL命令，启用TokuDB存储引擎。

1

mysql> INSTALL SONAME 'ha_tokudb';

使用SHOW ENGINES命令查看已开启的存储引擎，可以看到TokuDB已启用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                                    | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| CSV                | YES     | CSV storage engine                                                         | NO           | NO   | NO         |
| MRG_MyISAM         | YES     | Collection of identical MyISAM tables                                      | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables                  | NO           | NO   | NO         |
| BLACKHOLE          | NO      | /dev/null storage engine (anything you write to it disappears)             | NULL         | NULL | NULL       |
| MyISAM             | YES     | MyISAM storage engine                                                      | NO           | NO   | NO         |
| TokuDB             | YES     | Percona TokuDB Storage Engine with Fractal Tree(tm) Technology             | YES          | YES  | YES        |
| InnoDB             | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES          | YES  | YES        |
| ARCHIVE            | NO      | Archive storage engine                                                     | NULL         | NULL | NULL       |
| FEDERATED          | YES     | FederatedX pluggable storage engine                                        | YES          | NO   | YES        |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                                         | NO           | NO   | NO         |
| Aria               | YES     | Crash-safe tables with MyISAM heritage                                     | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
11 rows in set (0.02 sec)

相关参数配置

1
2
3
4
5
6
7
8

[mysqld]
# TokuDB
plugin-load = ha_tokudb
tokudb_cache_size = 4G
tokudb_data_dir = /data/mysql/mysql3306/tokudb_data
tokudb_log_dir = /data/mysql/mysql3306/logs
tokudb_tmp_dir = /data/mysql/mysql3306/tmp
tokudb_pk_insert_mode = 2

各参数说明：

• tokudb_cache_size
  默认情况下，TokuDB分配50%的系统内存。
• tokudb_data_dir
  指定TokuDB数据的存储位置。默认为空，使用datadir定义的路径。
• tokudb_log_dir
  指定TokuDB日志的存储位置。默认为空，使用datadir定义的路径。
• tokudb_tmp_dir
  TokuDB批量导入数据时，临时文件的存储位置。TokuDB在使用LOAD DATA导入数据的时候会通过临时表(可能会很大)来完成。
  默认为空，使用datadir定义的路径。
• tokudb_pk_insert_mode
  主键写入的模式，只有值为2时，才支持RBR。

注意事项

变量toukudb_cache_size的值大小设置

TokuDB默认分配50%的系统内存，该值由变量toukudb_cache_size控制，类似于InnoDB的innodb_buffer_pool_size。
如果同时使用InnoDB和TokuDB存储引擎，需适当调整这两个变量的值，以免超过系统内存，造成swap交换。

toukudb_cache_size为只读变量，修改后重启生效。

变量tokudb_pk_insert_mode对复制的影响

当变量tokudb_pk_insert_mode为默认值（1）或0时，基于ROW格式的复制（RBR）将无法运行，需要将该变量的值修改为2，RBR才能正常运行。

变量tokudb_pk_insert_mode的说明如下：

• Description: Mode for primary key inserts using either REPLACE INTO or INSERT IGNORE on tables with no secondary index, or where all columns in the secondary index are in the primary key. For example PRIMARY KEY (a,b,c), key (b,c)
  • 0: Fast inserts. Triggers may not work, and row-based replication will not work.
  • 1: Fast inserts if no triggers are defined, otherwise inserts may be slow. Row-based replication will not work.
  • 2: Slow inserts. Triggers and row-based replication work normally.
• Scope: Global, Session
• Dynamic: Yes
• Data Type: enumerated
• Default Value: 1
• Valid Values: 0, 1, 2

数据占用存储空间对比

使用MyISAM引擎存储日志数据时，表数据大小是13G；更改为TokuDB引擎后，使用默认的压缩方式（tokudb_zlib），表数据大小是1.6G。可以看出，TokuDB相对于MyISAM，数据压缩比达到8倍之多。

参考文章

1. MariaDB官方文档-Enabling TokuDB：
   https://mariadb.com/kb/en/mariadb/enabling-tokudb
2. MongoDB官方文档-Disable Transparent Huge Pages(THP)：
   https://docs.mongodb.com/manual/tutorial/transparent-huge-pages/
3. TokuDB使用简单说明：
   http://highdb.com/tokudb-特性概览/

系统环境

测试环境：

• OS: CentOS 7
• DB Version: MariaDB 10.0.23
• PT Version: pt-table-checksum 2.2.18
• 主从环境
  • Master: 192.168.0.17:53309
  • Slave: 192.168.0.18:3309

问题

在使用pt-table-checksum配置主从校验的时候，本地和生产环境都可以正常校验，而在测试环境校验的时候，却输出以下警告信息：

1
2

Cannot connect to h=192.168.0.18,p=...,u=pt_table_check
Diffs cannot be detected because no slaves were found.  Please read the --recursion-method documentation for information.

pt-table-checksum无法连接从库。
由于没有发现从库，数据校验时无法实时检测从库与主库的数据是否一致（DIFFS列始终为0），需要通过--recursion-method选项指定其他的方式来搜索、连接从库（此处--recursion-method使用的是默认值processlist,hosts）。

原因

执行的详细命令及输出如下：

1
2
3
4
5
6

shell> ./bin/pt-table-checksum --socket=/var/lib/mysql/mysql.sock --user=pt_table_check --password='checksum123' --tables=road_to_dba.test1 --replicate=percona_schema.checksums --no-check-binlog-format --no-check-replication-filters

Cannot connect to h=192.168.0.18,p=...,u=pt_table_check
Diffs cannot be detected because no slaves were found.  Please read the --recursion-method documentation for information.
            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
09-21T20:57:37      0      0      972       1       0   0.033 road_to_dba.test1

虽然在校验时pt-table-checksum没有连接到从库，但校验能够在主库正常运行，而且能够通过复制传递到从库。校验完成后，在从库也可以通过checksums表查询到数据校验不一致的表信息。

本着严(qiang)谨(po)的(zheng)态度，决定还是对于上述警告信息彻底解决掉。经过分析，具体原因如下：

• 默认情况下，pt-table-checksum使用的从库连接参数，是从主库的连接参数继承而来的，包括用户名（--user）、密码（--password）、端口（--port）等。
• 在本次校验中，没有显式指定从库的用户名（--slave-user），密码（--slave-password），及端口。
• 所以，在没有显式指定从库的连接参数的情况下，默认是，主库和从库的用户名、密码、端口是相同的；但是在我的测试环境中，主从环境的端口是不同的。所以导致pt-table-checksum虽然搜索到了从库，但是无法连接从库（Cannot connect to h=192.168.0.18,p=...,u=pt_table_check），紧接着报没有发现从库的错误。

由于pt-table-checksum没有参数可以用来指定从库的端口，所以使用dsn方式来指定从库的连接信息（--recursion-method dsn=D=percona,t=dsns,h=host,P=3309,u=username,p=passwd）。

dsn是什么

首先介绍俩名词：

• dsn方法：dsn是参数--recursion-method的一个参数值。注意是dsn，不是dns…
• DSN：DSN，即DATA SOURCE NAME，数据源名称。DSN包含从库的各个连接参数（user、password、port等），由逗号分隔的多个option=value字符串组成。
  如：h=host,P=3309,u=username,p=passwd。

dsn方法是指将从库的DSN信息存储在表（DSN表）里，然后将该表和DSN信息赋值给dsn，作为--recursion-method的参数值。
格式如：--recursion-method dsn=D=percona,t=dsns,h=host,P=3309,u=username,p=passwd。

当指定pt-table-checksum的--recursion-method参数值为dsn时，它只会连接和检测这些指定的从库。当从库的MySQL用户名、密码、端口与主库不相同时，也可以通过dsn的方式来指定。

DSN的部分选项如下：

• D
  DSN表所在的数据库名。
• h
  从库的host。
• p
  小写p，从库的密码。当密码包括逗号（,）时，需要使用反斜杠转义。
• P
  大写P，从库的端口。
• S
  连接使用的socket文件。
• t
  存储DSN信息的DSN表名。
• u
  从库的MySQL用户名。

每一个选项和其值的形式为option=value，=的前后不能空格，如果选项值有空格，则必须使用引号引起来。

将DSN作为--recursion-method的参数值时，必须包含D和t选项；或者只包含t选项，同时DSN表指定数据库前缀（如percona.dsns）。

DSN表结构如下：

1
2
3
4
5
6

CREATE TABLE `dsns` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) DEFAULT NULL,
  `dsn` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
);

存储在表中的DSNs以id值排序，但是这里可以忽略id和parent_id列，只需将从库的DSN信息存储在dsn列即可。存储的DSN格式如前面在命令行上指定DSN一样，如：h=host,P=3309,u=username,p=passwd。

DSN的详细介绍可参考Percona官方文档：https://www.percona.com/doc/percona-toolkit/2.2/dsn_data_source_name_specifications.html

解决问题

上面绕的有点晕。。。其实只需要知道如何使用dsn指定从库连接信息即可。

下面通过指定--recursion-method为dsn的方式，解决测试环境在数据校验时无法连接从库的问题。

1. 在主库新建DSN表

   1 2 3 4 5 6

   CREATE TABLE `percona_schema.dsns` (     `id` int(11) NOT NULL AUTO_INCREMENT,     `parent_id` int(11) DEFAULT NULL,     `dsn` varchar(255) NOT NULL,     PRIMARY KEY (`id`)   );

2. 这里为了测试，和主库的MySQL账号区分开，新建了一个账号pt_table_check2专用于连接从库
   主库账号是pt_table_check

   1	GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO pt_table_check2@'192.168.0.%' IDENTIFIED BY 'checksum123';

3. 将从库的DSN信息写入DSN表

   1	INSERT INTO percona_schema.dsns(dsn) VALUES ("h=192.168.0.18,P=3309,u=pt_table_check2,p=checksum123");

4. 在主库使用dsn方式，重新运行pt-table-checksum进行校验

   1 2 3 4

   shell> ./bin/pt-table-checksum --socket=/var/lib/mysql/mysql.sock --user=pt_table_check --password='checksum123' --tables=road_to_dba.test1 --replicate=percona_schema.checksums --no-check-binlog-format --no-check-replication-filters --recursion-method dsn=t=percona_schema.dsns,h=192.168.0.18,P=3309,u=pt_table_check2,p=checksum123                   TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE   09-21T21:22:30      0      1      972       1       0   0.273 road_to_dba.test1

从第4步可以看到，pt-table-checksum已经能够检测到从库，并且检测到主从数据不一致（DIFFS = 1）。
问题解决。

无法连接/检测从库的影响

虽然在使用pt-table-checksum时，如果无法连接/检测到从库，仍可以完成主从一致性校验。但是，这样可能会产生一些其他的问题，如下：

1. pt-table-checksum在执行校验时，无法实时检测主从的数据是否一致。即，输出的DIFFS列始终为0。
2. 无法检测到从库是否有使用复制过滤，可能会造成从库复制卡住。
3. 当某个表在主库上作为一个分块进行校验时，无法检测其在从库的数据量，当该表在从库的数据量很大时，会造成从库负载过高。
4. 无法检测到从库的复制延迟状态，造成从库复制延迟过大。

pt-table-checksum是Percona Toolkit工具系列中的一个，可以用来检测MySQL主、从数据的一致性。
其原理是，在主库执行校验语句（binlog格式为STATEMENT），通过复制传递到从库，如果数据不一致，则主、从会产生不同的校验值，以此来判断主从数据是否一致。

原理

• pt-table-checksum将每个表切分成多个块（chunks），每个块包含多行数据，每次仅对一个块进行校验。
• 它可以根据参数指定的每个块的校验执行时间，将表分成不同大小的块。
• 将单个表切分成多个块进行校验，可以保证不会引起从库太大的延迟，也不会对服务器负载造成太大干扰。默认的每个块的校验执行时间是0.5s。
• pt-table-checksum会持续跟踪服务器执行校验语句的时间，并且会随着服务器性能的变化，来动态调整分块的大小。
• 将表分块时，需要使用索引（优先使用主键或唯一键）。如果表没有索引，且表的行数量较小时，pt-table-checksum会将整个表作为一个数据块进行校验。
• pt-table-checksum会持续监控从库状态，如果从库复制延迟太大，校验会暂停，以等待从库追上主库。如果从库发生错误，或者复制停止，它也会暂停及等待。
• pt-table-checksum对于校验过程中产生的错误是有复原能力的。如果正在执行校验的SQL被kill掉，这对pt-table-checksum来说不是一个致命的错误，它会重新执行被kill掉的查询语句；如果再次失败，则会跳过，继续进行表的下一个分块的校验。
  当出现锁等待超时的时候，也会进行相同的重试行为，同时输出警告信息。
  如果连接服务器失败，pt-table-checksum也会进行重连和继续进行校验。
• 当在运行的过程中被完全终止后，可以使用--resume参数，继续从上次终止时正在处理的表的当前分块开始，继续校验。
  我们也可以使用CTRL-C按键来停止校验，pt-table-checksum会在完成对当前正在处理的分块的校验后，正常退出。之后我们也可以启动程序继续进行校验。
• 当pt-table-checksum完成对一个表的所有分块的校验后，它会暂停并等待所有检测到的从库执行完这个表的校验语句。一旦从库执行完成，它会比对主、从的校验结果是否一致，并输出一行结果。

使用限制

• pt-table-checksum要求复制是基于STATEMENT格式的，并且它在运行时会在主库上设置binlog_format=STATEMENT，但是由于MySQL的限制，这一设置并不会传递到从库。
  因此当从库的binlog格式是ROW格式时，无法直接对从库的从库进行校验。
  pt-table-checksum会自动检测所有服务器的binlog_format，可以通过参数--[no]check-binlog-format来指定检测与否。
• pt-table-checksum假设主从的数据库和表结构都是一致的。
  如果主库上的库不存在于从库上，或者从库的表结构与主库不一致，将会导致主从复制中断。

输出

pt-table-checksum的输出有两种格式：带--replicate-check-only参数和正常不带这个参数时，输出结果的格式是不同的。

不带--replicate-check-only参数的输出

pt-table-checksum在完成校验后会以表格形式输出结果，每个表的校验结果为一行输出，每完成校验一张表会输出一行校验结果。

输出格式如下：

1
2
3

            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
09-12T10:34:38      0      0        1       1       0   0.059 road_to_dba.names
09-12T10:34:38      0      0        5       1       0   0.016 road_to_dba.t_bigint

各列的含义如下：

• TS
  pt-table-checksum完成该表的校验时的时间。
• ERRORS
  在校验表的过程中出现的错误和警告的数量。
  错误和警告信息在校验的过程中会以标准错误的形式输出。
• DIFFS
  主库数据与一个（或多个）从库数据不一致的分块的数量。
  当指定--no-replicate-check时，该值始终为0。当指定--replicate-check-only时，只输出数据不一致的表的校验结果。
• ROWS
  查询和校验的表的行数。
• CHUNKS
  表被分成的分块的数量。
• SKIPPED
  校验表时，跳过的分块的数量。
  数据分块被跳过可能由以下问题引起：
  • MySQL没有使用--chunk-index指定的索引；
  • 通过分析执行计划（--[no]check-plan）检测到MySQL没有使用全部的表分块使用的索引；
  • 数据分块的大小大于--chunk-size * --chunk-size-limit；
  • 锁等待超时（重试的次数大于--retries指定的值）；
  • 校验的查询语句被kill掉（重试的次数大于--retries指定的值）
• TIME
  表的校验执行时长。
• TABLE
  校验的表名（含库名）。

带--replicate-check-only参数的输出

如果指定了--replicate-check-only参数，则只会输出校验结果不一致的从库数据。
输出结果的格式为：每一个从库为一个段落，每一个校验结果不同的分块占一行，各列值之间以空格分隔。如下：

1
2
3
4
5
6
7
8
9

Differences on node601
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
road_to_dba.tbl1 1 0 1 PRIMARY 1 100
road_to_dba.tbl1 6 0 1 PRIMARY 501 600

Differences on node603
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
road_to_dba.tbl1 1 0 1 PRIMARY 1 100
road_to_dba.tbl2 9 5 0 PRIMARY 101 200

输出的每个段落的第一行表示校验结果与主库不一致的从库的信息。
各列的含义如下：

• TABLE
  与主库数据不一致的表的名称（包含库名）。
• CHUNK
  表中与主库数据不一致的分块号。
• CNT_DIFF
  从库的分块的行数量减去主库的分块的行数量的差值。
• CRC_DIFF
  如果从库分块的CRC校验值与主库的不同，则为1；否则，为0。
• CHUNK_INDEX
  将表进行分块所使用的索引。
• LOWER_BOUNDARY
  分块的下边界所使用的索引值。
• UPPER_BOUNDARY
  分块的上边界所使用的索引值。

退出状态码

pt-table-checksum的退出状态码有3种值：0，255，其他的位掩码值。

• 0表示没有校验过程中没有任何错误出现。即，没有错误、警告、不同的校验值、跳过数据分块或表等。
• 255表示数据校验出现严重错误。也就是说，校验的进程终止或崩溃了。错误信息作为标准错误（STDERR）输出。
• 如果退出状态码不是0或255，各个位掩码值表示的含义如下：

  1 2 3 4 5 6 7 8 9

  FLAG              BIT VALUE  MEANING   ================  =========  ==========================================   ERROR                     1  出现了一个不严重的错误   ALREADY_RUNNING           2  --pid选项指定的文件已存在，并且对应的PID在运行中   CAUGHT_SIGNAL             4  Caught SIGHUP, SIGINT, SIGPIPE, or SIGTERM   NO_SLAVES_FOUND           8  没有检测到从库或集群节点   TABLE_DIFF               16  本次校验至少有一个分块的数据不同   SKIP_CHUNK               32  至少有一个数据分块被跳过   SKIP_TABLE               64  至少有一个表被跳过

常用参数

–ask-pass

通过提示输入密码，而不是在命令行指定密码。

–[no]check-binlog-format

默认：yes
检查binlog格式。
如果binlog格式不是STATEMENT，需要指定--no-check-binlog-format，如果不指定此项，会报错。

–[no]check-replication-filters

默认：yes
pt-table-checksum会检查复制过滤相关的参数，例如，binlog_ignore_db，replicate_do_db等。如果检测到已配置任何复制过滤参数，它将会终止校验，并输出错误信息。

如果只是校验指定的数据库或表，且没有被复制过滤掉，则可以指定--no-check-replication-filters来进行数据校验。
如果被校验的表在主库存在，但是在从库被复制过滤掉了，则会导致复制中断卡住。

–chunk-time

值类型：浮点数
默认：0.5(s)
根据这个时间来动态的调整数据分块的大小，以使每个分块的校验执行时间不超过此值。

–databases

缩写形式：-d
指定需要校验的数据库，多个库以逗号分隔。

–databases-regex

使用正则表达式的形式来指定需要校验的数据库。

–host

缩写形式：-h
值类型：字符串
默认：localhost

需要连接的服务器的主机地址。

–ignore-databases

指定需要忽略校验的数据库，多个库以逗号分隔。

–ignore-databases-regex

值类型：字符串
以正则表达式的形式指定需要忽略的数据库。

–ignore-tables

指定需要忽略校验的表，多个表名以逗号分隔。表名前面可以指定数据库名。
--replicate选项指定的表，始终会被忽略掉。

–ignore-tables-regex

以正则表达式的形式指定需要忽略校验的表。

–password

缩写形式：-p
数据库连接的密码，如果密码包括逗号（,），则必须使用反斜杠。

–port

缩写形式：-P
数据库连接的端口。

–recursion-method

默认：processlist,hosts
指定搜索从库的递归方法。当pt-table-checksum无法搜索到从库时，其可以正常的进行数据校验，但是无法直接检测从库数据与主库是否一致。
如果搜索不到从库，可以尝试指定其他的递归方法，或者使用dsn来指定需要检测的从库。

允许的方法有：

1
2
3
4
5
6
7

METHOD       USES
===========  =============================================
processlist  SHOW PROCESSLIST
hosts        SHOW SLAVE HOSTS
cluster      SHOW STATUS LIKE 'wsrep\_incoming\_addresses'
dsn=DSN      DSNs from a table
none         Do not find slaves

详细可参考官方文档：https://www.percona.com/doc/percona-toolkit/2.2/pt-table-checksum.html#cmdoption-pt-table-checksum--recursion-method

–replicate

默认：percona.checksums
将校验结果写入到指定的库和表中。

本文后续所说的校验信息表即指该表。

表结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CREATE TABLE checksums (
   db             CHAR(64)     NOT NULL,
   tbl            CHAR(64)     NOT NULL,
   chunk          INT          NOT NULL,
   chunk_time     FLOAT            NULL,
   chunk_index    VARCHAR(200)     NULL,
   lower_boundary TEXT             NULL,
   upper_boundary TEXT             NULL,
   this_crc       CHAR(40)     NOT NULL,
   this_cnt       INT          NOT NULL,
   master_crc     CHAR(40)         NULL,
   master_cnt     INT              NULL,
   ts             TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
   PRIMARY KEY (db, tbl, chunk),
   INDEX ts_db_tbl (ts, db, tbl)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

lower_boundary和upper_boundary列的类型可以设置为BLOB，详情参考--binary-index参数。

默认情况下，--[no]create-replicate-table是开启的。因此，当--replicate指定的库和表不存在时，pt-table-checksum会自动创建这些库和表。

如果用于校验的MySQL用户没有新建表的权限，则也可以在校验主从数据之前，使用上述表结构手动创建该表。

--replicate参数指定的表，在校验数据一致性时，默认是被忽略的。即，--ignore-tables参数会自动的包含该表。

–[no]replicate-check

默认：yes
在校验完每一个表后，校验从库与主库的数据一致性。
pt-table-checksum会在所有检测到的从库上，执行一个简单的SELECT语句，来比较从库的校验值与主库的校验值是否一致。如果不一致，则将不一致的分块的数量，输出到DIFFS列。

–replicate-check-only

如果指定此选项，pt-table-checksum不会校验任何表，而是使用上一次数据校验存储在--replicate指定的校验信息表的校验数据，来检测主从数据的一致性。
使用该选项时，只会输出校验结果不一致的表的信息。

该选项只和--[no]replicate-check选项搭配使用。这两个选项配合起来可以做定时校验和监控。例如，使用cron任务定时校验主从数据时指定--no-replicate-check，然后再在Zabbix或Nagios监控时，指定--replicate-check-only来检测主从数据一致性。

–slave-user

值类型：字符串
连接从库时所使用的MySQL用户名。
当连接从库的用户名和主库不同时，可以使用此参数单独指定从库用户。

–slave-password

值类型：字符串
指定连接从库的密码，可以和参数--slave-user一起使用，并且所有从库的密码都必须是一样的。

–set-vars

值类型：array
设置MySQL变量值，每个变量值的形式为variable=value，多个变量以逗号分隔。
pt-table-checksum默认设置的变量值为：

1
2

wait_timeout=10000
innodb_lock_wait_timeout=1

当无法设置变量值的时候，pt-table-checksum会输出相应的警告信息，并继续进行校验。

–socket

缩写形式：-S
指定socket文件。

–tables

缩写形式：-t
指定需要检查的表，多个表用逗号分隔。表名前面可以加上数据库的名称。

–tables-regex

使用正则表达式的形式指定需要检查的表。

–user

缩写形式：-u

指定连接的用户名。

–where

只校验符合WHERE条件的数据。

通常情况下，如果某个表每天只会往里面新增写入数据，则可以使用WHERE条件只校验昨天的数据，以加快校验速度。
如：

1

pt-table-checksum --where "ts > CURRENT_DATE - INTERVAL 1 DAY"

其他参数

–binary-index

该参数选项和--create-replicate-table选项一起使用，使用该参数会将校验信息表的lower_boundary和upper_boundary列定义为BLOB类型。
如果被校验的表的索引包含binary数据类型，则需要使用选项。

–check-interval

值类型：时间
默认：1
当发现从库的延迟时间超过--max-lag定义的时间后，需要休眠等待的时间。

–[no]check-plan

默认：yes
在执行查询语句之前使用EXPLAIN检查执行计划，以保证校验工作的安全性。
查询语句包括确定表数据分块的上下边界的语句，和查询分块的语句。如果MySQL将使用一个糟糕的执行计划，pt-table-checksum会跳过这个分块。

–check-slave-lag

值类型：字符串
指定需要检测复制延迟的从库，参数值是一个DSN，并且继承主库的属性和连接选项（--port、--user等）。
默认情况下，pt-table-checksum会监测所有从库的延迟。如果某些从库配置了延迟复制，则可以使用此参数指定只需要检测延迟的从库，以忽略那些配置了复制延迟的从库。

–[no]check-slave-tables

默认：yes
检查主库的表存在于从库上，且具有--columns选项指定的所有的列。
如果从库上不存在某些表，或者缺少某些列，在校验数据一致性的时候，pt-table-checksum将会导致复制中断。
如果确定从库的表和列都和主库的一样，则可以禁用此项。

–chunk-index

值类型：字符串
指定将表进行分块所使用的索引。
默认情况下，pt-table-checksum会自动选择最合适的索引来对表进行分块。使用此选项可以使用指定的索引。如果指定的索引不存在，则pt-table-checksum会使用其默认的行为来选择索引。
建议在校验单表数据时可以使用此参数，而不要在校验整个服务器的数据时使用此参数。

–chunk-index-columns

值类型：整数
和参数--chunk-index一起使用，指定只使用指定（复合）索引的最左边的几列。

–chunk-size

默认：1000
每一个数据分块的行数。允许的后缀有：k，M，G。
推荐在大多数情况下，不要使用此参数，而是使用--chunk-time参数。

使用该参数可能会引起一个问题：

如果分块所使用的索引不是唯一的，则可能导致分块的行数比实际指定的要大得多。
例如，一个分块使用索引可以检索到的行数为10000，则使用该索引的WHERE语句是无法正好匹配1000条记录的，那么这个分块就会包含10000行记录。
这样的分块，很可能会由于超过--chunk-size-limit的限制而被跳过。

–chunk-size-limit

值类型：浮点数
默认：2.0
指定分块的行数最多可以超过--chunk-size参数指定的行数的多少倍。

pt-table-checksum使用EXPLAIN来估算分块的行数。如果这个估算值超过了--chunk-size参数值的某个倍数（由--chunk-size-limit定义），则分块会被跳过。

最小值是1，表示分块的行数不能超过--chunk-size指定的值。由于分块的行数是估算的，所以不建议指定为1。
当参数值为0时，则不会检查是否超过指定的行数。

–columns

缩写形式：-c
值类型：array
多个列以逗号分隔。只校验这些列。如果一个表不包含该选项指定的任何一列，则会被跳过。
该选项对所有的表有效，所以一般在进行单表校验时，指定此选项才是有意义的，除非被校验的多个表具有相同的列。

–config

值类型：array
指定配置文件，多个值以逗号分隔。
如果使用该参数，该选项必须放在第一个位置。

–[no]create-replicate-table

默认：yes
如果--replicate选项指定的数据库和表不存在，则创建该库和表。表结构与--replicate选项下提到的表结构一样。

–defaults-file

缩写形式：-F
只从给定的文件读取MySQL的参数。必须使用绝对路径来指定。

–[no]empty-replicate-table

默认：yes
在校验每个表之前，删除之前存在校验信息表的该表的校验数据。

该选项不会TRUNCATE整个表，而只是在校验每个表之前，删除该表相关的校验数据。
如果使用--resume选项从之前的一个校验继续执行校验，则重新开始校验时所在的那张表的校验数据不会被清除掉。

–engines

缩写形式：-e
指定需要校验的表的存储引擎。

–explain

可以多次使用该参数选项。默认是0次。
输出当前数据校验的查询语句，但不执行。该选项会使--[no]empty-replicate-table选项无效。
当使用该参数一次时，会输出表的校验查询语句（不含具体的上下边界值）。
当使用该参数两次时，会迭代的调用数据分块算法，输出表的每一个分块的上、下边界值，但是不会执行这些校验查询语句。

–float-precision

值类型：整数
FLOAT和DOUBLE类型转换成字符串时的精度。
指定浮点数被四舍五入（ROUND()）转换成字符串时，小数点后保留的数字的个数。
默认情况下，浮点数没有被四舍五入，而是被使用CONCAT()函数转换成字符串。

–function

值类型：字符串
校验时使用的hash函数，包括FNV1A_64、MURMUR_HASH、SHA1、MD5、CRC32等。
默认的是CRC32。

–help

显示帮助信息。

–ignore-columns

指定需要忽略校验的列名，多个列以逗号分隔。
如果一个表的所有列都在--ignore-columns指定忽略的列中，则会跳过该表。

–ignore-engines

默认：FEDERATED,MRG_MyISAM
指定需要忽略校验的存储引擎，多个值以逗号分隔。

–max-lag

类型：时间
默认：1s

当发现从库的延迟超过该参数的值时，则会暂停校验，直至从库的延迟小于该值。
pt-table-checksum在校验完每一个分块后，都会检查所有检测到的从库的延迟（根据Seconds_Behind_Master判断）。如果延迟大于该值，则会休眠等待--check-interval定义的秒数，然后再次检查从库。
如果从库停止了，pt-table-checksum则会一直等待，直至从库重新启动。当从库重新启动且延迟不再大的时候，会继续进行校验。

–max-load

值类型：array
默认：Threads_running=25
在校验完每一个分块后，执行SHOW GLOBAL STATUS，检查相关状态的值是否超过该选项定义的阈值。当超过阈值时，pt-table-checksum会暂停校验；当值低于阈值后，会继续进行校验。
该选项支持指定多个MySQL status变量（以逗号分隔），并为其分别指定阈值（可选的。形式：=MAX_VALUE或:MAX_VALUE）。如果没有指定阈值，则pt-table-checksum会将当前值增大20%，作为阈值。
例如，可以指定Threads_connected=110，来限定当Threads_connected超过110时，则暂停校验。

–pid

创建指定的PID文件。

–progress

type：array
默认值：time,30
每隔多久将执行的进度信息以标准错误输出（STDERR）。
该参数的值由两部分构成，以逗号分隔。第一部分的取值可以是：percentage，time，或者iterations；第二部分指定每隔多久进行一次信息输出：in percentage，seconds，或者number of iterations。
pt-table-checksum会对许多耗时的操作输出进度信息，包括等待从库赶上主库（从库延迟时）。

–quiet

缩写形式：-q
可以多次叠加使用该选项，默认未使用。使用该选项使pt-table-checksum只输出最重要的信息，并且会使选项--progress无效。
指定该参数一次，则只会输出错误、警告，和具有不同校验值的表。
指定该参数两次，则只会输出错误信息。在这种情况下，可以使用退出状态码来判断是否有警告或者不同的校验值。

–recurse

值类型：整数
在主从结构中，递归搜索从库的层数。
默认是无限的。

–replicate-check-retries

值类型：整数
默认：1
当发现某个表的校验结果不一致时，对该表进行重复校验的次数。只有当经过这些次数的校验后，还存在的不一致的校验信息才作为最终的结果。

使用这个参数，是为了解决使用-–resume参数而导致的虚假的主从不一致信息。当该参数值为2或者更大时，基本可以消除这些虚假的主从不一致信息。
详情可以参考以下链接：

• Bug #1311654: https://bugs.launchpad.net/percona-toolkit/+bug/1311654

–replicate-database

pt-table-checksum在进行数据校验时，执行的USE database语句始终使用该参数指定的数据库。
默认情况下，会将当前校验的表所在的库，作为USE database的库来执行。
使用该参数选项来避免复制过滤引起的问题（过滤参数如binlog_ignore_db，replicate_ignore_db等）。

–resume

在上一次校验中断后，使用此参数可以继续上一次的校验。该参数会禁用--[no]empty-replicate-table参数。
如果pt-table-checksum在校验完所有的表之前被终止了，则使用--resume参数再次启动pt-table-checksum时，会从上次校验的最后一个表的最后一个校验完成的分块开始校验。

–retries

值类型：整数
默认：2

当出现一个非致命的错误时，对该分块进行重试校验的次数。
非致命的错误包括锁等待超时、校验查询的SQL线程被kill了，等等。

–run-time

值类型：时间
pt-table-checksum执行校验的总时长。
允许的时间后缀有：s（秒），m（分），h（时），d(天)。

当校验很多表时，可以将该参数和--resume参数结合在一起使用。

使用--run-time在指定分配的时间进行校验后退出，然后使用--resume参数在指定时间继续之前的校验。

–separator

值类型：字符串
默认：#
定义函数CONCAT_WS()使用的分隔符。该参数定义的字符，用于在校验时连接各列的值。

–slave-skip-tolerance

值类型：浮点数
默认：1.0

当某个表在主库只被作为一个数据分块校验，而在从库的数据大小却超过了可接受的最大值时，该表会被跳过。由于表的行数是粗略估计的，在多数情况下，由于很小的主从数据差异而进行的表跳过是没有必要的。
该参数的定义可以减少这种不必要的跳过。
使用该参数可指定从库的行数超过主库的行数的最大的容忍值。
例如，当参数值为1.2时，表在从库的行数最多是主库的1.2倍。

–trim

对校验数据的VARCHAR列添加TRIM()函数。
MySQL 5.0之后的版本，VARCHAR列会保存字符串首尾的空格；但是MySQL 5.0之前的版本会移除这些空格。
指定该选项，可以移除VARCHAR列数据的首尾的空格。

–version

显示程序的版本。

–[no]version-check

默认：yes
自动的检查Percona Toolkit，MySQL，和其他程序的版本。
首先，pt-table-checksum会检查它自己和其他软件的版本，检查的软件如MySQL、Perl、Perl module DBD::mysql等等。然后，它会检查和输出这些软件版本的已知问题。

使用示例

用法

1

pt-table-checksum [OPTIONS] [DSN]

系统环境

• OS Version: CentOS 6
• DB Version: MySQL 5.6.29
• PT Version: pt-table-checksum 2.2.18
• 主从环境:
  主从端口相同，都是3376。
  • Master: 192.168.0.162:3376
  • Slave1: 192.168.0.161:3376

安装依赖软件

安装 Perl, DBI, DBD::mysql等

1

shell> yum install perl perl-devel perl-Time-HiRes perl-DBI perl-DBD-MySQL perl-Digest-MD5

安装Percona Toolkit

1
2
3
4
5

shell> wget percona.com/get/percona-toolkit.tar.gz
shell> tar zxvf percona-toolkit.tar.gz
shell> cd percona-toolkit-2.2.18
shell> ./bin/pt-table-checksum --version
pt-table-checksum 2.2.18

新建MySQL帐号

新建账号pt_table_check用于连接主库和从库进行校验：

1
2

mysql> GRANT SELECT, PROCESS, SUPER, REPLICATION SLAVE ON *.* TO pt_table_check@'%' IDENTIFIED BY 'checksum123';
mysql> GRANT CREATE, INSERT, UPDATE, DELETE ON percona_schema.* TO pt_table_check@'%';

执行数据校验

在主库上执行

校验表road_to_dba.t_int主从数据的一致性：

1

shell> ./bin/pt-table-checksum --socket=/tmp/mysql3376.sock --user=pt_table_check --password='checksum123' --tables=road_to_dba.t_int --no-check-binlog-format --replicate=percona_schema.checksums

结果：

1
2

            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
09-19T18:50:19      0      1        9       1       0   0.042 road_to_dba.t_int

可以从DIFFS列看出有一个数据分块的主从数据不一致。

查看差异汇总

在从库执行

1
2
3
4
5
6
7
8
9
10
11
12
13

mysql> SELECT db, tbl, SUM(this_cnt) AS total_rows, COUNT(*) AS chunks
FROM percona_schema.checksums
WHERE (
 master_cnt <> this_cnt
 OR master_crc <> this_crc
 OR ISNULL(master_crc) <> ISNULL(this_crc))
GROUP BY db, tbl;
+-------------+-------+------------+--------+
| db          | tbl   | total_rows | chunks |
+-------------+-------+------------+--------+
| road_to_dba | t_int |         10 |      1 |
+-------------+-------+------------+--------+
1 row in set (0.00 sec)

从以上查询结果可以看出：

表road_to_dba.t_int总共有一个分块（chunks）的主从数据不一致。

或者

1
2
3
4
5
6
7

mysql> SELECT * FROM percona_schema.checksums WHERE master_cnt <> this_cnt OR master_crc <> this_crc OR ISNULL(master_crc) <> ISNULL(this_crc);
+-------------+-------+-------+------------+-------------+----------------+----------------+----------+----------+------------+------------+---------------------+
| db          | tbl   | chunk | chunk_time | chunk_index | lower_boundary | upper_boundary | this_crc | this_cnt | master_crc | master_cnt | ts                  |
+-------------+-------+-------+------------+-------------+----------------+----------------+----------+----------+------------+------------+---------------------+
| road_to_dba | t_int |     1 |   0.000546 | NULL        | NULL           | NULL           | 2e1ed7d3 |       10 | 17818634   |          9 | 2016-09-19 18:50:19 |
+-------------+-------+-------+------------+-------------+----------------+----------------+----------+----------+------------+------------+---------------------+
1 row in set (0.00 sec)

从以上查询可以看出：

表road_to_dba.t_int的分块1的主从数据不一致。该分块在主库的行数（master_cnt）为9，在从库的行数（this_cnt）为10；该分块在主库的校验值（master_crc）为17818634，在从库的校验值（this_crc）为2e1ed7d3；

参考文档

• Percona官方文档：https://www.percona.com/doc/percona-toolkit/2.2/pt-table-checksum.html

大清早的起来，打开手机看到Zabbix的邮件提醒，MariaDB数据库备份失败，数据库的备份计划已经正常运行将近一年了，于是对于这次备份失败很是好奇。远程连上服务器，查看XtraBackup备份日志的部分信息如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

160910 00:05:01 Connecting to MySQL server host: localhost, user: xxx, password: set, port: xxx, socket: /var/lib/mysql/mysql.sock
Using server version 10.0.23-MariaDB-enterprise-log
innobackupex version 2.3.5 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 45cda89)
incremental backup from 0 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /opt/mysql_data
xtrabackup: open files limit requested 65535, set to 65535
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 50331648
Found and using lsn: 846260275194 for name backup-53309-all_databases
xtrabackup: error: log block numbers mismatch:
xtrabackup: error: expected log block no. 586990567, but got no. 587187167 from the log file.
xtrabackup: error: it looks like InnoDB log has wrapped around before xtrabackup could process all records due to either log copying being too slow, or  log files being too small.
xtrabackup: Error: xtrabackup_copy_logfile() failed.

原因分析

主要错误日志：

1
2
3

xtrabackup: error: log block numbers mismatch:
xtrabackup: error: expected log block no. 586990567, but got no. 587187167 from the log file.
xtrabackup: error: it looks like InnoDB log has wrapped around before xtrabackup could process all records due to either log copying being too slow, or  log files being too small.

从以上错误日志可以看出，大概的意思是说：
XtraBackup在顺序拷贝完redo log末尾的数据后，重新从redo log的起始位置去拷贝时，发现起始位置的log block no.与刚才尾部的no.不连续。

当然日志里也进一步给出了解释：
在XtraBackup处理完所有的redo log数据之前，redo log起始位置的数据就被后续写入的log覆盖掉了。原因可能是拷贝redo log的速度太慢了，或者redo log文件的大小设置太小了。

结合从网上找到的资料，引起以上问题的可能原因如下：

1. redo log的文件大小（innodb_log_file_size*innodb_log_files_in_group）设置过小；
2. XtraBackup拷贝redo log的速度有些慢（可能受其他的系统任务的比较频繁的磁盘IO影响）；
3. 如果备份文件是存储在远程文件系统上，则还有可能是受网络带宽较小或拥堵导致；

本次问题分析

redo log相关的系统变量：

1
2

innodb_log_files_in_group = 2
innodb_log_file_size = 50331648    # 48M

从以上设置可以看出，MariaDB设置的redo log大小是2 * 48M，文件大小设置的有些小。

备份文件是存在远程文件系统的，查看了下Zabbix系统监控的当时的网络流量很小，而且此前备份一直是正常的，排除网络带宽和流量拥堵的影响。

此时又想起了一件事……
备份计划是每天00:05开始的，就在上个月我在主库添加了一个定时任务，每天对某个日志表进行归档操作，执行时间也是00:05。
应该是这个导致了00:05后redo log的快速循环写入，同时redo log文件设置的总大小又不大，导致XtraBackup在备份的时候，出现错误“log block numbers mismatch”。

解决方法

由于innodb_log_file_size变量不能动态更改，暂时也不能重启数据库更改变量值。所以将XtraBackup的开始时间推迟了一段时间，以错开日志归档时的IO高峰期。

备份计划推迟后，昨天的备份没有再次出现错误，后续还待进一步观察是否会再次出现此错误。

参考文章

• 链接1：https://bugs.launchpad.net/percona-xtrabackup/+bug/1050355
• 链接2：https://bugs.launchpad.net/percona-xtrabackup/+bug/1206309

mysqld

启动方式：

本文假设已添加MySQL安装目录/usr/local/mysql/bin至系统环境变量PATH
所以在执行MySQL相关命令时，不再切换到MySQL安装目录，或者使用完整路径。

1
2
3
4

shell > mysqld --user=mysql &

[1] 23046
2016-06-24 22:57:33 0 [Note] mysqld (mysqld 5.6.29-log) starting as process 23046 ...

1. mysqld，即MySQL服务器。MySQL安装过程中，很多工作是由mysqld来完成的。
2. 使用mysqld启动MySQL服务器之后，系统仅有一个mysqld进程。如下：

   1 2 3

   shell> ps aux | grep mysqld mysql 23046 0.2 9.6 780496 48480 pts/0 Sl 22:57 0:00 mysqld --user=mysql

mysqld_safe

启动方式：

1
2
3
4
5

shell> mysqld_safe --user=mysql &

[1] 23159
160624 23:11:43 mysqld_safe Logging to '/data/mysql/mysql3376/data/error.log'.
160624 23:11:43 mysqld_safe Starting mysqld daemon with databases from /data/mysql/mysql3376/data

1. mysqld_safe启动时会调用mysqld来启动MySQL服务器
2. mysqld_safe是mysqld的守护进程，添加了一些安全特性，当MySQL服务器出现错误时会重启mysqld。
3. 使用mysqld_safe启动MySQL服务器之后，系统有两个进程：mysqld和mysqld_safe。如下：

   1 2 3 4

   shell> ps aux | grep mysqld root 2892 0.1 0.2 106232 1400 pts/0 S 11:43 0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --user=mysql mysql 3934 0.1 9.6 780496 48472 pts/0 Sl 11:43 0:00 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql/mysql3376/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/mysql3376/data/error.log --pid-file=/data/mysql/mysql3376/data/node601.pid --socket=/tmp/mysql3376.sock --port=3376

mysql.server

启动方式：

1
2
3
4
5

# 启动MySQL
shell> mysql.server start

# 关闭MySQL
shell> mysql.server stop

1. mysql.server是一个SHELL脚本，通过调用mysqld_safe来启动MySQL；
2. 使用RPM或其他的Linux系统的包管理器安装MySQL时，mysql.server通常会被安装在/etc/init.d路径下，文件名为mysql或mysqld；

3. 使用二进制包或源码安装时，mysql.server在MySQL安装目录的support-files下，可以手动将其复制到/etc/init.d路径下；

   1 2	shell> cp mysql.server /etc/init.d/mysql shell> chmod +x /etc/init.d/mysql

   此时也可以使用以下命令来启动和关闭MySQL

   1 2 3 4 5 6 7 8 9

   # 启动 shell> service mysql start # shell> /etc/init.d/mysql start # 关闭 shell> service mysql stop # shell> /etc/init.d/mysql stop # 重启 shell> service mysql restart # shell> /etc/init.d/mysql restart

4. 使用mysql.server启动MySQL服务器之后，系统有两个进程：mysqld和mysqld_safe。如下：

   1 2 3 4

   shell> ps aux | grep mysqld root 4453 0.2 0.2 11472 1388 pts/0 S 12:41 0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/data/mysql/mysql3376/data --pid-file=/data/mysql/mysql3376/data/node601.pid mysql 5508 0.3 9.6 780496 48480 pts/0 Sl 12:41 0:00 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql/mysql3376/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/mysql3376/data/error.log --pid-file=/data/mysql/mysql3376/data/node601.pid --socket=/tmp/mysql3376.sock --port=3376

以上为使用mysqld、mysqld_safe、mysql.server进行MySQL单个实例的启动，使用[mysqld_multi]进行MySQL多实例的启动，将会在本文后面进行介绍。

MySQL配置文件

在介绍MySQL多实例之前，先介绍下MySQL配置文件。

1. 在启动MySQL时，若没有在命令行显式指定配置文件的路径，默认情况下，MySQL会从以下位置依次读取配置文件。并且，后读取的配置文件中的参数会优先于其前面的配置文件的参数生效。

   1 2 3 4

   /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

   可以通过以下命令查看MySQL默认读取的配置文件：

   1 2 3 4 5 6

   shell> mysqld --verbose --help | grep -A 5 'Default options' 2016-06-25 12:50:43 0 [Note] mysqld (mysqld 5.6.29-log) starting as process 5602 ... 2016-06-25 12:50:43 5602 [Note] Plugin 'FEDERATED' is disabled. Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

2. MySQL配置文件由一个或多个group组成，每个group的名称为要设置参数的MySQL程序的名称或者组名。

   • 常见的group有：[mysqld]、[mysql]、[client]等。
3. 以MySQL程序命名的group包含的参数，对该程序生效。比如：
   • [mysqld]、[mysql]下的参数分别对mysqld服务器程序和mysql客户端程序生效；
   • [mysqldump]下的参数对mysqldump程序生效；
   • 等等…
4. [client]分组下的参数，对所有的MySQL客户端程序生效。
   • 如果某个参数不能被所有的MySQL客户端程序识别，不要把该参数放在[client]分组下。否则，会引起不能识别该参数的程序报错并退出。
5. MySQL常用程序读取的配置文件中group名称：
   1. mysql：[mysql]、[client]
   2. mysqld：[mysqld]、[server]
   3. mysqld_safe：[mysqld]、 [server]、[mysqld_safe]；为了向后兼容，也读取[safe_mysqld]分组下的参数；
   4. mysql.server：[mysql.server]、[mysqld]；为了向后兼容，也读取[mysql_server]下的参数；

MySQL多实例

应用场景

1. 在同一台服务器上，不同的业务使用不同的实例，互不影响；
2. MySQL服务器随着连接数的上升，性能会下降，可以将连接数比较多的单个实例拆分成多个实例；
3. 多实例在互联网公司比较常用；

多实例参数

MySQL多个实例的以下参数应保持不同：

1. 数据目录：datadir=dir_name
2. 端口：port=port_num
3. socket文件名称：socket=file_name
4. pid文件名称：pid-file=file_name
5. 一些日志的名称和路径
   1. 通用查询日志：general_log_file=file_name
   2. 二进制日志：log-bin=file_name
   3. 慢查询日志：slow_query_log_file=file_name
   4. 错误日志：log-error=file_name

默认情况下，pid文件、以及以上各种日志文件，在各实例的数据目录下面，若已设置datadir为不同的目录，可不再显式设置这些选项。

设置tmpdir为不同的目录，可以方便的识别临时文件是由哪些MySQL实例产生的。当然，这并不是必须要设置的。

安装多实例

参照《MySQL安装和初始化》一文的介绍，现有系统已安装一个端口为3376的实例，在此基础上新增加一个端口为3377的实例。

1. 关键参数对比

   1. 端口为3376的实例的参数：

      1 2 3 4 5 6

      [mysqld] port = 3376 socket = /tmp/mysql3376.sock datadir = /data/mysql/mysql3376/data tmpdir = /data/mysql/mysql3376/tmp log-bin = /data/mysql/mysql3376/logs/mysql-bin

   2. 端口为3377的实例的参数：

      1 2 3 4 5 6

      [mysqld] port = 3377 socket = /tmp/mysql3377.sock datadir = /data/mysql/mysql3377/data tmpdir = /data/mysql/mysql3377/tmp log-bin = /data/mysql/mysql3377/logs/mysql-bin

2. 新建目录

   1	shell> mkdir -pv /data/mysql/mysql3377/{data,logs,tmp}

3. 修改配置文件

   • 将3376实例的配置文件复制到3377的目录下，并批量修改配置文件中的3376为3377。
     由于以上各参数值都是由实例相应的端口组成，所以这里只需要替换配置文件中的端口号，即可达到不同实例不同的参数。

     1 2 3

     shell> cp /etc/my.cnf /data/mysql/mysql3377/my3377.cnf shell> cd /data/mysql/mysql3377 shell> sed -i 's/3376/3377/g' my3377.cnf

   • 替换之后配置文件的参数如下：

     1 2 3 4 5 6 7 8 9 10 11 12 13 14

     shell> grep 3377 my3377.cnf # client port = 3377 socket = /tmp/mysql3377.sock # mysqld port = 3377 datadir = /data/mysql/mysql3377/data tmpdir = /data/mysql/mysql3377/tmp socket = /tmp/mysql3377.sock log-bin = /data/mysql/mysql3377/logs/mysql-bin server-id =1613377 innodb_data_home_dir = /data/mysql/mysql3377/data innodb_log_group_home_dir = /data/mysql/mysql3377/logs

4. 修改目录权限

   1 2 3 4 5 6 7 8

   shell> chown -R mysql:mysql /data/mysql/mysql3377 shell> ll /data/mysql/mysql3377 total 4 drwxr-xr-x 2 mysql mysql 6 Jun 25 16:56 data drwxr-xr-x 2 mysql mysql 6 Jun 25 16:56 logs -rwxr-xr-x 1 mysql mysql 3020 Jun 25 17:06 my3377.cnf drwxr-xr-x 2 mysql mysql 6 Jun 25 16:56 tmp

5. 初始化MySQL 3377实例

   1 2	shell> cd /usr/local/mysql/ shell> ./scripts/mysql_install_db --defaults-file=/data/mysql/mysql3377/my3377.cnf --user=mysql

6. 启动3377实例

   1 2 3 4

   shell> mysqld --defaults-file=/data/mysql/mysql3377/my3377.cnf --user=mysql & [2] 6961 2016-06-25 17:40:20 0 [Note] mysqld (mysqld 5.6.29-log) starting as process 6961 ...

   查看后台进程，已启动两个MySQL实例：3376和3377

   1 2 3 4 5

   shell> netstat -nalp | grep mysqld tcp 0 0 :::3376 :::* LISTEN 6857/mysqld tcp 0 0 :::3377 :::* LISTEN 6961/mysqld unix 2 [ ACC ] STREAM LISTENING 23304 6857/mysqld /tmp/mysql3376.sock unix 2 [ ACC ] STREAM LISTENING 23462 6961/mysqld /tmp/mysql3377.sock

7. 关闭3377实例

   1 2 3 4

   shell> mysqladmin -S /tmp/mysql3377.sock -vvv shutdown Shutdown signal sent to server; Waiting for pid file to disappear [2]+ Done mysqld --defaults-file=/data/mysql/mysql3377/my3377.cnf --user=mysql

mysqld_multi

从以上配置3377实例的过程可以看出，可以为每个实例指定单独的配置文件。在启动时，指定对应的配置文件（--defaults-file）；在关闭时，指定实例对应的socket（或者ip和端口），即可分别管理每一个实例。

而多个实例的管理，也可以采用另一种方法：各个实例的参数都在同一个配置文件里配置，使用mysqld_multi管理这些实例。

这里的“配置文件”可以是默认的/etc/my.cnf，也可以是由--defaults-file指定的。

mysqld_multi相关配置文件

关于mysqld_multi的配置例子，可以使用命令mysqld_multi --example查看，如下为其中的一部分：

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

shell > mysqld_multi --example

[mysqld_multi]
mysqld     = /usr/local/mysql/bin/mysqld_safe
mysqladmin = /usr/local/mysql/bin/mysqladmin
user       = multi_admin
password   = my_password

[mysqld2]
socket     = /tmp/mysql.sock2
port       = 3307
pid-file   = /usr/local/mysql/data2/hostname.pid2
datadir    = /usr/local/mysql/data2
language   = /usr/local/mysql/share/mysql/english
user       = unix_user1

[mysqld3]
mysqld     = /path/to/mysqld_safe
ledir      = /path/to/mysqld-binary/
mysqladmin = /path/to/mysqladmin
socket     = /tmp/mysql.sock3
port       = 3308
pid-file   = /usr/local/mysql/data3/hostname.pid3
datadir    = /usr/local/mysql/data3
language   = /usr/local/mysql/share/mysql/swedish
user       = unix_user2

[mysqld_multi]分组下的参数，对mysqld_multi程序自身生效；[mysqldN]分组下的参数，对特定的实例生效（N为正整数）。

1. [mysqld_multi]分组相关的参数选项如下：

   1. mysqld=prog_name
      • 用于启动MySQL的程序，可以是mysqld，也可以是mysqld_safe
      • 当mysqld指定为mysqld或者mysqld_safe时，启动实例时，会分别读取这两个程序相应的group的配置文件；
   2. mysqladmin=prog_name
      • 用于关闭MySQL服务的mysqladmin程序路径

   3. user=user_name

      • 调用mysqladmin时使用的MySQL用户名
      • 每一个被管理的实例中都需要有此用户名，且密码相同（如果密码不同，无法同时关闭多个实例），且具有SHUTDOWN权限
      • 可以使用以下命令在每一个实例中新建该用户

        1 2	mysql> CREATE USER 'multi_admin'@'localhost' IDENTIFIED BY 'multipass'; mysql> GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost';

   4. password=password

      • 调用mysqladmin时，所使用的user的密码
   5. log=file_name
      • 用来记录mysqld_muti的启动日志
2. [mysqldN]
   • 该分组的参数，对特定的MySQL实例生效
   • [mysqld]分组下可用的参数，都可以针对各个实例在[mysqldN]分组下再特别指定
   • N为正整数，建议N为端口号，便于区分实例的配置文件
3. [mysqld]、[mysqld_safe]
   • 通用设置，对所有的实例都生效

配置本文的3376、3377实例

在/etc/my.cnf文件添加[mysqld_multi]、[mysqld3376]、[mysqld3377]分组的参数选项，如下：

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

[mysqld_multi]
mysqld = /usr/local/mysql/bin/mysqld
mysqladmin = /usr/local/mysql/bin/mysqladmin
user = multi_admin
password = multipass
log = /data/mysql/multi.log

[mysqld3376]
port = 3376
socket = /tmp/mysql3376.sock
datadir = /data/mysql/mysql3376/data
tmpdir = /data/mysql/mysql3376/tmp
log-bin = /data/mysql/mysql3376/logs/mysql-bin
server-id = 1613376
innodb_data_home_dir = /data/mysql/mysql3376/data
innodb_log_group_home_dir = /data/mysql/mysql3376/logs
# 必须在此指定user=mysql（mysql为Linux系统用户）
# 或者，在[mysqld]分组下指定全局user=mysql，否则无法启动MySQL
user = mysql

[mysqld3377]
port = 3377
socket = /tmp/mysql3377.sock
datadir = /data/mysql/mysql3377/data
tmpdir = /data/mysql/mysql3377/tmp
log-bin = /data/mysql/mysql3377/logs/mysql-bin
server-id = 1613377
innodb_data_home_dir = /data/mysql/mysql3377/data
innodb_log_group_home_dir = /data/mysql/mysql3377/logs
user = mysql

mysqld_multi启动/关闭MySQL实例的方式

可以用来启动/关闭一个、多个或某个范围的实例
前提：已在配置文件中定义该实例对应分组的参数[mysqldN]

1. 单个实例：Ni

   1 2	shell> mysqld_multi start Ni shell> mysqld_multi stop Ni

2. 多个实例：Ni,Nj,...,Nk

   1 2	shell> mysqld_multi start Ni,Nj,Nk shell> mysqld_multi stop Ni,Nj,Nk

3. 某个范围的多个实例：Ni-Nj

   1 2	shell> mysqld_multi start Ni-Nj shell> mysqld_multi stop Ni-Nj

4. 多个分开的实例和某个范围的多个实例：Ni,...,Nj-Nk

   逗号,，破折号-前后不可以有空格，否则空格后面的字符将会被忽略

   1 2	shell> mysqld_multi start Ni,Nj-Nk shell> mysqld_multi stop Ni,Nj-Nk

启动/关闭本文的3376、3377实例

1. 启动3376实例

   1	mysqld_multi start 3376

   查看3376实例的mysqld进程是否已启动：

   1 2 3

   shell> ps aux | grep mysqld mysql 9686 0.2 9.6 780496 48484 pts/3 Sl 01:42 0:00 /usr/local/mysql/bin/mysqld --port=3376 --socket=/tmp/mysql3376.sock --datadir=/data/mysql/mysql3376/data --tmpdir=/data/mysql/mysql3376/tmp --log-bin=/data/mysql/mysql3376/logs/mysql-bin --server-id=1613376 --innodb_data_home_dir=/data/mysql/mysql3376/data --innodb_log_group_home_dir=/data/mysql/mysql3376/logs

2. 关闭3376实例

   • 实际测试时，即使已经在配置文件的[mysqld_multi]分组下指定了password参数的值，关闭MySQL实例时，仍然会报密码错误。需要在命令行显式指定password的值，才能关闭实例。（原因未知）

   • [mysqld_multi]的log中报错信息如下：

     1 2 3 4

     Stopping MySQL servers Warning: Using a password on the command line interface can be insecure. ^G/usr/local/mysql/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'multi_admin'@'localhost' (using password: YES)'

   • 使用以下命令关闭实例：

     1	mysqld_multi stop 3376 --password=multipass

3. 同时启动3376、3377实例

   1 2 3 4 5

   shell> mysqld_multi start 3376,3377 shell> ps aux | grep mysqld mysql 9845 1.0 9.6 780496 48468 pts/3 Sl 01:53 0:00 /usr/local/mysql/bin/mysqld --port=3376 --socket=/tmp/mysql3376.sock --datadir=/data/mysql/mysql3376/data --tmpdir=/data/mysql/mysql3376/tmp --log-bin=/data/mysql/mysql3376/logs/mysql-bin --server-id=1613376 --innodb_data_home_dir=/data/mysql/mysql3376/data --innodb_log_group_home_dir=/data/mysql/mysql3376/logs mysql 9848 1.0 9.6 780496 48456 pts/3 Sl 01:53 0:00 /usr/local/mysql/bin/mysqld --port=3377 --socket=/tmp/mysql3377.sock --datadir=/data/mysql/mysql3377/data --tmpdir=/data/mysql/mysql3377/tmp --log-bin=/data/mysql/mysql3377/logs/mysql-bin --server-id=1613377 --innodb_data_home_dir=/data/mysql/mysql3377/data --innodb_log_group_home_dir=/data/mysql/mysql3377/logs

   3376、3377这两个实例的进程已同时启动

4. 同时关闭3376、3377实例

   1 2 3 4

   shell> mysqld_multi stop 3376,3377 --password=multipass shell> ps aux | grep mysqld root 9958 0.0 0.1 103308 852 pts/3 S+ 01:55 0:00 grep mysql

   两实例的进程已同时被关闭。

多实例安装——使用现有实例安装

第3节中介绍的3377实例是全新安装的一个实例，安装完成后还需要进行初始化等操作。

新的实例的安装也可以在原有实例的数据的基础上进行安装。下面介绍在3377实例的基础上，来安装一个新的3378实例。

1. 新建3378实例的目录

   1	shell> mkdir -pv /data/mysql/mysql3378

2. 停止3377实例

   1 2 3 4

   shell> mysqladmin -vvv --socket=/tmp/mysql3377.sock shutdown Shutdown signal sent to server; Waiting for pid file to disappear [2]+ Done mysqld --defaults-file=/data/mysql/mysql3377/my3377.cnf

3. 将3377实例的数据等目录复制到3378目录

   1 2 3 4 5 6 7 8 9

   shell> cp -ar /data/mysql/mysql3377/* /data/mysql/mysql3378/ shell> cd /data/mysql/mysql3378 shell> ll total 8 drwxr-xr-x 4 mysql mysql 121 Jun 26 15:46 data drwxr-xr-x 2 mysql mysql 4096 Jun 26 15:45 logs -rwxr-xr-x 1 mysql mysql 3019 Jun 26 15:38 my3377.cnf drwxr-xr-x 2 mysql mysql 6 Jun 26 15:45 tmp

4. 修改3378实例的配置文件：datadir、socket、port等

   1 2 3

   shell> cd /data/mysql/mysql3378 shell> mv my3377.cnf my3378.cnf shell> sed -i 's/3377/3378/g' my3378.cnf

   修改后的配置信息如下：

   1 2 3 4 5 6 7 8 9 10 11 12

   shell> grep 3378 my3378.cnf port = 3378 socket = /tmp/mysql3378.sock port = 3378 datadir = /data/mysql/mysql3378/data tmpdir = /data/mysql/mysql3378/tmp socket = /tmp/mysql3378.sock log-bin = /data/mysql/mysql3378/logs/mysql-bin server-id =1613378 innodb_data_home_dir = /data/mysql/mysql3378/data innodb_log_group_home_dir = /data/mysql/mysql3378/logs

5. 删除3378数据目录的auto.cnf文件

   此文件为MySQL自动生成的server-uuid信息，需保证每个实例的该信息不同。
   删除此文件后，mysqld启动时会自动重新生成此文件。

   auto.cnf：

   1 2	[auto] server-uuid=fccde147-3b71-11e6-967d-0800272bc1fa

   1 2	shell> cd /data/mysql/mysql3378/data/ shell> rm -f auto.cnf

6. 启动3378实例

   1 2 3 4

   shell> mysqld --defaults-file=/data/mysql/mysql3378/my3378.cnf --user=mysql & [1] 3191 2016-06-26 16:18:26 0 [Note] mysqld (mysqld 5.6.29-log) starting as process 3191 ...

   确认实例是否启动成功：

   1 2 3

   shell> ps aux | grep mysqld mysql 3191 1.0 9.6 780496 48464 pts/2 Sl 16:18 0:00 mysqld --defaults-file=/data/mysql/mysql3378/my3378.cnf --user=mysql