我们在部署MySQL Replication从库时，通常是一开始就做好一个从库，然后随着业务的变化，数据也逐渐复制到从服务器。

但是，如果我们想对一个已经上线较久，有这大数据量的数据库部署复制从库时，应该怎么处理比较合适呢？

本文以我近期所做Zabbix数据库部署MySQL Replication从库为例，向大家呈现一种新的复制部署方式。由于Zabbix历史数据非常多，在转TokuDB之前的InnoDB引擎时，已经接近700G，转成TokuDB后，还有300多G，而且主要集中在trends_uint、history_uint等几个大表上。做一次全量备份后再恢复耗时太久，怕对主库写入影响太大，因此才有了本文的分享。

我大概分为几个步骤来做Zabbix数据迁移的：

1、初始化一个空的Zabbix库 …

背景介绍

线上的Zabbix数据库有几个大表数据量疯狂增长，单表已经超过500G，而且在早期也没做成分区表，后期维护非常麻烦。比如，想删除过期的历史数据，在原先的模式下，history、history_uint等几个大表是用 (itemid, clock) 两个字段做的联合主键，只用 clock 字段检索效率非常差。

TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是高压缩比，高 INSERT 性能，支持大多数在线修改索引、添加字段，特别适合像 Zabbix 这种高 INSERT，少 UPDATE 的应用场景。

迁移准备

欲使用 TokuDB 引擎，服务层可以选择和 MariaDB ，也可以选择 Percona ，鉴于我以往使用 Percona 的较多，因此本次也选择使用 Percona 版本集成 TokuDB 引擎。

当前最新版下载地址： …