MySQL的多线程复制

日期: 2010-10-24 作者:佚名 来源:TechTarget中国

  对于使用主从复制的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微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者

佚名
佚名

相关推荐