实验环境

此次实验的环境如下

  • 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