mysql gtid模式主键主突_MySQL-5.7.20二进制主从复制（GTID模式）

GTID优势

更简单的实现 failover，不用以前那样在需要找 log_file 和 log_Pos。

更简单的搭建主从复制。

复制集群有一个统一的方式识别复制位置，给集群管理带来了便利。

正常情况下，GTID 是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

GTID的限制

在一个事务里面混合使用引擎,如 Innodb(支持事务)、MyISAM(不支持事务)， 造成多个 GTIDs 和同一个事务相关联出错

CREATE TABLE…..SELECT 不能使用，该语句产生的两个 event 在某一情况 会使用同一个 GTID(同一个 GTID 在 slave 只能被使用一次)

1th event:创建表语句 create table

2th event:插入数据语句 insert

CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 不能在事务内使用 (启用了–enforce-gtid-consistency 参数)。

GTID的工作原理

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

4、如果有记录，说明该GTID的事务已经执行，slave会忽略。

5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

server_uuid是MySQL Server的只读变量，保存在数据目录下的auto.cnf中，可直接通过cat命令查看。MySQL第一次启动时候创建auto.cnf文件，并生成server_uuid(MySQL使用机器网卡，当前时间，随机数等拼接成一个128bit的uuid，可认为在全宇宙都是唯一的，在未来一百年，使用同样的算法生成的uuid是不会冲突的)。之后MySQL再启动时不会重复生成uuid，而是使用auto.cnf中的uuid。

在同一个集群内，每个MySQL实例的server_uuid必须唯一，否则同步时，会造成IO线程不停的中断，重连。在通过备份恢复数据时，一定要将var目录中的auto.cnf删掉，让MySQL启动时自己生成uuid

GTID中还有一部分是transaction_id，同一个server_uuid下的transaction_id一般是递增的。如果一个事务是通过用户线程执行，那么MySQL在生成的GTID时，会使用它自己的server_uuid，然后再递增一个transaction_id作为该事务的GTID。当然，如果事务是通过SQL线程回放relay-log时产生，那么GTID就直接使用binlog里的了。在MySQL 5.6中不用担心binlog里没有GTID，因为如果从