当前位置: 首页 > mysql, 数据库 > 正文

mysql的多线程复制

关键字:
1 星2 星3 星4 星5 星 (2 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

对于使用主从复制的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。这也使得,从库可以从多个主库复制,这对于一些场景会很有用。该方法的缺点是,对现有的复制机制改动很大,包括现有的复制配置、管理命令等都需要做很大的改变。

本文固定链接: http://www.chepoo.com/mysql-thread-replication.html | IT技术精华网

mysql的多线程复制:等您坐沙发呢!

发表评论