码迷,mamicode.com
首页 > 数据库 > 详细

详解mysql复制机制--异步复制,半同步复制和并行复制

时间:2019-05-26 18:06:08      阅读:248      评论:0      收藏:0      [点我收藏+]

标签:分发   导致   star   性能   nod   重要   red   接受   概念   

详解MySQL复制机制--异步复制,半同步复制和并行复制

**# 异步复制

异步复制是MySQL自带的最原始的复制方式,主库和备库成功建立复制关系后,在备库上会有一个IO线程去主库拉取binlog,并将binlogx到本地,就是下图中Relaylog,然后备库会开启另外一个SQL线程取回放Relay log,通过这种方式达到Master-Slave数据同步的目的。

通常情况下,slave是只读的,可以承担一部分读流量,而且可以根据实际需要,添加一个或者多个slave,这样在一定程度上可以缓解主库的读压力;

    另一方面,若Master出现异常(crash,硬件故障等),无法对外提供服务,此时Slave可以承担起master的重任,避免了单点的产生,所以复制就是为容灾和提高性能而生。

**  半同步复制**
**1.概念**
一般情况下,异步复制就已经足够应付了,但由于是异步复制,备库极有可能是落后于主库,特别是极端情况下,我们无法保证主备数据是严格一致的(即使我们观察到Seconds  Behind  Master这个值为0)

比如,当用户发起commit命令时,Master并不关心slave的执行状态,执行成功后,立即返回给用户。试想下,若一个事务提交后,master成功返回给用户后crash,这个事务的binlog还没来得及传递到slave,那么slave相对于master而言就少了一个事务,此时主备就不一致了。对于要求强一致的业务是不可以接受的,半同步复制就是为了解决数据一致性而产生的。

为什么叫半同步复制?我们来先说说同步复制,所谓同步复制就是一个事务在master和slave都执行后,才返回给用户执行成功。这里核心是说master和slave要么都执行,要么都不执行,涉及到2pc(2  phrase  commit)。而MySQL只实现了本地redo-log和binlog的2PC,但并没有实现master和slave的2PC,所以不是严格意义上的同步复制。而MySQL半同步复制不要求slave执行,而仅仅是接收到日志后,就通知master可以返回了。

  这里关键点是slave 接受日志后是否执行,若执行后才通知master则是同步复制,若仅仅是接受日志成功,则是半同步复制。

     半同步复制如何实现?半同步复制实现的关键点是master对于事务提交过程特殊处理。目前实现半同步复制主要是有两种模式,AFTER_SYNC模式和AFER_COMMIT模式。两种方式的主要区别在与是否在存储引擎提交后等待slave的ACK.

     2、AFTER_COMMIT模式
           先来看看AFTER_COMMIT模式,start和End分别表示用户发起commit命令和master返回给用户的时间点,中间部分就是整个commit过程master和slave做的事情。

                 master提交时,会首先将该事务的redo  log刷入磁盘(这里其实还涉及到两阶段提交的问题),然后进入Inodb  commit过程,这个步骤主要是释放锁,标记事务为提交状态(其他用户可以看到该事务的更新),这个过程完成后,等待slave发送ack消息,等到slave的响应后,master才成功返回给用户,master和slave的同步逻辑,是master-slave一致性的保证。

        3、AFTER_SYNC模式
        与AFTER_COMMIT相比,Master在AFTER_SYNC模式下,fsync  binlog后,就开始等待slave同步,那么在进行第5步innodbcommit后,即其他事务能看到该事务的更新时,slave已经成功接收到binlog,即使发生切换,slave拥有与master同样的数据,不会发生“幻读”现象。但是对于上面描述的第一种情况,结果是一样的。

        所以,在极端情况下,半同步复制的master-slave会有一个事务不一致,但是对于用户而言,由于这个事务并没有成功返回给用户,所以无论事务提交与否都是可以接受的,用户有必要进行查询或重试,判读是否更新成功。或者我们想想,对于单机而言,若事务执行成功后,返回给用户时,网络断了,用户也是面临一样的问题,所以,这不是半同步复制的问题,对于提交返回成功的事务,半同步复制保证master-slave一定是一致的,从这个角度来看,半同步复制不会丢数据,可以保证master-slave的强制性。

并行复制
半同步复制解决了Master-slave 强一致问题,那么性能问题呢?参与复制的两个线程:IO线程和SQL线程,分别用于拉取和回放binlog。对于slave而言,所有拉取和解析binlog的动作都是串行的,相对与master并发处理用户请求,在高负载下,若master产生binlog的速度超过slave消费binlog的速度,导致slave出现延迟,可以看到,users和master之间的管道远远大于master和salve之间的管道。

 那么如何并行化,并行io线程,还是并行sql线程?其实两方面都可以并行,但是并行sql线程的收益更大,因为sql线程做的事情更多(解析,执行)。并行IO线程,可以将从master拉取和写入relay  log分为两个线程;并行sql线程则可以根据需要做到库级并行,表级并行,事务级并行。库级并行在MySQL官方版本5.6已经实现了。并行复制框架实际包含了一个协调线程和若干个工作线程。协调线程负责分发和解决冲突,工作线程只负责执行。

 DB1,DB2和DB3的事务 就可以并发执行,提高了复制的性能。有时候库级并发可能不够,需要做表级并发,或更细粒的事务级并发。

 **并行复制如何处理冲突?**
   并发的世界是美好的,但不能乱并发,否则数据就乱了。master上面通过锁机制来保证并发的事务有序进行,那么并行复制呢?slave必需保证回放的顺序与master上事务执行顺序一致,因此只要做到顺序读取binlog,将不冲突的事务并发执行即可。对于库级并发而言,协调线程要保证执行同一个库的事务放在一个工作线程串行执行;对于表级并发而言,协调线程要保证同一个表的事务串行执行;对于事务级而言,则是保证操作同一行的事务串行执行。

     **是否粒度越细,性能越好?**
       这个并不是一定的。相对与串行复制而言,并行复制多了一个协调线程。协调线程一个重要作用是解决冲突,粒度越细的并发,可能会有更多的冲突,最终可能也是串行执行的,但消耗了 大量的冲突检测代价。

详解mysql复制机制--异步复制,半同步复制和并行复制

标签:分发   导致   star   性能   nod   重要   red   接受   概念   

原文地址:https://blog.51cto.com/14354846/2400323

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!