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。

 

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