MySQL二进制日志恢复数据报错：@@GLOBAL.GTID_MODE = OFF.

共计 2384 个字符，预计需要花费 6 分钟才能阅读完成。

解决 MySQL 利用二进制日志恢复数据报错：ERROR 1781 (HY000) at line 16: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.

工作中，运用二进制日志，帮开发的同事恢复数据时，出现了报错告警：

服务器相关环境参数：

服务器系统：CentOS Linux release 7.3.1611 (Core)

MySQL 版本：

解决办法：

配置 gtid 选项

配置前：

配置后：

 GTID 相关知识：

GTID(GlobalTransaction ID) 是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID 实际上是由 UUID+TID 组成的。其中 UUID 是一个 MySQL 实例的唯一标识。TID 代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。

MySQL5.6 增加了 GTID 复制。

一个事务对应一个唯一 ID。

一个 GTID 在一个服务器上只会执行一次。

GTID 是用来替代以前 classic 的复制方法。

优点：

相对于行复制来讲数据安全性更高；

故障切换更简单；

GTID 的使用局限：

不支持非事务引擎（从库报错，stopslave; start slave; 忽略）；

不支持 create table … select 语句复制（主库直接报错）；不支持 sql_slave_skip_counter；

对于 createtemporary table 和 drop temporary table 语句不支持；

不允许在一个 SQL 同时更新一个事务引擎和非事务引擎的表；

在一个复制组中，必须要求统一开启 CTID 或是关闭 GTID；

开启 DTID 需要重启（5.7 中可能不需要）；

开启 DTID 后，就不在使用原来的传统的复制方式；

gtid 和非 gtid 的 mysql 实例是不能复制数据的，要么都是 gtid，要么都是普通的；

更新非事务引擎表，在同一事务中更新事务表与非事务表将导致多个 GTIDs 分配给同一事务；

临时表，事务内部不能执行创建删除临时表语句，但可以在事务外执行，但必须设置 set autocommit = 1；

CREATE TABLE … SELECTstatements

不安全的基于语句复制，实际是两个独立的事件，一个用于建表，一个用于向新表插入源表数据。

不执行不支持的语句

启用 –enforce-gtid-consistency 选项启动 GTID 模式，上述不支持的语句将会返回错误。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2018-01/150123.htm