常日情形下，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模式和AFTER_COMMIT模式。两种办法的紧张差异在于是否在存储引擎提交后等待Slave的ACK。
2、AFTER_COMMIT模式
先来看看AFTER_COMMIT模式，Start和End分别表示用户发起Commit命令和Master返回给用户的韶光点，中间部分便是全体Commit过程Master和Slave做的事情。
Master提交时，会首先将该事务的redo log刷入磁盘，然后将事务的binlog刷入磁盘(这里实在还涉及到两阶段提交的问题)，然后进入innodb 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的强同等性。下图是AFTER_SYNC模式，事务提交过程。
并行复制
半同步复制办理了Master-Slave的强同等问题，那么性能问题呢？从图1中可以看到参与复制的紧张有两个线程：IO线程和SQL线程，分别用于拉取和回放binlog。对付Slave而言，所有拉取和解析binlog的动作都是串行的，相对付Master并发处理用户要求，在高负载下， 若Master产生binlog的速率超过Slave消费binlog的速率，导致Slave涌现延迟。如下图，可以看到，Users和Master之间的管道远远大于Master和Slave之间的管道。
图4
那么如何并行化，并行IO线程，还是并行SQL线程？实在两方面都可以并行，但是并行SQL线程的收益更大，由于SQL线程做的事情更多(解析，实行)。并行IO线程，可以将从Master拉取和写Relay log分为两个线程；并行SQL线程则可以根据须要做到库级并行，表级并行，事务级并行。库级并行在mysql官方版本5.6已经实现。如下图，并行复制框架实际包含了一个折衷线程和多少个事情线程，折衷线程卖力分发和解决冲突，事情线程只卖力实行。
图中，DB1，DB2和DB3的事务就可以并发实行，提高了复制的性能。有时候库级并发可能不足，须要做表级并发，或更细粒度的事务级并发。
图 5
并行复制如何处理冲突？
并发的天下是美好的，但不能乱并发，否则数据就乱了。Master上面通过锁机制来担保并发的事务有序进行，那么并行复制呢？Slave必需担保回放的顺序与Master上事务实行顺序同等，因此只要做到顺序读取binlog，将不冲突的事务并发实行即可。对付库级并发而言，折衷线程要担保实行同一个库的事务放在一个事情线程串行实行；对付表级并发而言，折衷线程要担保同一个表的事务串行实行；对付事务级而言，则是担保操作同一行的事务串行实行。
是否粒度越细，性能越好？
这个并不是一定的。相对付串行复制而言，并行复制多了一个折衷线程。折衷线程一个主要浸染是办理冲突，粒度越细的并发，可能会有更多的冲突，终极可能也是串行实行的，但花费了大量的冲突检测代价。
关于mysql复制方面的内容就先容到这了，建议大家有空可以自己测试一下这几种模式。后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
