日期:2014-05-16  浏览次数:20745 次

mysql主从同步延迟方案解决的学习心得

无意中看到2012华东架构师大会主页(http://atcc.mysqlops.com/#video_show),PS:现在架构师大会好多!

在里面看了mysql异步延迟解决方案的PPT,对于提出的解决方案有些共鸣,分享下

mysql 主从同步的目的应该有很多,有的是为了备份,有的是为了读写分离,看具体需求。
但主从机制是一样的:
mysql主从的实现是,mysql master被使用后,其中master后台IO线程会写Binlog;slave有一个Relay Log线程同步binlog日志,同时有另一个Extractor线程会读取相应的Binlog,在Slave进行相应的同样的操作。
对于主从正常执行,相应的延迟几乎是不存在的。但是在高QPS下,主从同步却出现了比较明显的延迟情况。在PPT介绍中,当master QPS达到1万左右时,Slave重做的QPS却只有2000左右,因此所谓的瓶颈其实是在Binlog日志在slave重做这块。而此处实现是单线程的,因此改进的方法此处用多线程实现。

PPT中介绍淘宝实现,修改了源码,对应的机制是Transfer机制:此处通过对Binlog日志重做采用多线程实现,从而提高slave的QPPS,PPT给出的实验数据按此机制实现后,QPS能达到1万多。从而解决mysql主从之间高QPS下的数据同步问题。
当然使用此机制对应的mysql相关配制也有一定的要求:
1.Binlog日志格式必须是基于ROW级别的,
2.对应的SQL语句必须对应PK或者uni key。

对于以上两点,作者解析是基于多线程必须是知道PK或者uni key才能完成相应的多线程重做slave,这样才能保证SQL语句的执行顺序。相对来说,对于第二点很多应用需求还是能满足。但是对ROW日志格式,对于一些批量修改等应用,采用此日志格式所带来的DB的IO压力等应该也是需要考虑的。

毕竟一种新的方案的提出有它的优点也有它的缺点,合适才是最合理的。总的来说此PPT是围绕此方案的实现在讲解,很易懂。

有需要了解的可以去上面网址下载PPT学习!