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
101 3
|
4月前
|
关系型数据库 MySQL 数据库
为什么需要MVCC 隔离级别
【8月更文挑战第5天】
56 7
|
7月前
|
SQL 安全 关系型数据库
详解InnoDB(1)——事务
详解InnoDB(1)——事务
95 1
|
存储 算法 Oracle
PostgreSQL的MVCC vs InnoDB的MVCC
PostgreSQL的MVCC vs InnoDB的MVCC
103 0
PostgreSQL的MVCC vs InnoDB的MVCC
|
SQL Oracle 关系型数据库
数据库复制对nologging操作的处理
当DML操作以NOLOGGING方式执行时,或者SQLLoader以UNRECOVERABLE方式进行直接路径加载时,会禁止生成重做日志或者只会生成很少的日志信息,这些可以加快这些操作的速度。
103 0
|
存储 SQL 缓存
InnoDB事务剖析
InnoDB事务剖析
238 0
|
SQL 存储 Oracle
事务的隔离级别与MVCC
提到数据库,你多半会联想到事务,进而还可能想起曾经背得滚瓜乱熟的ACID,不知道你有没有想过这个问题,事务有原子性、隔离性、一致性和持久性四大特性,为什么偏偏给隔离性设置了级别? 一切还得从事务说起。
|
SQL 存储 Java
|
SQL 关系型数据库 MySQL
MySQL事务隔离与undo log、MVCC的亲密关系(上)
MySQL事务隔离与undo log、MVCC的亲密关系
142 0
MySQL事务隔离与undo log、MVCC的亲密关系(上)