mysql gtid 限制_MySQL GTID详解

GTID介绍

从MySQL 5.6.5开始支持GTID，每一个在主库上提交的事务在复制集群中可以生成一个唯一的ID。

一个GTID在一个服务器上只执行一次，避免重复执行导致主从不一致或者数据混乱。

在传统复制的slave，binlog日志可以不开启，但是在GTID中，slave的binlog必须开启，目的是记录执行过的GTID。

GTID的组成

GTID = server_uuid:transaction_id

server_uuid：在数据目录下的 auto.cnf 文件是用来保存 server_uuid的。MySQL启动时，会读取 auto.cnf 文件，如果 auto.cnf 文件丢失，则生成一个新的 server_uuid，那么这样GTID的值也会改变。

transaction_id表示该实例上已经提交的事务数量，并且随着事务提交单调递增。例如，要提交的第一个事务的 transaction_id 是1，第十个 transaction_id 是 10，在GTID中，transaction_id不可能是0。

GTID的好处

1.更简单的实现failover ，主从环境主库的dump进程可以直接通过GTID定位到需要发送的binary log位置，而不再需要指定binary log的 LOG_FILE和LOG_POS，只需指定主库的ip、port、username、password 就可以了，因为GTID的复制是自动的，所以会自动找到GTID去同步。根据GTID可以知道事务最初是在哪个实例上提交的。

2.基于库的多线程复制，多线程是针对每个database开启相应的独立线程，即每个库有一个单独的sql thread，如果线上业务中，只有一个database或者绝大多数压力集中在个别database的话，多线程并发复制特性就没有意义了(slave-parallel-workers=0 表示禁用多线程功能)。

GTID的限制

1.不支持非事务引擎(从库报错，stop slave;start slave;忽略)。

2.不支持create table xxx select 语句复制(在最新版本8.0.21已经解决了)。

3.不允许一个SQL同时更新一个事务引擎和非事务引擎的表。

4.在一个复制组中，必须要求统一开启GTID或者是关闭GTID。

5.开启GTID需要重启(MySQL5.7.6版本开始可以在线升级gtid模式)。

6.开启GTID后，就不再使用原来的传统的复制方式。

7.对于create temporary table和drop temporary语句不支持。

8.不支持sql_slave_skip_counter。

开启GTID

gtid_mode = on

log-bin = mysql-bin #5.6必选 5.7.5和之后可选，为了高可用，最好设置

log-slave-updates = 1 #5.6必选 5.7.5和之后可选，为了高可用，最好设置

enforce-gtid-consistency = 1

判断复制方式GTID 还是传统复制pos

Show slave status 查看Auto_Position字段。

0是传统复制pos方式。

1是gtid方式。

gtid_pureged

gtid_pureged 命令的实际意义：因为没有binlog信息(expire_logs_days)，不考虑这些gtid确认和回滚。常用备份恢复，搭建从库的时候使用。

自动触发机制：flush，服务器重新启动

如果purged掉的GTIDs会包含到gtid_executed中。

mysqldump --set-gtid-purged=off/on 参数：是否将GTID_PURGED 添加到输出中。

gtid_pureged使用场景：

1.在副本上禁用二进制日志记录提交的复制事务的GTIDs。

2.写入二进制日志文件的事务的GTIDs，该文件现在已被清除。

3.通过语句set @@GLOBAL.gtid_purged显式添加到集合中的gtid。