MySQL 基础知识梳理学习（四）----GTID

在日常运维中，GTID带来的最方便的作用就是搭建和维护主从复制。GTID的主从模式代替了MySQL早期版本中利用二进制日志文件的名称和日志位置的做法，使用GTID使操作和维护都变得更加简洁和可高。

1.GTID的优点

（1）基于GTID搭建主从复制根据简单。

（2）可以确保每个事务只会被执行一次。

（3）可以方便的实现Replication的Failover，不需要像传统模式复制那样去找master_log_file和master_log_pos。

（4）GTID在MGR中也发挥了中要作用。MGR各节点之间复制依赖于GTID，并且在集群节点进行Recover重新加入到集群的操作中，会选择其中一个节点作为Donor,然后基于Purged的GTID开始同步数据。MGR还是通过GTID进行冲突验证，用于跟踪每个实例上提交的事务，确定哪些事务可能有冲突。

2.使用GTID搭建主从时，需要注意的MySQL参数。

（1）server_id: 设置MySQL实例的server_id,每个实例的server_id不能一样。

（2）gtid_mod=ON: MySQL实例开启GTID模式。

（3）enforce_gtid_consitency=ON: 使用GTID模式复制时，需要开启此参数，用来保证GTID的一致性。

（4）log-bin: MySQL必须开启Binlog。

（5）log-slave-updates=1：决定slave从master接受到的更新且执行之后，执行的Binlog是否记录到salve的Binlog中，建议开启。

（6）binlog_format=ROW：强烈建议binlog_format使用ROW格式，其它格式可能造成数据不一致。

（7）skip-slave-start=1：当salve数据库启动的时候，salve不会自动开启复制。

3.使用GTID的注意事项

由于基于GTID的复制依赖于事务，所以在使用GTID时，有些MySQL特性不支持。

（1）事务中混合多个存储引擎，会产生多个GTID。

当使用GTID时，如果在同一个事务中，更新包含了非事务引擎（如MyISAM）和事务引擎（InnoDB）表的操作，就会导致多个GTID分配给同一个事务。

（2）主从库的表存储引擎不一致，会导致数据不一致。

如果主从库的存储引擎不一致，例如一个是事务存储引擎，一个是非事务存储引擎，则会导致事务和GTID之间一对一的关系被破坏，结果导致基于GTID的复制不能正确地运行。

（3）基于GTID模式复制，不支持Create table ...select 语句。

因为使用基于行模式的复制时，该语句实际上被记录为两个单独的事件，一个是创建表，另一个是将原表中的数据插入到刚刚新建的表中。当在事务中执行该语句时，在一些情况下。这两个事务可能接收到相同的事务ID，这意味着包含插入的事务将被从库挑过。

（4）不支持Create Temporary table 和 drop temporary table。

使用GTID复制时，不支持Create Temporary table 和 drop temporary table。但是，在autocommit=1的情况下可以创建临时表，master创建临时表不产生GTID信息，所以不会同步到Salve上，但是删除临时表时，产生GTID会导致主从中断。

（5）不推荐在GTID模式的实例上进行mysql_upgrade.

因为mysql_upgrade的过程要创建或修改系统表，而系统表时非事务引擎，所以不建议在开启GTID模式的实例上使用带有--write-binlog选项的mysql_upgrade。

（6）一旦在给定的MySQL实例中提交了事务，具有相同GTID的事务便会被该服务器忽略。而且，在主实例上提交的事务在从库上只可以应用一次。

-----主要内容参考梳理于网络知识，此短文仅为学习笔记，在此原创作者感谢！