我们在部署mysql replication从库时，通常是一开始就做好一个从库，然后随着业务的变化，数据也逐渐复制到从服务器。 但是，如果我们想对一个已经上线较久，有这大数据量的数据库部署复制从库时，应该怎么处理比较合适呢？ 本文以我近期所做zabbix数据库部署
我们在部署mysql replication从库时，通常是一开始就做好一个从库，，然后随着业务的变化，数据也逐渐复制到从服务器。
但是，如果我们想对一个已经上线较久，有这大数据量的数据库部署复制从库时，应该怎么处理比较合适呢？
本文以我近期所做zabbix数据库部署mysql replication从库为例，向大家呈现一种新的复制部署方式。由于zabbix历史数据非常多，在转tokudb之前的innodb引擎时，已经接近700g，转成tokudb后，还有300多g，而且主要集中在trends_uint、history_uint等几个大表上。做一次全量备份后再恢复耗时太久，怕对主库写入影响太大，因此才有了本文的分享。
我大概分为几个步骤来做zabbix数据迁移的：
1、初始化一个空的zabbix库2、启动复制，但设置忽略几个常见错误（这几个错误代码对应具体含义请自行查询手册）#忽略不重要的错误，极端情况下，甚至可以直接忽略全部错误，例如#slave-skip-errors=allslave-skip-errors=1032,1053,10623、将大多数小表正常备份导出，在slave服务器上导入恢复。在这里，正常导出即可，无需特别指定 --master-data 选项4、逐一导出备份剩下的几个大表。在备份大表时，还可以分批次并发导出，方便并发导入，使用mysqldump的-w参数，然后在slave上导入恢复（可以打开后面的参考文章链接）5、全部导入完成后，等待复制没有延迟了，关闭忽略错误选项，重启，正式对外提供服务上述几个步骤完成后，可能还有个别不一致的数据，不过会在后期逐渐被覆盖掉，或者被当做过期历史数据删除掉。
本案例的步骤并不适用于全部场景，主要适用于：
不要求数据高一致性，且数据量相对较大，尤其是单表较大的情况，就像本次的zabbix数据一样。
参考文章：
迁移zabbix数据库到tokudb
[mysql faq]系列— mysqldump加-w参数备份
本条目发布于2014/07/06。属于数据库分类，被贴了 mysql replication、mysqldump、tokudb、zabbix 标签。作者是yejr。 [mysql faq]系列 — mysqldump加-w参数备份