MySQL有很多种复制，至少从概念上来看，传统的主从复制，半同步复制，GTID复制，多线程复制，以及组复制（MGR）。
咋一看起来很多，各种各样的复制，其实从原理上看，各种复制的原理并无太大的异同。
每一种复制的出现都是有其原因的，是解决（或者说是弥补）前一种的复制方案的潜在的问题的。
新的复制方式的出现，是基于对原复制某一方面增强或者是优化的结果，而不是全新的一种方案或者技术，所以就不难理解为什么有这么多中复制。
其实搞出来这么多概念，个人觉得是源于开源的原因吧，不同复制版本的出现，因为是一个不断发现问题就解决问题的过程。
如果是闭源的数据库，你只管打补丁就行了，SP1,SP2,SP3……，应该不会出现这么多概念上的东西。
本文仅从原理上粗略总结各种复制技术的特点以及解决的问题，不涉及太多的细节问题。
MySQL复制的原理图（图片来源于深入浅出MySQL）
大致的流程如下：
1，搭建完主从之后，slave连接至master，slave的io_thread等待主库的binlog信息
2，master上执行各种DDL或者DML命令，执行完成执行生成binlog
3，master上的binlog_dump线程将生成的binlog传送给slave的slave的io_thread
4，slave的io_thread接受到master上的binlog之后将binlog写入本地的中继日志文件
5，slave本地的sql_thread应用中继日志到本地数据库中
传统的主从复制
对于传统的主从复制,Slave连接至master的典型操作如下，就是手工指定slave要从master的哪个文件的哪个点开始执行其二进制日志。
CHANGE MASTER TO
MASTER_HOST='***.***.***.***',
MASTER_USER='username',
MASTER_PASSWORD='pwd',
MASTER_PORT = 3306,
MASTER_LOG_FILE='mysql-bin.000047',
MASTER_LOG_POS=3112;
潜在的问题：
1，数据异步复制，master提交事物并不需要与slave确认，binlog以异步的方式传送到slave，很明显，潜在的问题就是如果master宕机，可能存在没有传递到slave的binlog，造成事物的丢失。
2，需要手工确认logfile以及logfile的偏移量
半同步复制
半同步复制最大的特点就是改进了传统的主从复制潜在的主从不一致的问题，
半同步复制要求master提交事务之后，等到至少一台slave接收到binlog并且成功写入到中继日志中才算返回给客户端成功提交的消息。
这样就确保了master上所有的事物，都可以传递至至少一个slave，master宕机的情况下并不会丢失事物，解决了传统复制潜在的问题1 ，但是问题2依旧。
潜在的问题：
1，依旧需要手工确认logfile以及logfile的偏移量
GTID复制
GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。
这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。
正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。
典型的GTIDslave启动脚本如下
change master to
master_user='username',
master_password='pwd'
MASTER_AUTO_POSITION = 1;
相对于传统的主从复制，或者是提高了安全性的半同步复制，在搭建主从，或者是改变主从的时候，
操作方式都是需要手动指定binlog的文件以及文件的偏移量，说白了就是人为地去判断slave应该从从master的哪个binlog中的哪个位置开始重放二进制日志中的内容。
这样势必会增加手动操作以及人为判断错误的可能性，不是太方便做主从或者故障转移操作。
相对传统的复制，GTID的优势：
1、更简单的搭建主从复制，以及实现故障转移，不用以前那样在需要手工指定log_file和log_pos。
2，正常情况下，GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过，跳过错误的事物更加方便。
多线程复制
半同步复制解决了传统复制潜在的slave丢失master事物的问题，GTID复制简化复制的实现，解决了传统复制过于复杂的的问题，算是原始复制的两个补丁。
从安全性和复杂程度两个纬度改进了传统复制，但是传统复制依然潜在一个致命的问题，就是主从复制的延迟。
slave上的sql_thread应用中继日志到本地数据库中，是一个单线程的操作，这样面对大量的binlog，就可能存在效率上的问题，
多线程复制就是通过并行解析中继日志的方式，提要slave上sql_thread的执行效率，从而改善主从复制延迟的问题（当然也需要master的binlog做一定的优化）
MGR（MySQL Group Replication）