Detailed MySQL replication - asynchronous replication, semi-synchronous replication and parallel replication
** # asynchronous replication
Asynchronous replication is MySQL comes with the most primitive means of copying, the main library and library equipment after a successful replication relationship is established, there will be a standby database on the IO thread to the main Kula take binlog, and binlogx locally, is the next figure Relaylog, and then opens another library prepared SQL thread take playback Relay log, in this way to achieve the purpose of the Master-Slave synchronization data.
通常情况下，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的强制性。Parallel copy
semi-synchronous replication to solve the same problem Master-slave strong, then the performance problem? Participate in the replication of two threads: IO thread and the SQL thread, respectively, for pulling and playback binlog. For the slave, all analytical and binlog pulling movements are serial, parallel processing as opposed to master user request, at a high load, when the master generates a speed faster than the slave binlog binlog consumption, leading to delays slave, can be seen, the pipe between the master and the users is far greater than the pipe between the master and the salve.
那么如何并行化，并行io线程，还是并行sql线程？其实两方面都可以并行，但是并行sql线程的收益更大，因为sql线程做的事情更多（解析，执行）。并行IO线程，可以将从master拉取和写入relay log分为两个线程；并行sql线程则可以根据需要做到库级并行，表级并行，事务级并行。库级并行在MySQL官方版本5.6已经实现了。并行复制框架实际包含了一个协调线程和若干个工作线程。协调线程负责分发和解决冲突，工作线程只负责执行。
DB1,DB2和DB3的事务 就可以并发执行，提高了复制的性能。有时候库级并发可能不够，需要做表级并发，或更细粒的事务级并发。
**并行复制如何处理冲突？**
并发的世界是美好的，但不能乱并发，否则数据就乱了。master上面通过锁机制来保证并发的事务有序进行，那么并行复制呢？slave必需保证回放的顺序与master上事务执行顺序一致，因此只要做到顺序读取binlog，将不冲突的事务并发执行即可。对于库级并发而言，协调线程要保证执行同一个库的事务放在一个工作线程串行执行；对于表级并发而言，协调线程要保证同一个表的事务串行执行；对于事务级而言，则是保证操作同一行的事务串行执行。
**是否粒度越细，性能越好？**
这个并不是一定的。相对与串行复制而言，并行复制多了一个协调线程。协调线程一个重要作用是解决冲突，粒度越细的并发，可能会有更多的冲突，最终可能也是串行执行的，但消耗了 大量的冲突检测代价。