三种MySQL并行复制方案的分析.doc

三种MySQL并行复制方案的分析
MySQL的复制框架下主要由3个过程组成，分别是：Master端的binlog发送，Slave端的binlog接收以及relay log的执行。很久以来这3个过程都是单线程执行，造成的结果是slave端的数据经常严重滞后于master端。
影响slave端的数据同步速度有两个因素：一是binlog从Master到slave的发送速度，二是slave的relay log的执行速度。前者主要由网络传输速度决定，然而在内网直连的环境下这不会成为性能瓶颈。所以，slave端的relay log的回放速度成为了影响slave与master数据同步的主要因素。
经常可以遇到的一种情况是，slave端数据虽然严重滞后，但是slave端的操作系统的资源利用率却无法提升。造成这种现象的原因是，slave上的relay log的回放是单各sql线程执行。
目前，加快slave上的relay log的回放过程速度有若干种解决方案。由innosql团队完成的sql线程批量提交事务的方案，测试结果显示性能提高显著（/）。但是还是受限于sql单线程执行的制约，性能提高存在一个上限。
所以使用多个sql线程在slave端执行relay log成为了提高slave数据同步速度的重要途径。但是，sql线程在回放过程中必须满足两个条件：一，relay log文件中的一个event在slave上必须且只能执行一次；二，sql线程对同一份数据的修改顺序必须和master端的修改顺序相同。只有实现了这两点，才能保证slave上回放出来的数据和master是一致的。单个sql线程回放时，这两点是自然成立的。但是多个sql线程并行回放却有一定的困难。
目前，多sql线程并行复制有多种解决方案。。该方案在slave端给每一个库建立一个sql线程，一个sql线程只回放一个库的修改操作，对于relay log中不是sql线程负责的库上的操作直接跳过执行。该方案满足前面提到的回放过程的两个要求，可以保证主从数据的一致。但是，该方案的缺点也很明显，因为对于目前的应用，大部分的数据都是放在一个库中。使用该并行复制方