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

2023-11-12 来源：哗拓教育

[root@localhost tmp]# mysqlbinlog --no-defaults mysql-bin.000614|mysql -uroot -pEnter password:ERROR 1781 (HY000) at line 16: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.[root@localhost tmp]# mysqlbinlog --no-defaults mysql-bin.000614|mysql -uroot -pEnter password:[root@localhost tmp]# echo $?0

服务器相关环境参数：

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

MySQL版本：

mysql> select version();+-----------+| version() |+-----------+| 5.7.13    |+-----------+1 row in set (0.00 sec)

解决办法：

配置gtid选项

配置前：

mysql> show global variables like 'gtid_mode';ERROR 2006 (HY000): MySQL server has gone awayNo connection. Trying to reconnect...Connection id:    24Current database: gold+---------------+-------+| Variable_name | Value |+---------------+-------+| gtid_mode     | OFF   |+---------------+-------+1 row in set (0.10 sec)

配置后：

mysql> set @@GLOBAL.GTID_MODE = on;ERROR 1788 (HY000): The value of @@GLOBAL.GTID_MODE can only be changed one step at a time: OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON. Also note that this value must be stepped up or down simultaneously on all servers. See the Manual for instructions.mysql> set @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;mysql> show global variables like 'gtid_mode';+---------------+----------------+| Variable_name | Value          |+---------------+----------------+| gtid_mode     | OFF_PERMISSIVE |+---------------+----------------+1 row in set (0.00 sec)

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模式，上述不支持的语句将会返回错误。

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

标签：next state 解决办法 gtid table 系统开发 col sele

小编还为您整理了以下内容，可能对您也有帮助：

解析如何通过Mysql的二进制日志恢复数据库数据（图文详解）

本篇文章主要介绍了详解如何通过Mysql的二进制日志恢复数据库数据，具有一定的参考价值，有兴趣的可以了解一下。

经常有网站管理员因为各种原因和操作，导致网站数据误删，而且又没有做网站备份，结果不知所措，甚至给网站运营和盈利带来负面影响。所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据。

系统环境：

操作系统：CentOS 6.5 X64 (虚拟机)；

WEB服务：PHP+Mysql+apache；

网站：为方便，直接在本地用蝉知系统搭建一个DEMO站点；

操作步骤：

1.开启binlog功能及基本操作；

2.往站点添加数据；

3.刷新binlog日志；

4.删除数据；

5.binlog日志内容解析；

6.恢复指定数据；

1.开启binlog功能及基本操作

要使用Mysql的binlog日志功能，首先要在Mysql的配置文件中开启该功能，操作很简单。找到Mysql的配置文件，在文件中添加一行”log_bin = mysql-bin”即可。其实在我安装的各种Mysql环境中，该功能通常都是默认开启的。

开启binlog功能后，在mysql的数据库目录下就会有诸如mysql-bin.000001、mysql-bin.000002等文件，这就是mysql的二进制日志文件。每当mysql启动或手动刷新日志后都会新建一个二进制日志文件。

首先我们mysql命令行中，用”show master logs”命令查看已有的binlog文件。

2.往站点添加数据

在网站后台文章模块里，我添加了几条测试数据。

3.刷新binlog日志

此前mysql的binlog文件为mysql-bin.000001，并且在网站后台往数据库中添加了三篇文章。现在我们刷新binlog日志，会生成新的mysql-bin.000002文件，如下：

flush logs;

show master logs;

4.删除数据

这里我把刚才添加的三篇文章都删除掉。

5.binlog日志内容解析

Mysql的二进制日志文件记录的mysql的操作，比如刚才的删除操作，我们来看下日志文件的具体内容。

使用mysql的mysqlbinlog命令：

mysqlbinlog /data/mysql/mysql-bin.000002注意：因为我本地mysqlbinlog无法识别binlog配置中的default-character-set=utf8，所以这里我在命令中加上了” _no-defaults”才起作用，大家引以为鉴。

下面是日志内容部分截图：

6.恢复指定数据；

在通过mysql的binlog日志恢复数据时，我们可以指定恢复到具体时间点，这有点像服务器快照管理。所以我们现在要恢复刚才删除的那篇文章，可以从删除之前找一个时间点，并恢复到那个时间点即可。

有关mysqlbinlog命令的使用方法，我们可以通过mysqlbinlog的帮助命令进行查看，如下：

mysqlbinlog _no-defaults _help

如帮助文档所示，可以通过指定时间或指定位置来恢复数据，这里我以指定时间为例给大家演示。

我们来查看下日志文件mysql-bin.000001，如下：

mysqlbinlog -no--defaults /data/mysql/mysql-bin.000001

通过前面操作步骤我们知道，在删除数据之前，我们生成了mysql-bin.000002日志文件，所以我们只要恢复到这个时间点即可，上图中我已找到了这个时间。

