这个系列是专门调研MySQL主从同步延迟并改进，最终实现的MySQL-Transfer已经能实现线上无延迟同步。目前正在开发Transfer 2.0，进一步简化运维、提升同步性能和减少当前版本的限制，如支持事务、单表并发等。

MySQL-Transefer（下称Transfer）是一个基于MySQL+patch后得到的主从同步工具。 其主要目的是为了解决原生版本的主从同步里，从库是单线程apply主库的binlog，导致的延迟。 最近完成测试的版本将multi-master合并到Transfer中并针对支付宝的应用需求做了定制性能改进。 这里做一个已经完成的完整功能介绍。

1、Transfer可以注册成多个Master的从库

2、Transfer接收多个Master传入的binlog后将更新执行到Slave上

3、Transfer本地没有数据

如果你没有多主的需求，那结构就是Master -> Transfer -> Slave.由于Transfer是在MySQL基础上打的patch，因此支持几乎所有MySQL的监控命令，你原来加在Slave上的监控，可以直接改到Transfer上。

一般我们将Transfer和Slave放在同一个机器上（等于是装两个MySQL，一个是Transfer，一个是真正的slave） 

1、作为这个关键的转发工具transfer，需要提供如下功能：

1、能够指定同步master中的哪部分数据，并且能够方便地修改这个配置以应对master的加表需求；

2、支持stop slave、start slave。支持快速切换到新主库的change master命令。

3、能够记录读取点，transfer自己重启或master重启后能够按照记录点继续读后面的binlog；

4、能够记录分发点，transfer自己重启或slave重启后能够按照记录点继续同步给slave

Transfer的这么多功能，自己造轮子就累了。这里直接用MySQL来充当此角色。Transfer更新slave在功能上可以使用federated引擎，但由于其纠结的实现导致性能上达不到要求，因此在MySQL框架层中作了一点修改――读到同步日志后，直接发送给slave。

功能比较齐全。直接使用MySQL，原有的管理功能基本都能用，主库从库重启/换库的代价比较小。

1、为什么不直接把transfer当slave用？

实际上是可以的，作了简单实验发现与“改进方案”的从库QPS相同，好处是减少了一层transfer的逻辑。一般来说这种

工具也不会放到和slave一个机器，直接用作slave就少了一个机器。 不过直接改slave的代码还是推广比较麻烦。而且不

得不承认的是，这个方案存在一个硬伤：跨表更新的语句顺序无法严格保证。――这也是这两个方案的应用前提：没有跨

表语句或者对这种出现的情况要求不严格。

2、为什么不直接写一个工具而用MySQL？

其实作transfer的MySQL并不像想象的那么庞大。不需要的引擎可以都不编译进去，其实只需要框架层的逻辑和一个myisa

m引擎即可。而它提供了很多管理命令，比如一个现成的客户端，能够方便的stop slave、change master，能够用show

slave status看同步状态。这些作为这个工具的基本功能，自己一个个实现重复轮子太多了。

这次单独调查一下主从延迟的时间。这里说的主从延迟，并不是指“从库更新

性能跟不上主库”， 而是“一个命令从主库更新完成到从库更新完成的延迟

时间。 对于每一个连上来的从库，主库都有一个client线程与之对应。 先看

主从的基本数据流

1、客户端SQL更新命令

2、主库执行

3、主库写binlog

4、主库client线程读binlog发送给从库的io线程

5、从库io线程写盘（relay-log）

6、从库sql线程读relay-log

7、执行更新。