通过GTIDs【global transaction identifiers】,可以标识每一个事务，并且可以在其一旦提交追踪并应用于任何一个Slave上；这样 就不需要像BinaryLog复制依赖Log file 和位置。GTIDs完全基于事务，只要在Master提交的所有事务都在Slave上进行了Commit，那么就能保证Master和Slave之间的数据 一致性。你可以使用基于SBR或RBR的GTIDs来实现。推荐使用RBR【Row-based replication】.
1 GTID介绍
GTID的惟一性，不仅仅在Master上惟一，而是在整个集群中惟一。
GTID是由SourceId：transaction_Id 构成;SourceId用于标识源Server，即Master中的server_uuid[系统变量];transaction_id，是按照事务提交顺序而生成的序列数字。如第一个被提交的是1，则其GTID=XXXXXXXXXXXX:1.
GTID被存储于mysql.gtid_executed中，当gtid_mode=ON/ON_PERMISSIVE时。
GTID的生命周期
a.事务在Master上执行并提交
该事务用GTID标识，GTID由Master的UUID和一个非0的未被使用的事务序列号构成；该GTID被写入Master的BinLog中。
b.之后BinLog被传送到Slave上并存储在Slave的relay Log中【using established mechanisms for this process】.Slave读取到这个GTID，并为系统变量gtid_next赋值，这就告诉了Slave下一个要执行的事务【transaction】就是这个。
c.Slave确认该GTID是否已被使用【在其BinLog中】。若未用，则执行transaction并写入BinLog。需要注意的是：不仅仅是检查BinLog而且要确认没有其他session 已读取但未提交。换句话说，多个Clients不允许并行执行同一事务。
d.由于gtid_next不为空。Slave执行并写入BinLog。
2.构建GTID复制
a. 同步数据。即将Master与Slave的数据同步到一致，然后都开启SET @@global.read_only=ON;
b.停止Servers。可使用：mysqladmin -uroot -p shutdown
c.配置主从Server.确保双方都开启gtid_mode=ON，enforce_gtid_consistency=ON。
d.将Slave挂载到Master，告诉Slave将使用哪个Master作为复制的数据源。使用CHANGE MASTER TO语句，一定要启用MASTER_AUTO_POSITION=1,告诉Slave事务将由GTIDS标识。
e.启动Slave. START SLAVE.
f.关闭 read_only. SET @@global.read_only = OFF.
3.使用GTIDs限制
GTIDs是基于事务的【transactions】,所以对非事务的操作不会支持。
CREATE TABLE ... SELECT statements .creat table ...select对基于语句的复制【SBR】是不安全的。
Temporary tables 。GTIDsg不支持CREATE TEMPORARY TABLE AND DROP TEMPORARY TABLE .
【Preventing execution of unsupported statements】阻止不支持语句的执行。为了防止GTID受到不支持语句的影响而失败，在参与复制的Server上都要使用enforce-gtid-consistency操作。
sql_slave_skip_counter用于跳过不支持的事务【这在GTIDs不支持】。
在gtid_mode=ON时不要进行mysql_upgrade,因为Mysql_update会用MyiSam引擎改变一些系统表。
也不要在gtid_mode=ON时进行mysqldump文件的导入。
也可参考这篇文章：
http://www.cnblogs.com/abobo/p/4242417.html