ENFORCE_GTID_CONSISTENCY与临时表的问题

简介:

业务从5.6切到5.7后,启用gtid,业务有临时表。出现:

qnz9sa0MaxwfH887YA2jg+2DagjWOFbQPaOFbYAm


修改 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = off;


配置文件中

ENFORCE_GTID_CONSISTENCY = off;


###

Checkpoint 1. Ensure that your workload is compatible with GTIDs.

This checkpoint is needed because GTIDs do put (small) restrictions on the SQL you can execute. The following statements are disallowed: CREATE  TABLE … SELECT; CREATE TEMPORARY or DROP TEMPORARY inside a transaction context; and mixing transactional tables with nontransactional tables in the same statement or in the same transaction context. Such statements must be eliminated from the workload (this is a good practice anyways, because the non-transactional nature of these statements makes them unsuitable for replication).

We do not expect these to be severe limitations for most users. But, to be sure that enabling GTIDs does not cause any surprises, you can now pre-check your workload by enabling a mode that generates warnings for the GTID-violating statements.

To complete checkpoint 1, do the following:

1. On each server, execute: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN, and set enforce-gtid-consistency=WARN in my.cnf.

2. Let it run for a while with your normal workload. Any GTID-violating statement will execute correctly, but generate a warning in the server log, like:

or

or

Look in the log for these warnings. If there are any warnings , adjust your SQL so that it only uses GTID-compatible statements. E.g., replace CREATE TABLE … SELECT by a CREATE TABLE statement followed by an INSERT statement, move CREATE/DROP TEMPORARY out of transactional context, or switch to InnoDB for any table that needs to be updated in the same transaction or in the same statement as other InnoDB tables. Notice that these statements are risky to use together with replication, so all this is good to do anyways. Repeat until it does not generate any warning.

3. On each server, execute: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON, and set enforce-gtid-consistency=ON in my.cnf so that the value is preserved next time you need to restart (you don’t need to restart due to this procedure, but there could always be some other reason).

目录
相关文章
|
1月前
|
存储 SQL 关系型数据库
binlog,undolog,redolog
binlog,undolog,redolog
42 3
|
11月前
|
SQL Oracle 关系型数据库
数据库复制对nologging操作的处理
当DML操作以NOLOGGING方式执行时,或者SQLLoader以UNRECOVERABLE方式进行直接路径加载时,会禁止生成重做日志或者只会生成很少的日志信息,这些可以加快这些操作的速度。
|
SQL 存储 Java
|
存储 监控 关系型数据库
MySQL事务隔离与undo log、MVCC的亲密关系(下)
MySQL事务隔离与undo log、MVCC的亲密关系
105 0
|
SQL 关系型数据库 MySQL
MySQL事务隔离与undo log、MVCC的亲密关系(上)
MySQL事务隔离与undo log、MVCC的亲密关系
113 0
MySQL事务隔离与undo log、MVCC的亲密关系(上)
|
SQL 存储 关系型数据库
DDL_Synchronization
在共享存储一写多读的架构下,数据文件实际上只有一份。得益于多版本机制,不同节点的读写实际上并不会冲突。但是有一些数据操作不具有多版本机制,其中比较有代表性的就是文件操作。
DDL_Synchronization
|
SQL 存储 缓存
MySQL中的redolog,undolog,以及binlog的区别及各自作用是什么?
MySQL中有六种日志文件, 分别是:重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、慢查询日志(slow query log)、一般查询日志(general log),中继日志(relay log)。 其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义。 这里简单总结一下这三者具有一定相关性的日志。
MySQL中的redolog,undolog,以及binlog的区别及各自作用是什么?
|
弹性计算 关系型数据库 测试技术
为什么高并发小事务, unlogged table不比logged table快多少? - commit wal log
标签 PostgreSQL , unlogged table , logged table , wal writer 背景 unlogged table,这些表的写操作不记录WAL日志。那么这种表的高并发写入一定比logged table快,快很多吗? 实际上一个事务,在事务结束时,也会记录一笔commit或rollback xlog,所以如果是高并发的小事务,commit xlog的
802 0
|
算法 MySQL 关系型数据库