[转载]开源MySQL多线程逻辑导出工具mydumper原理

mydumper（&myloader）是用于对MySQL数据库进行多线程备份和恢复的开源 (GNU GPLv3)工具。开发人员主要来自MySQL、Facebook和SkySQL公司，目前由Percona公司开发和维护，是Percona Remote DBA项目的重要组成部分，包含在Percona XtraDB Cluster中。mydumper的第一版0.1发布于2010.3.26，最新版本0.9.1发布于2015.11.06。

补充：目前项目已经迁移到github上了

导入导出测试

下图是在SSD和HDD存储介质上将mydumper和同为逻辑备份的MySQL官方mysqldump所做的性能对比测试，测试对象为网易博客库：

可以发现，在备份时间上，mydumper性能比mysqldump好将近1倍，通过分析不难发现，两者性能的差距主要跟备份实例的IO性能以及mydumper开启的线程数有关系，如果外部实例的IO性能很差，那么可能mysqldump单线程就能够将IO吃满，那改为使用mydumper也无法带来性能提升，但如果实例的IO性能较好，通过增加备份线程数（测试所用为2线程），就可能带来成倍的性能提升。导入时间分别使用与mydumper配合使用的myloader多线程sql导入工具以及mysqldump对应的source命令得到。相应的，在IO性能较好的SSD上，myloader的多线程优势体现明显，比source的单线程执行时间上节省将近2倍（测试所用为4线程）。不过在HDD上，由于其本身性能原因，myloader带来的效益变小。

多线程导出原理分析

mydumper是一种比MySQL官方mysqldump更优秀的备份工具，主要体现在多线程和备份文件保存方式上。在MySQL 5.7版本中，官方发布了一种新的备份工具mysqlpump，也是多线程的，其实现方式给人耳目一新的感觉，但遗憾的是其仍为表级别的并行。而mydumper能够实现记录级别的并行备份，其备份框架由主线程和多个工作线程组成，备份流程可见下图：

主线程负责建立数据一致性备份点、初始化工作线程和为工作线程推送备份任务：

• 对备份实例加读锁，阻塞写操作以建立一致性数据备份快照点，记录备份点BinLog信息；

• 创建工作线程，初始化备份任务队列，并向队列中推送数据库元数据（schema）、非InnoDB表和InnoDB表的备份任务；

工作线程负责将备份任务队列中的任务按顺序取出并完成备份：

• 分别建立与备份实例连接，将session的事务级别设置为repeatable-read，用于实现可重复读；

• 在主线程仍持有全局读锁时开启事务进行快照读，这样保证了读到的一致性数据与主线程相同，实现了备份数据的一致性；

• 按序从备份任务队列中取出备份任务，工作线程先进行MyISAM等非InnoDB表备份，再完成InnoDB表备份；这样可以在完成非InnoDB表备份通知后主线程释放读锁，尽可能减小对备份实例业务的影响；

mydumper的记录级备份由主线程负责任务拆分，由多个工作线程完成。主线程通过将表数据拆分为多个chunk，每个chunk作为一个备份任务。表数据拆分方式如下所述：mydumper优先选择主键索引的第一列作为chunk划分字段，若不存在主键索引，则选择第一个唯一索引作为划分依据，若还不存在，则选择区分度（Cardinality）最高的任意索引。如果还是无法满足，则只能进行表级的并行备份。在确定了chunk划分字段后，先获取该字段的最大和最小值，再通过执行“explain select field from db.table”来估计该表的记录数，最后根据所设的每个任务（文件）记录数来将该表划分为多个chunk。如下图所示：

以上描述可知，mydumper并不能保证记录级备份时，每个备份任务中的记录数是相同的。另外，目前记录级备份存在一个bug：所用索引字段为负数时主线程会进入死循环无法退出，导致备份失败。https://bugs.launchpad.net/mydumper/+bug/1418355

与mysqldump另一个不同是， mydumper为每个备份任务建立至少一个备份文件。在0.9.1版本中，文件类型包括schema-create、schema、schema-post文件等表元数据文件分别用保存建数据库语句、建表语句（包括触发器）、函数/存储过程/事件定义语句等；数据文件可以根据用户设置为固定大小或固定记录数的文件。这样便以进行更细粒度的数据恢复和数据删除，比如可以在myloader的时候仅选择某几个数据库/表进行恢复。