比较MySQL主从复制中基于GTID复制和基于日志点的复制

基于日志点的复制是MySQL支持的第一种主从复制方式，也是最传统的复制方式。

这种复制方式在MySQL历史发行版、percona MySQL以及MariaDB中都是通用的。

在基于日志点的复制情况下，主可以是MySQL发行版，从可以是percona MySQL或MariaDB，这都是可行的。

slave请求master的增量日志依赖于日志偏移量，也就是二进制文件名和已经同步过的偏移量。

使用change master to 命令时，配置链路时，需要指定master_log_file和master_log_pos参数。

GTID（Global Transaction ID），全局事务ID。

从MySQL 5.6.5 版本开始新增了一种基于 GTID的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

GTID由两部分组成，source_id:transaction_id，其中source_id是执行事务的MySQL实例ID，而transaction_id是该集群中所执行过的每个事务所具有的的唯一标识，并且transaction_id是随着事务的不断执行递增的。

（1）通过source_id来标识事务是在MySQL集群中哪台MySQL实例执行处理提交的。

（2）方便进行MySQL集群故障转移

当master挂掉后，我们只要从当前集群中选出哪个slave同步的事务最多（transaction_id最大），就将其选择为新的master，并使其他slave对新的master进行数据同步即可。

相比于基于日志点的复制，基于GTID的复制方式在进行故障转移上要方便很多。

（3）slave增量同步master的数据依赖于其已经同步的事务ID，master通过事务ID可以知道哪些事务还没有同步到slave上。

（4）相比于基于日志点复制，在基于GTID复制中，我们配置复制链路时，并不需要指定master_log_file和master_log_pos，只要指定master_auto_position参数即可

	基于日志点的复制	基于GTID的复制
易兼容性	MySQL新老版本、percona MySQL、MariaDB	MySQL新版本、percona MySQL
支持的架构	MMM架构、MHA架构	MHA架构
故障转移的难易程度	主备切换后很难找到新的同步点	可以很方便的找到已完成同步的事务ID
易维护性	可以方便的跳过复制错误	只能通过置入空事务的方式跳过错误

说明：

在支持的架构一点上，由于MMM架构已经缺乏必要的维护了，MMM架构并没有对最新的GTID复制进行支持。

在故障转移的难易程度一点上，基于日志点的复制方式，每一个实例的二进制文件名都不同，所以一旦master宕机，就很难找到新老master二进制文件及偏移量的对应关系，因此在基于日志点的复制方式中，主备切换后很难找到新的同步点。而与其对比，基于GTID复制的方式则很容易就找到新老master的同步点。

在易维护性一点上，基于日志点的复制只要设置 sql_slave_skip_counter 即可。

根据使用场景：

需要兼容老版本MySQL及MariaDB，选择基于日志点的复制

需要MMM架构来做MySQL高可用架构管理，选择基于日志点的复制

其他各种情况，可以优先选择基于GTID的复制方式