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

Posted 2021-12-07

详解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，将不冲突的事务并发执行即可。对于库级并发而言，协调线程要保证执行同一个库的事务放在一个工作线程串行执行；对于表级并发而言，协调线程要保证同一个表的事务串行执行；对于事务级而言，则是保证操作同一行的事务串行执行。

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