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

目录
相关文章
|
4月前
|
存储 SQL 关系型数据库
binlog,undolog,redolog
binlog,undolog,redolog
89 3
|
3月前
|
存储 SQL 关系型数据库
binlog、redolog和undolog三者有何区别?
MySQL中的binlog、redo log和undo log是日志文件,各有特定作用。binlog用于数据备份、恢复和复制,适用于所有存储引擎。redo log记录事务修改,用于崩溃恢复和数据持久性,仅InnoDB存储引擎支持。undo log保存事务修改前的状态,用于事务回滚和MVCC,也仅InnoDB支持。它们在功能和记录内容上有明显区别,有助于事务管理和数据库一致性。
|
10月前
|
关系型数据库 MySQL
MySQL 5.7 基于GTID主从复制+并行复制+半同步复制
MySQL 5.7 基于GTID主从复制+并行复制+半同步复制
117 0
|
SQL Oracle 关系型数据库
数据库复制对nologging操作的处理
当DML操作以NOLOGGING方式执行时,或者SQLLoader以UNRECOVERABLE方式进行直接路径加载时,会禁止生成重做日志或者只会生成很少的日志信息,这些可以加快这些操作的速度。
|
关系型数据库 MySQL
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
609 0
|
SQL 关系型数据库 MySQL
是谁,把InnoDB表上的DML搞慢的?
是谁,把InnoDB表上的DML搞慢的?
118 0
是谁,把InnoDB表上的DML搞慢的?
|
SQL 存储 Java
|
关系型数据库 MySQL 数据库
【愚公系列】2022年04月 Mysql数据库-GTID同步
【愚公系列】2022年04月 Mysql数据库-GTID同步
201 0
|
SQL 存储 关系型数据库
DDL_Synchronization
在共享存储一写多读的架构下,数据文件实际上只有一份。得益于多版本机制,不同节点的读写实际上并不会冲突。但是有一些数据操作不具有多版本机制,其中比较有代表性的就是文件操作。
DDL_Synchronization