GTID

MySQL

5.6使用server_uuid和transaction_id两个共同组成一个GTID。

即：GTID =

server_uuid:transaction_id.

server_uuid是MySQL Server的只读变量，保存在数据目录下的auto.cnf中,MySQL第一次启动时候创建auto.cnf文件,其是128bit的uuid。可以通过MySQL客户端使用如下命令查看server_uuid，看到的实际上是server_uuid的十六进制编码，总共16字节(其中uuid中的横线只是为了便于查看，并没有实际意义)：

mysql> show global variables like
'server_uuid';
+---------------+--------------------------------------+
| Variable_name | Value
|
+---------------+--------------------------------------+
| server_uuid |
eb1fbc5d-5f48-11e9-aba6-005056981a9d |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

MySQL支持通过设置Session级别的变量gtid_next，来指定下一个事务的GTID，格式就是‘server_uuid:transaction_id'。之后还可以改回AUTOMATIC(默认值)

mysql>setgtid_next='b694c8b2-883f-11e5-85fb-e41f136aba3e:12000005';
QueryOK,0rowsaffected(0.00sec)
mysql>begin;
QueryOK,0rowsaffected(0.00sec)
mysql>commit;
QueryOK,0rowsaffected(0.00sec)
mysql>setgtid_next=AUTOMATIC;
QueryOK,0rowsaffected(0.00sec)

一般设置gtid_next是加1，用于主从同步时跳过一个事务。但是如果设置gtid_next之后，导致当前server_uuid下的transaction_id不连续，那么坑爹的地方也就出现了。在改回AUTOMATIC以后，再有事务执行时，MySQL生成transaction_id时，不是按当前最大的transaction_id继续增长，而是补缺口(使用最小的缺失的那个transaction_id作为下一个gtid)。这样的话，即使是同一个server_uuid，也不能通过transaction_id的大小来判断事务的顺序。

在MySQL

5.6中不用担心binlog里没有GTID，因为如果从库开启了GTID模式，主库也必须开启，否则IO线程在建立连接的时候就中断了。5.6的GTID对MySQL的集群环境要求是非常严格的，要么主从全部开启GTID模式，要么全部关闭GTID模式。

配置方式为gtid_mode=ON/OFF。让人诧异的是gtid_mode的类型为枚举类型，枚举值可以为ON和OFF，所以应该通过ON或者OFF来控制gtid_mode，不要把它配置成0或者1，否则结果可能不符合你的预期.

mysql> show global variables like
'%gtid%';
+----------------------------------+-------+
| Variable_name
| Value |
+----------------------------------+-------+
| binlog_gtid_simple_recovery
| ON
|
| enforce_gtid_consistency |
OFF
|
| gtid_executed
|
|
| gtid_executed_compression_period |
1000
|
| gtid_mode
| OFF
|
| gtid_owned
|
|
| gtid_purged
|
|
| session_track_gtids
| OFF
|
+----------------------------------+-------+

开启gtid_mode时，log-bin和log-slave-updates也必须开启，否则MySQL Server拒绝启动。

除此以外，enforce-gtid-consistency也必须开启，否则MySQL Server也拒绝启动。

一旦使用GTID模式同步以后，主从切换就可以使用GTID来自动找点儿了，使用方式是在CHANGE MASTER时指定MASTER_AUTO_POSITION=1

当开启GTID时，每个binlog文件都有且只有一个Previous-GTIDs，位置都是在Format_description_log_event之后的第一个Binlog Event处。它的含义是在当前Binlog文件之前执行过的GTID集合，可以充当索引用，使用这个Binlog Event，可以便于快速判断GTID是否位于当前binlog文件中。

mysql uuid没变化 mysql server uuid_MySQL

在MySQL

5.7版本中，其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能，即将参数gtid_mode设置为OFF呢？故MySQL 5.7又引入了称之为Anonymous_Gtid(ANONYMOUS_GTID_LOG_EVENT)的二进制日志event类型。

当开启GTID时，每一个操作语句(DML/DDL)执行前就会添加一个GTID事件，记录当前全局事务ID；同时在MySQL 5.7版本中，组提交信息也存放在GTID事件中，有两个关键字段last_committed，sequence_number就是用来标识组提交信息的。在InnoDB中有一个全局计数器(global

counter)，在每一次存储引擎提交之前，计数器值就会增加。在事务进入prepare阶段之前，全局计数器的当前值会被储存在事务中，这个值称为此事务的commit-parent(也就是last_committed)。

这意味着在MySQL 5.7版本中即使不开启GTID，每个事务开始前也是会存在一个Anonymous_Gtid，而这个Anonymous_Gtid事件中就存在着组提交的信息。反之，如果开启了GTID后，就不会存在这个Anonymous_Gtid了，从而组提交信息就记录在非匿名GTID事件中。

GTID找点儿原理

我们知道，在未开启GTID模式的情况下，从库用(File_name和File_pos)二元组标识执行到的位置。START SLAVE时，从库会先向主库发送一个BINLOG_DUMP命令，在BINLOG_DUMP命令中指定File_name和File_pos，主库就从这个位置开始发送binlog。

在开启GTID模式的情况下，如果指定MASTER_AUTO_POSITION=1。START SLAVE时，从库会计算Retrieved_Gtid_Set和Executed_Gtid_Set的并集(通过SHOW SLAVE STATUS可以查看)，然后把这个GTID并集发送给主库。主库会使用从库请求的GTID集合和自己的gtid_executed比较，把从库GTID集合里缺失的事务全都发送给从库。如果从库缺失的GTID，已经被主库pruge了呢？从库报1236错误，IO线程中断。

通过GTID找到点儿的原理还是比较奇怪的，它过于强调主从binlog中GTID集合的一致性，弱化了Binlog执行的顺序性。

mysql uuid没变化 mysql server uuid_MySQL