命令如下：

代码如下:

mysqlbinlog _no-defaults _stop-datetime='2017-04-11 09:48:48'/data/mysql/mysql-bin.000001 |mysql _uroot _p123456

这时我们在看后台，发现刚才删除的三篇文章都已恢复回来了，从而到达我们期望的目的。

总结：

本文和大家分享了如何通过mysql的二进制日志文件恢复数据。但还是要提醒大家，在平时要做好网站数据备份，现在的一些主流CMS建站系统都会内置数据库备份功能，比如这里我用的蝉知系统，数据是网站的命脉，做好数据备份以避免后期不必要的麻烦或损失。

mysql数据库怎样用日志恢复数据sql语句

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
SHOW BINLOG EVENTS /G
你还可以从命令行输入下面的内容：
mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS /G'
将密码my_pwd替换为服务器的root密码。
1. 指定恢复时间
对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是2006年4月20日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 /
mysql -u root -pmypwd
该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 /
mysql -u root -pmypwd /
在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。

mysql数据库怎样用日志恢复数据sql语句

为什么使用mysqlbinlog无法恢复数据

1. 以前我错误的认为mysql的日志可以恢复到任何时间的状态，其实并不是这样，这个恢复是有前提的，就是你至少得有一个从日志记录开始后的数据库备份，通过日志恢复数据库实际上只是一个对以前操作的回放过程而已，不用想得太复杂，既然是回放你就得注意了，如果你执行了两次恢复那么就相当于是回放了两次，后果如何你自己应该清楚了吧。

2. 要想通过日志恢复数据库，在你的my.cnf文件里应该有如下的定义，log-bin=mysql-bin，这个是必须的.binlog-do-db=db_test,这个是指定哪些数据库需要日志，如果有多个数据库就每行一个，如果不指定的话默认就是所有数据库.
[mysqld]
log-bin=mysql-bin
binlog-do-db=db_test
binlog-do-db=db_test2

3.删除二进制日志:
a.mysql> system ls -ltr /var/lib/mysql/bintest*;
mysql>reset master(清空所有的二进制日志文件)
b.purge master logs to 'bintest.000006';(删除bintest.000006之前的二进制日志文件)
c.purge master logs before '2007-08-10 04:07:00'(删除该日期之前的日志)
d.在my.cnf 配置文件中[mysqld]中添加:
expire_logs_day=3设置日志的过期天数,过了指定的天数,会自动删除

4.下面就是恢复操作了
特别提示，mysql每次启动都会重新生成一个类似mysql-bin.000003的文件，如果你的mysql每天都要重新启动一次的话，这时候你就要特别注意不要选错日志文件了。

(注意：下面有一些技巧，这些东西才是最宝贵的哟，普通的东东手册上都有，这可是我摸索出来的哟，别人我都不告诉他。

技巧1 :
在下面你将看到 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd 类似的语句，但是它一次只能操作一个日志文件，如果你变通一下变成这样 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.0* | mysql -u root -pmypwd 那么它基本上就会表示出的所有的日志文件了，这样可解决你忘记在哪一个日志文件中的问题，当然你也可以用这种写法更完美,mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.[0-9]* | mysql -u root -pmypwd ，看到[0-9]*这个东东了吧，它表示以数字开头的任何字符，方便吧！

技巧2:
你可以通过--one-database 参数选择性的恢复单个数据库，example在下面，爽吧。
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test

技巧3:
如果你老人家已经使用过 /usr/local/mysql5/bin/mysqlbinlog --start-date="2005-04-20 9:55:00" /var/data/mysql5/mysql-bin.0* > /home/db/tt.sql 类似的语句将日志导成了ASCII文本文件，那么你就可以直接在phpmyadmin或者其它什么乱七糟八的的客户端里执行这个文件文件就行了，因为它本身就是一个标准的sql文件，比如想让文件里面的某些语句不执行，OK，it's easy,找到它们删除即可，然后再放进去执行就OK滴啦！这个可是灰常灰常的爽哟。。。。。。

技巧4:
我来给大家讲一下，下面这条语句都做了什么
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
这是把mysql-bin.000001这个二进制文件里的内容转换成ASCII文件(也就是sql语句)，直接通过管道操作符"|"传输给 mysql这个程序，然后过滤掉其它数据库的语句，只在db_test里执行。

技巧5:
着了，多打了一个技巧，现在暂时没内容，等以后再加吧！！！
)

下面部份摘录自网上。

如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于 mysqlbinlog的详细信息，参见mysql手册8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：

SHOW BINLOG EVENTS G

你还可以从命令行输入下面的内容：

mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS G'

将密码my_pwd替换为服务器的root密码。

1. 指定恢复时间

对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是2005年4月20日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：

mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：

mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。

2. 指定恢复位置

也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。操作方法为：

mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00"
/var/log/mysql/mysql-bin.000001 > /tmp/mysql_restore.sql

该命令将在/tmp目录创建小的文本文件，将显示执行了错误的SQL语句时的SQL语句。你可以用文本编辑器打开该文件，寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复操作，应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后，你应从命令行输入下面内容：

mysqlbinlog --stop-position="368312" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，恢复的数据和相关MySQL日志将反应事务执行的原时间。

为什么使用mysqlbinlog无法恢复数据

我的MYSQL是5.0版本的,运行总是会报错,请问如何解决?

1、可能是/opt/mysql-master/data/数据目录mysql用户没有权限(修改数据目录的权限)

解决方法：给予权限，执行 "chown -R mysql.mysql /opt/mysql-master/data" 然后重新启动mysqld

2、可能进程里已经存在mysql进程

解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9 进程号”杀死，然后重新启动mysqld！

3、可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。

解决方法：去mysql的二进制日志目录看看，如果存在mysql-binlog.index，就赶快把它删除掉吧

4、mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]下有没有指定数据目录(datadir)。

解决方法：请在[mysqld]下设置这一行：datadir = /opt/mysql-master/data

5、skip-federated字段问题

解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。

6、错误日志目录不存在

解决方法：使用“chown” “chmod”命令赋予mysql所有者及权限

7、selinux惹的祸，如果是centos系统，默认会开启selinux

解决方法：

先临时改为警告模式:[root@www php]# setenforce 0然后打开/etc/sysconfig/selinux，把SELINUX=enforcing改为SELINUX=disabled

8、可以试着把mysql.cnf默认文件开启，排查是不是配置文件的错误。

常见配置错误有：

查看配置文件/etc/my.cnf里有没有innodb_buffer_pool_size这个参数

innodb_buffer_pool_size：主要作用是缓存innodb表的索引，数据，插入数据时的缓冲；

默认值：128M；专用mysql服务器设置此值的大小：系统内存的70%-80%最佳。如果你的系统内存不大，查看这个参数，把它的值设置小一点吧

温馨提示：记得开启mysql错误日志，方便自己排错。

vim /etc/my.cnf 各位可以根据自己的my.cnf文件编辑[mysql_safe]

log-error = /data/mysql-master/logs/error.log

我的MYSQL是5.0版本的,运行总是会报错,请问如何解决?

高手救命，通过phpmyadmin 误删除mysql数据库怎么恢复

看到一个这样的解决方式不知道能不能帮助你：

phpmyadmin的后台数据库是mysql，下面或许有用。

《mysql数据恢复工具-mysqlbinlog 使用说明》

要使用此功能，首先必须确保mysql配置文件“My.ini”中的

[mysqld] log-bin=log_name #开启二进制日志(其中log_name自己定义)

开启的作用就是开启mysql的二进制日志，然后才可以使用mysqlbinlog工具恢复数据，

开启之后通过在mysql中运行：

SHOW BINLOG EVENTS

来确认二进制日志的开启情况

mysqlbinlog有两种方式来恢复数据：(Mysqldatalog.exe在“MySql\bin\”目录下)

1.通过指定时间：

Mysqldatalog> mysqlbinlog --start-date="2009-11-27 14:01:00" --stop-date="2009-11-27 14:59:59" log_name.000001 > D:\01.txt

2.通过指定位置：

参数说明：

•–start-position=N 从二进制日志中第1个位置等于N参量时的事件开始读。

•–stop-position=N 从二进制日志中第1个位置等于和大于N参量时的事件起停止读。

Mysqldatalog> mysqlbinlog --start-position=123 --end-position=456 log_name.000001 > D:\01.txt

关于position的说明：position可以通过执行SHOW BINLOG EVENTS命令来查看然后进入mysql中执行source 命令 mysql>source D:\01.txt 恢复数据完成。

最后说明：mysqlbinlog工具虽然很强大，但是为保数据不丢失最好还是跟备份数据同步使用。这样恢复数据就可以仅从最后一次备份开始到事故发生时间。

个人现在备份数据库都是采用“多备份”的多云盘自动备份，在怎么误删除也可以找的回来，有个好工具还是需要的

如何使用sql语句备份和恢复mysql数据库

一般使用的命令： mysqlmp --quick --database ondemand1 --u root >bacqup.sql 这样就能把数据库中ondemand1的表全部备份出来。其中参数的格式是：--（两横杠，不是我们常用的单横杠） quick是在数据比较多的时候，不用该参数的话，所有的数据都会先在内存缓存，接着才导出，这样会导致服务器运行减慢！ --u 必须要加一个用户名，否则系统会提示你进不了ODBC数据库的。 >backup.sql则是你备份数据库的目标文件名

数据导入：可以使用MySQL-Front工具把上面导出的backup.sql数据库导入执行。

以下导入方法未测试是否可行！

显示全文

全部栏目

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