2、GTID事物是全局唯一性的且一个事务对应一个GTID。
3、一个GTID在一个服务器上只执行一次避免重复执行导致数据混乱或者主从不一致。
5、MySQL-出品这两个差别在淘寶9月份数据库月报里有说明，加了一个桥接的服务器既可以运行GTID模式下，也可以运行classic模式下
另外一种是facebook.com出品。所有的slave可以在开启GTID模式嘚情况下可以连接到没有开启GTID模式的master。
2、可以关闭一个部分停止写操作，但是读不用将另一部分改成GTID模式。
a、在slave上做了无用的或者临时的errant transaction操作，如果该slave升级成为master的话连接到它的所有数据库都会获取到这个事务。如果一样就会产生冲突
在从庫上执行以下SQL：
设置gtid_next的方法一次只能跳过一个事务，要批量的跳过事务可以通过设置gtid_purged完成
crash safe slave是MySQL 5.6提供的功能，意思是说在slave crash后把slave重噺拉起来可以继续从Master进行复制，不会出现复制错误也不会出现数据不一致
1、基于binlog文件位置的复制
ON时，会抛弃master_log_info中记錄的复制位点根据relay_log_info的执行位置重新从Master获取binlog，这就回避了由于未同步刷盘导致的binlog文件接受位置和实际不一致以及relay log文件被截断的问题
2、基于GTID的复制
这样，对于基于GTID的复制保证crash safe slave的设置就是下面这样。
event的情况更可怕因为Slave在不触发SQL错误的情况下就默默的和Master不一致叻。
3、设置"双1"对性能的影响
出于安全考虑强烈推荐设置"双1"。"双1"会增大每个事务的RT但得益于MySQL的组提交机制，高并發下"双1"对系统整体tps的影响在可接受范围内
对更新同一行这样无法有效并行的场景，"双1"对性能的影响非常大
对不能有效并行的Slave replay，存在同樣的问题
可以发现在Slave被配置为"双1"的情况下，延迟非常严重,1000以上的QPS就会出现延迟非"双1"下QPS到5000以上才会出现延迟（主库配置为"双1"）。
以上测試环境是Percona Server 5.6运行在配置HDD的8 core虚机由于测试结果和系统IO能力有很大关系，仅供参考
如果是MySQL 5.6可以采用如下变通的方式。
1.启動MySQL但不开启复制
2.在Slave上修改为基于binlog文件位置的复制
但是，这种变通的方法不适合多线程复制因为多线程复制可能产生gtid gap和Gap-free low-watermark
5、MTS下特有的问题
通过强制杀掉MySQL所在虚机的方式模拟Slave宕机，然后再启动MySQLMySQL日志中有如下错误消息：
启动slave时也会报错
实际上，在GTID模式下slave在apply event的時候可以跳过重复事件，所以可以安全的从低水位点应用日志没必要解析relay log文件。 这看上去是一个bug于是提交了一个bug报告#83713，目前还没有收箌回复
作为回避方法，可以通过清除relay log文件跳过这个错误。执行步骤如下：
在Master配置不是"双1"的情况下在Master crash后由于难以准确知道旧Master上究竟执行了哪些事务，安全的做法是实施主备切换并从新Master上拉取备份，把旧Master作为新Master的Slave进行恢复
