ENFORCE_GTID_CONSISTENCY与临时表的问题

简介:

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



修改 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).

目录
相关文章
|
7月前
|
存储 SQL 关系型数据库
binlog,undolog,redolog
binlog,undolog,redolog
100 3
|
6月前
|
存储 SQL 关系型数据库
binlog、redolog和undolog三者有何区别?
MySQL中的binlog、redo log和undo log是日志文件,各有特定作用。binlog用于数据备份、恢复和复制,适用于所有存储引擎。redo log记录事务修改,用于崩溃恢复和数据持久性,仅InnoDB存储引擎支持。undo log保存事务修改前的状态,用于事务回滚和MVCC,也仅InnoDB支持。它们在功能和记录内容上有明显区别,有助于事务管理和数据库一致性。
174 0
|
SQL Oracle 关系型数据库
数据库复制对nologging操作的处理
当DML操作以NOLOGGING方式执行时,或者SQLLoader以UNRECOVERABLE方式进行直接路径加载时,会禁止生成重做日志或者只会生成很少的日志信息,这些可以加快这些操作的速度。
101 0
|
SQL 存储 Java
|
SQL 关系型数据库 MySQL
MySQL事务隔离与undo log、MVCC的亲密关系(上)
MySQL事务隔离与undo log、MVCC的亲密关系
141 0
MySQL事务隔离与undo log、MVCC的亲密关系(上)
|
存储 监控 关系型数据库
MySQL事务隔离与undo log、MVCC的亲密关系(下)
MySQL事务隔离与undo log、MVCC的亲密关系
133 0
|
SQL 存储 缓存
MySQL中的redolog,undolog,以及binlog的区别及各自作用是什么?
MySQL中有六种日志文件, 分别是:重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、慢查询日志(slow query log)、一般查询日志(general log),中继日志(relay log)。 其中重做日志和回滚日志与事务操作息息相关,二进制日志也与事务操作有一定的关系,这三种日志,对理解MySQL中的事务操作有着重要的意义。 这里简单总结一下这三者具有一定相关性的日志。
MySQL中的redolog,undolog,以及binlog的区别及各自作用是什么?
|
AliSQL 关系型数据库 MySQL
Binlog In Redo
Introduce the feature which persists binlog into redo on RDS-8.0
407 0
Binlog In Redo