MySQL的复制演进之路(起始篇)
MySQL复制含有以下优点:
当主库出现问题时，可以快速切换，从库提升为主库继续提供服务。
可以实现读写分离，降低主库的访问压力。
在从库上执行备份，避免对主库造成影响。
可以实现在线升级，先升级备库，再升级主库。
目前MySQL支持两种数据同步方法，传统复制和基于GTID的复制。
传统复制:基于二进制日志文件和位置进行复制，在进行主从配置复制时，需要指定从主库获取的二进制文件(binlog file) 和位置点(binlog position)。
基于GTID的复制:GTID,全称Global Transaction ID，从MySQL5.6及以后开始支持，利用GTID可以自动在主库中寻找需要复制的二进制日志记录，不需要关心日志文件或位置，简化了复制的配置。
MySQL通过三个线程完成主从复制，即Binlog Dump线程，I/O线程，SQL线程，其中Binlog Dump在主库上，I/O线程和SQL线程在从库上，当进行主从复制时，MySQL主库在事务提交时将数据变更作为事件Events记录到binlog二进制日志中，然后主库创建Binlog Dump线程读取事件发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志Relay Log中,然后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件进行回放，如果开启了并行复制，则SQL线程转变成coordinator(协调者),进行数据复制，从而实现数据一致。
流程如下:
MySQL支持以下几种不同类型的数据同步:
异步复制:最早的复制技术，MySQL内置支持，不需要安装插件，MySQL主库执行完更新操作后立即commit,然后向slave同步数据，性能最高，但是数据不是实时同步到从库，当主库在从库有延迟时发生故障时可能会导致主从数据不一致。
半同步复制(after commit):主库执行完更新操作后立即向从库复制数据，至少一个从库接收到数据后写入到Relay Log中，此时从库向主库返回ACK确认信息，然后才会进行commit，但是早期的半同步复制中，主库在等待ACK的InnoDB存储引擎内部已经进行commit操作，只是阻塞了返回给发起事务提交的客户端消息而已，如果有其他会话对该事务修改的数据进行查询，会查询到最新数据，当主库发生故障时，可能会发生幻读。
增强半同步复制(after sync):主库执行完更新操作后立即向从库复制数据，至少一个从库接收到数据后写入到Relay Log中，此时从库向主库返回ACK确认信息，然后才会进行commit。这是对半同步复制漏洞的修复。
延迟复制:可以通过设置使得从库故意滞后于主库一段指定的时间，以便出现误操作时能进行补救。
强同步复制:保证写操作完全同步到其他数据节点，主库在执行完更新操作后立即向从库复制数据，从库接收到数据并执行完后才向主库放回ACK信息，然后主库才进行commit操作。
演进过程大致如下:
好了，今天就到这吧，MySQL的复制进程经历了一系列的演进之路，从最开始的异步复制到后面的半同步复制，再到后面的增强半同步，以及后来的MGR，在追求卓越的道路上从未放弃。想想，你是不是也是这样呢，在学习之路上始终坚持呢，让我们一起加油。MySQL的复制知识点很多很杂，期待未来与你一起学习探讨。