对于使用主从复制的mysql用户来说，经常会遇到的问题是，当主库的写压力增大时，基于单线程复制的从库跟不上主库的写速度，造成应用从从库读到脏数据。如果在数据库前面使用了cache，那么这种脏数据的影响就更恶劣。更糟糕的是，如果在主库上执行了耗时很长的sql，那么从库就会被完全阻塞，这也限制了程序员们不要在主库执行耗时长的语句，更不要提那些alter schema的语句。对于mysql主从的这个缺陷，可以使用一些其他方式规避它，比如做sharding处理，控制每个master的写压力在合适的范围内，也可以去主从，通过应用来分发请求到各个db(应用相当于主库)，但这些做法相比复制无疑会复杂的多。

　　我很早就有的一个想法是，为什么不做一个mysql的多线程复制(并行复制)，使得从库的写速度能跟上主库，而是一直使用这种低效的单线程复制?那时我没有从mysql官方看到这方面的消息。最近，看到Baron Schwartz的MySQL Limitations Part 1: Single-Threaded Replication，值得分享和讨论一下这个问题。

　　Baron Schwartz在文章中提到了多线程复制的3种思路，列举如下:

　　1)每个数据库一个线程。这样做的前提是各个数据库之间是独立的，主库不需要做什么修改，从库上对每个数据库起一个线程执行复制过来的binary log。这种方式的优点在于，基于现有的复制机制修改起来较为简单，缺点就是它不具有通用性。但我想，大多数应用的事务都不是跨数据库的，另一方面，是否可以做成，通过配置，配置哪些独立的数据库可以起独立线程，而关联的数据库还是使用原来的复制方式?

　　2)在从库上由一个协调线程(coordinator)负责分发任务给worker线程池。协调线程读relay log到一个事务段(而不是一个语句)，将整个事务交由某个工作线程执行，工作线程执行到COMMIT，但不是真正的commit，然后回报给协调线程。协调线程将确保所有的事务以相同的顺序开始和提交。如果出现死锁或者锁等待超时等错误，协调线程要使工作线程回滚，并且重试或者串行化执行有问题的事务。相比于1)，该方法具有通用性，缺点是实现起来会更复杂，并且当出现死锁等问题时，是否能正确的处理好也是个问题。

　　3)主库上有多个binlog，每个数据库一个，这样从库的复制单位就是单个数据库的binlog。这也使得，从库可以从多个主库复制，这对于一些场景会很有用。该方法的缺点是，对现有的复制机制改动很大，包括现有的复制配置、管理命令等都需要做很大的改变。

　　说完上面的实现思路，接下来的问题就是，mysql是否会做多线程复制(且不说它使用哪种方式)?在MySQL Limitations Part 1: Single-Threaded Replication的评论中，有人给出了这个http://forge.mysql.com/wiki/ReplicationFeatures/ParallelSlave链接，就是说mysql从5.1开始做这个事情，只是没想到其如此低调，连Baron Schwartz似乎都不知晓。在http://forge.mysql.com/worklog/task.php?id=4648可以看到mysql对多线程复制的一些思路，它是基于5.1的行复制(估计现在多数应用还是基于语句复制)，实现思路似乎和上面的2)有些相像。不知道以mysql的办事效率，该功能何年何月才能成熟起来。

微信公众号

TechTarget

官方微博

TechTarget中国