一、什么是 GTID
GTID （Global Transaction Identifiers）是对付一个已提交事务的编号，事务的独一编号，而且是一个全局独一的编号。GTID 和事务会记录到 binlog 中，用来标识事务。
GTID 是用来替代以前 classic 复制要领，MySQL-5.6.2 开始支持 GTID，在 MySQL-5.6.10 后完善。
有了 GTID，一个事务在集群中就不再孑立，在每一个节点中，都存在具有沟通标识符的兄弟们和它作伴，可以制止同一个事务，在同一个节点中呈现多次的环境。
GTID 的呈现，最直接的结果就是，每一个事务在集群中具有了独一性的意义，这在运维方面具有更大的意义，因为利用 GTID 后再也不需要为了不绝地找点而烦恼了，给 DBA 带来了很大的便利性。
GTID 构成：
GTID 是由 server_uuid:Sequence_Number 。
Server_Uuid：是一个 MySQL 实例的全局独一标识；存放为在$datadir/auto.cnf
Sequence_Number：是 MySQL 内部的一个事务的编号，一个 MySQL 实例不会反复的序列号（担保处事器内独一），也暗示在该实例上已经提交事务的数量，而且跟着事务提交而递增。
按照 GTID 可以知道事务最初是在哪个实例上提交的，利便妨碍排查和切换
cat /data/mysql/data/auto.cnf
[auto]
server-uuid=b3f31135-4851-11e8-b758-000c29148b03
二、GTID 主从复制道理
(1) 当一个事务在主库端执行并提交时，发生 GTID，一同记录到 binlog 日志中。
(2) binlog 传输到 slave,并存储到 slave 的 relaylog 后，读取这个 GTID 的这个值配置 gtid_next 变量，即汇报 Slave，下一个要执行的 GTID 值。
(3) sql 线程从 relay log 中获取 GTID，然后比拟 slave 端的 binlog 是否有该 GTID。
(4) 假如有记录，说明该 GTID 的事务已经执行，slave 会忽略。
(5) 假如没有记录，slave 就会执行该 GTID 事务，并记录该 GTID 到自身的 binlog;
(6) 在理会进程中会判定是否有主键，假如没有就用二级索引，假如没有就用全部扫描。
三、GTID 优势和限制
GTID 的优势:
(1) 按照 GTID 可以快速简直定事务最初是在哪个实例上提交的。
(2) 简朴的实现 failover，不消以前那样在需要找 log_file 和 log_pos。
(3) 更简朴的搭建主从复制，确保每个事务只会被执行一次。
(4) 比传统的复制越发安详。
(5) GTID 的引入，让每一个事务在集群事务的海洋中有了秩序，使得 DBA 在运维中做集群变迁时越发利便，可以或许做到胸有成竹心中有数。
GTID 的限制:
因为基于 GTID 的复制依赖于事务，所以在利用 GTID 时，有些 MySQL 特性是不支持的。
(1) 不答允在一个 SQL 同时更新一个事务引擎和非事务引擎的表；
事务中殽杂多个存储引擎，就会发生多个 GTID。当利用 GTID 时，假如在同一个事务中，更新包罗了非事务引擎（如 MyISAM）和事务引擎（如 InnoDB）表的操纵，就会导致多个 GTID 分派给了同一个事务。
(2) 主从库的表存储引擎必需是一致的；
主从库的表存储引擎纷歧致，就会导致数据纷歧致。假如主从库的存储引擎纷歧致，譬喻一个是事务存储引擎，一个长短事务存储引擎，则会导致事务和 GTID 之间一对一的干系被粉碎，功效就会导致基于 GTID 的复制不能正确运行；
(3) 不支持 create table … select 语句复制（主库直接报错）
由于利用基于行模式的复制时，create table ...select 语句会被记录为两个单独的事件（会生成两个 sql），一个是 DDL 建设表 SQL，一个是 insert into 插入数据的 SQL。由于 DDL 会导致自动提交，所以这个 sql 至少需要两个 GTID，可是 GTID 模式下，只能给这个 sql 生成一个 GTID，假如强制执行会导致和上面（2）中一样的功效。
(4) 在一个复制组中，必需要求统一开启 GTID 或是封锁 GTID;
(5) 开启 GTID 需要重启（5.6 需要，5.7 中不需要）
(6) 开启 GTID 后，就不能在利用本来的传统的复制方法;
(7) 不支持 create temporary table 和 drop temporary table 语句;
利用 GTID 复制时，不支持 create temporary table 和 drop temporary table ，可是在 autocommit=1 环境下可以建设姑且表，MASTER 建设姑且表不发生 GTID 信息，所以不会同步到 SLAVE 上，可是删除姑且表时，发生 GTID 会导致主从复制间断。
(8) 不推荐在 GTID 模式的实例长举办 mysql_upgrade;
因为 mysql_upgrade 的进程要建设或修改系统表（非事务引擎），所以不发起在开启 GTID 的模式的实例上利用带有--write-binlog 选项的 mysql_upgrade;
(9) 不支持 sql_slave_skip_counter;
四、为什么要利用 GTID
好比以下M-S布局
S1→M←S2，当M宕机的时候，个中一台S就必需包袱起M的责任，可是由于2台S之间没有干系，很难使S2成为S1的slave。
GTID 的存在利便了 Replication 的 Failover在 MySQL 5.6 GTID 呈现之前 Replication failover 的操纵进程：修改复制源的呼吁语法为：
mysql> CHANGE MASTER TO
MASTER_HOST='XXXX',
MASTER_USER='XXXX',
MASTER_PASSWORD='XXXXX',
MASTER_LOG_FILE='XXXXX',
MASTER_LOG_POS=XXXXX;