MySQL GTIDs（global transaction identifiers）
1、如何定义和生成GTIDs
唯一性：在所有主从库都是唯一的，由二元组构成
每个事务和GTIDs之间都有1:1映射
GTID = source_id:transaction_id
source_id标记主库的server_uuid
transaction_id是一个递增序列，从1开始，包含5个事务的GTID
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
START SLAVE对于GTIDs的支持：
START SALVE有SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS选项
1.1 server_uuid
获取server_uuid的方式
a、判断data_dir/auto.cnf文件是否存在，如果存在返回
b、不存在的话，自动产生一个新的UUID，并保存到data_dir/auto.cnf中
auto.cnf文件格式如下：
[auto] server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562
auto.cnf文件是自动产生的，不要试图修改这个文件。
如果主库的server_uuid发生变化的话，需要重新change master to，故这个auto.cnf文件是只读的。
http://dev.mysql.com/doc/refman/5.6/en/replication-options.html#sysvar_server_uuid
1.2 GTID sets
gtid_set:
uuid_set [, uuid_set] ...
| ''
uuid_set:
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9|A-F]
interval:
n[-n]
(n >= 1)
存在多种使用：
a、gtid_executed记录已经执行过的gtid，gtid_purged记录已经执行过的并且已经从binlog中删除的
mysql> show global variables like '%gti%'; +--------------------------+------------------------------------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------------------------------------+ | enforce_gtid_consistency | ON | | gtid_executed | 5f02986b-c5de-11e3-8d21-001e4f1ef3b7:1-8, b9d59578-df02-11e3-b112-001e4f1f39cf:1-2 | | gtid_mode | ON | | gtid_owned | | | gtid_purged | 5f02986b-c5de-11e3-8d21-001e4f1ef3b7:1-8, b9d59578-df02-11e3-b112-001e4f1f39cf:1-2 | +--------------------------+------------------------------------------------------------------------------------+
b、GTID_SUBSET() 和GTID_SUBTRACT()函数
1.3 GTID产生过程
（1）事务执行完成，并在主库提交
使用主库的UUID以及最小的事务序列数，并将GTID记录到主库的binlog中
（2）当binlog的数据被从库接收后，并存储在relay log中，此时从库SQL线程读取GTID，并将其赋值给变量gitd_next
（3）从库检查GTID，确认没有执行过。如果这个GTID没有使用过，从库写入GTID，并回放这个事务。
slave需要确保两点：
a、GTID没有被之前的事务使用过
b、相关联的事务没有被提交
（4）因为gtid_next非空，slave不会尝试产生一个新GTID，而是将GTID保存在变量gtid_next中
2、如何设置基于GTIDs的同步
一主一从配置方式
先配置好主从异步复制，再次不赘述
2014-06-09 10:35:53 19208 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
配置文件中设置：
gtid-mode = ON enforce_gtid_consistency = 1 log-bin = mysql-bin log-slave-updates = 1
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html
设置同步：
mysql> CHANGE MASTER TO
> MASTER_HOST = host,
> MASTER_PORT = port,
> MASTER_USER = user,
> MASTER_PASSWORD = password,
> MASTER_AUTO_POSITION = 1;
不需要使用MASTER_LOG_FILE和MASTER_LOG_POS
如果使用上面两个参数，需要将MASTER_AUTO_POSITION设置为0
否则会出现以下错误提示：
ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active.
3、使用GTIDs进行Failover和Scaleout
基于Gtids带来的一些优势：
(1)、简单复制(Simple replication)
无需找点，会基于Gtids自行找点以及过滤相同gtid的事务，不会存在重复执行的问题
红色标注的地方是和传统的binlog不同的地方，从库上记录每个事务的gtid，这样在主从切换的时候不需要再找点，只需要比较事务id即可
(2)、将数据和事务拷贝到从库(Copying data and transactions to the slave)
数据方式：通过mysqldump方式，需要设置两个选项--master-data和--set-gtid-purged，并且从库上需要设置--git-mode=ON
事务方式：通过mysqlbinlog，通过两个选项 --read-from-remote-server和--read-from-remote-master ，使用--raw选项生成SQL文件导入
(3)、注入空事务(Injecting empty transactions)
对这个地方没太理解
(4)、通过gtid_purged过滤事务(Excluding transactions with gtid_purged)
gtid_purged记录一些已经被执行完成的gtid，并且对应的binlog已经被清理
5.6.9以前的版本没有gtid_purged这个变量
4、使用GTIDs的一些建议
1、对于基于statement和row的复制都支持，建议使用基于row格式
5、使用GTIDs的限制
5.1更新涉及到非事务存储引擎
在同一个事务中提交包含对非事务存储引擎的修改，会对应不同的Gtids
主从一对一的Gtid被破坏
6、参考文献
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002qhe.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002qsk.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002s5l.html
http://code.openark.org/blog/mysql/thoughts-on-mysql-5-6-new-replication-features
http://www.mysqlsystems.com/2013/03/mysql-replication-gtid-notes.html
