gtid 详解
Retrieved_Gtid_Set Executed_Gtid_Set
Retrieved_Gtid_Set : 从库已经接收到主库的事务编号
Executed_Gtid_Set : 从库自身已经执行的事务编号
执行三个事务之后
[root@localhost][db1]> create table t2 ( id int);
Query OK, 0 rows affected (0.07 sec)
[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.07 sec)
Records: 1 Duplicates: 0 Warnings: 0
[root@localhost][db1]> insert into t2 select 2;
Query OK, 1 row affected (0.02 sec)
其中主库的 Executed_Gtid_Set为：2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
看到从库的Retrieved_Gtid_Set为: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
Executed_Gtid_Set为： 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
也就是说主库产生了3个事务，从库接收到了主库的3个事务，且都已全部执行。
多个 set
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
原因：
这里的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33好理解，就是已经执行主库的1-33的事务，那么8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1呢?其实也简单，有两种情况
一种：NO.1 从库有数据写入（即从库插入数据）
[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.03 sec)
Records: 1 Duplicates: 0 Warnings: 0
show slave status\G;
Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Auto_Position: 1
Replicate_Rewrite_DB:
可以看到已经执行的事务有来自主库的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,也有从库自己写入的数据：8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1。
另一种：NO.2 主从切换(这里使用的是MHA切换主从)
Master_Server_Id: 20
Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
Auto_Position: 1
可以看到主从切换以后主库的server-id是20。这里的意思是接收到主库8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1,并已经执行了这个事物，这个事物其实就是之前从库写入的那条数据。对于2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3就是之前主库执行的3个事务，如果此时在主库再插入一条数据，那么变化如下：
Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2
下面说说GTID不连续问题
这个是由于binlog被清理后导致的:
binlog不可能永远驻留在服务上，需要定期进行清理(通过expire_logs_days可以控制定期清理间隔)，否则迟早它会把磁盘用尽。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。
