## 实验环境


此次实验的环境如下

- MySQL 5.7.25

- Redhat 6.10

- 操作系统账号:mysql

- 数据库复制账号:repl

- 复制格式:基于行的复制


| IP地址 |主从关系|复制账号  |复制格式  |
| --- | --- | --- | --- |
| 11.12.14.29 | 主库 | repl |Row-Based  |
| 11.12.14.30| 从库(半同步)| repl |Row-Based|


这节我们的内容为MySQL的复制,MySQL复制有两种形式

- 基于二进制日志文件位置
- 基于GTID

上节说了如何一步步搭建基于GTID的复制

由于其是基于事务的,有一些特性可能不受支持,接下来我们详细说下

当我们设置enforce-gtid-consistency=true时,如下操作会返回错误,前提是二进制日志功能被启用并且写入到二进制文件中

但我们也必须设置该参数,否则复制会出问题





## 1. update语句中引用了非事务型的表

如果我们update事务表(如innodb)时引用了非事务表(如MyISAM ),这样是不行的,因为事务可能被分配多个GTID

这种情况也有可能在主从库的存储引擎不一致时发生


## 2. CREATE TABLE ... SELECT 语句


当使用行格式的二进制日志时,CREATE TABLE ... SELECT 语句不受支持,因为该语句会分成2个语句及2个GTID(一个create一个insert)

这种情况我们可以直接写成两个语句来达到目的

## 3. 临时表

在事务,存储过程,函数和触发器内部不可以使用 CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句

如果需要使用需要在事务外部,并且 autocommit=1


## 4.   sql_slave_skip_counter

该参数在启用了GTID后不被支持,如果需要跳过事务,可以使用gtid_next变量


非GTID模式:

```
mysql> stop slave sql_thread;
mysql> set global sql_slave_skip_counter=1;
mysql> start slave sql_thread;
```

GTID模式:

```
mysql> SET @@SESSION.GTID_NEXT= '508fb971-3402-11e5-a0aa-08002788310b:1346';
mysql> BEGIN;
mysql> COMMIT;
mysql> SET GTID_NEXT='AUTOMATIC';
```

注意此方法可能会导致数据库丢失,跳过后请检查主从数据的一致性

## 5. 忽略服务器

 IGNORE_SERVER_IDS 参数会被废弃
 
## 6.mysql_upgrade

启用GTID后,不要在mysql_upgrade时写入日志,默认是不写入的的



好了上面就是一些启用GTID功能后的一些限制,我们无需理会他们,MySQL会自动处理这些问题





## 7. 参考资料

本专题内容翻译自官方文档并结合自己的环境

[https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html)