MySQL5.6有很多新的特性，其中很多人都感兴趣的一条就是全局事务序号功能(GTIDs)。而大家都对这一特性很感兴趣的原因也很好理解，即：本来重新连接从服务器和一个新的主服务器一直是件很麻烦的事，然而在启用GTIDs功能之后就变得简单易行。可是，GTIDs的使用
mysql5.6有很多新的特性，其中很多人都感兴趣的一条就是全局事务序号功能(gtids)。而大家都对这一特性很感兴趣的原因也很好理解，即：本来重新连接从服务器和一个新的主服务器一直是件很麻烦的事，然而在启用gtids功能之后就变得简单易行。可是，gtids的使用不单单是用单独的标识符替换旧的二进制日志文件/位置，它也采用了新的复制协议。假如你还不太明白这些，那你可以在这篇文章里学点什么。
复制协议：新的 VS 旧的
旧的协议往往简单直接即：首先从服务器上在一个特定的偏移量那里连接到一个给定的二进制日志文件，然后主服务器在从那里发送所有的事务。
新协议稍有不同：slave首先会发送它已经执行过的GTID的范围，然后master发送每一个丢失的事务. 它也确保了一个给定的GTID只可以在一个特定的slave中执行一次.
实践中，这会改变任何东西吗? 使得，它会改变很多东西. 想象一下下面的场景: 你想要从trx 4开始复制，但是trx2在slave上因为某种缘故丢失了.
使用老协议的话，trx 2再也不会被执行一次，而使用新协议，它就会被自动的再执行一次.
下面是两个你可以在实践中看到新协议的通用场景.
跳过事务
众所周知老的 SET GLOBAL sql_slave_skip_counter = N 在你想要跳过一个事务时不再提供支持，而GTID就可以被启用了. 换用 GTID XXX:N 来跳过事务, 你须得 注入一个空的事务:
mysql> SET gtid_next = 'XXX:N';
mysql> BEGIN; COMMIT;
mysql> SET gtid_next = 'AUTOMATIC';
为什么我们不能使用 sql_slave_skip_counter? 就是因为新的复制协议!
想象一下我们拥有如下图所示的三台服务器:
让我们假设 sql_slave_skip_counter 可以用并且已经被用在S2上用于跳过trx2. 如果你吧S2设置成S1的一个slave将会发生什么呢?
两个服务器会互相交换被执行了GTID的范围，并且S1将会意识到其必须将trx2发送给S2. 然后会发生的事情有两种可能:
如果 trx 2 仍然在S1的二进制日志中，它将会被发送给S2，而事务在也不会被跳过了.
如果 trx 2 不再存在于S1的二进制日志中，你将会得到一个复制错误.
很明显这不安全，这就是为什么 sql_slave_skip_counter 在使用GTID时是不能用的. 要想跳过一个事务，唯一安全的选择就是去执行一个虚拟的事务，而不是一个真实的事务.
错误的事务
如果你在一个slave上本地执行了一个事务 (在MySQL文档中被称为错误事务), 如果你被这个事务推送到新的master上时会发生什么呢?
使用老协议，，基本上没啥事(准确点说，新的master和其slave之间的数据将会出现不一致，但那在稍后就可能会被修复).
使用新协议，错误的事务将会被识别成为在每个地方都丢失了，并且将会自动在容错备份上被执行，这样就将会导致打断复制的隐患.
比方说，你拥有一个master(M)和两个slave (S1 和 S2). 这里有两种将slave重连到新的master将会发生(带有不同复制错误的)失败的场景:
# 场景 1
# S1
mysql> CREATE DATABASE mydb;
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# Thanks to 'IF NOT EXITS', replication doesn't break on S1. Now move S2 to S1:
# S2
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# This creates a conflict with existing data!
mysql> SHOW SLAVE STATUSG
[...]
Last_SQL_Errno: 1007
Last_SQL_Error: Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'CREATE DATABASE mydb'
[...]
# 场景 2
# S1
mysql> CREATE DATABASE mydb;
# Now, we'll remove this transaction from the binary logs
# S1
mysql> FLUSH LOGS;
mysql> PURGE BINARY LOGS TO 'mysql-bin.000008';
# M
mysql> CREATE DATABASE IF NOT EXISTS mydb;
# S2
mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;
# The missing transaction is no longer available in the master's binary logs!
mysql> SHOW SLAVE STATUSG
[...]
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
[...]
你可以这样理解，错误的事务应该借助基于GTID的服务得以避免. 如果你需要运行一个本地事务，最好的选择是针对那条特定的语句禁用二进制日志:
mysql> SET SQL_LOG_BIN = 0;
mysql> # Run local transaction
结论
GTIDs在让我们方便重新和其他服务器连接副本方面是个不小的进步。然而同样的在运维方面我们也因此面临新的困难和挑战。假如你打算开始使用GTIDs,那么你就得确实理解新的复制协议，否则你就会以一种想不到的方式结束复制过程。
