mysql 还原备份_mysql备份还原怎么返回是否备份还原成功了

た 入场券 2023-01-11 03:37 251阅读 0赞

在实例存活的情况,可以在实例状态中查询ALL_GTID。

在实例崩溃的情况,无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

下面列举与ALL_GTID相关的变量。

与ALL_GTID相关的变量

Previous-GTIDs

Previous-GTIDs格式如下(环境为MySQL5.7,日志手动flush binary logs获得):

查看新轮转出的BINLOG:

下面为mysql-bin.00001中包含的GTID:

然后再次flush binary logs:

请点击输入图片描述

mysql-bin.00002中是没有任何GTID的。

综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

请点击输入图片描述

全局变量中的GTID相关的变量

变量解释:

gtid_executed 代表着server上所有事务执行产生的GTID(包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID)。

gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved 是从机上relay_log中的GTID。

ALL_GTID 的计算

了解了GTID相关的变量之后,可以得到获得实例的All_GTID的集合的方法:

对象

方法

存活的Master实例 gtid_executed

存活的Slave实例 gtid_executed和gtid_retrieved的并集

非存活Master实例 最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

非存活Slave实例 最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID

在获得非存活实例中的ALL_GTID时,最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放),所以需要扫描最后一个BINLOG文件。

生产中我们使用Xtrabackup来产生一个 从实例 的流程如下:

拉取备份,进行还原

change master to

set @@global.gtid_purged=’xxx’;

set @@global.gtid_purged=’xxx’; 的影响:

将 从实例 的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

MySQL 5.7中set gtid_purged的行为变更

问题描述

回顾一下备份恢复的流程:

拉取备份,进行还原

change master to

set @@global.gtid_purged=’xxx’;

现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生 正确的Previous-GTIDs。

分析

分析整个过程,解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤:

手工还原备份

环境

BINLOG数量,Previous-GTIDs状态

Xtrabackup 2.4.2 & MySQL 5.6 1,空

Xtrabackup 2.4.2 & MySQL 5.7 1,空

Xtrabackup 2.2.9 & MySQL 5.6 1,空

Xtrabackup 2.2.9 & MySQL 5.7 1,空

可见: 恢复过程不会轮转BINLOG。

验证change master和set gtid_purged在不同的MySQL版本中执行的差异

环境

BINLOG数量,Previous-GTIDs状态

change master & MySQL 5.6 1,空

change master & MySQL 5.7 1,空

set gtid_purged & MySQL 5.6 2,正常

set gtid_purged & MySQL 5.7 1,空

可见: 执行set gtid_purged时不同版本的MySQL产生了差异

验证

对不同版本MySQL单独执行set @@global.gtid_purged=’’;语句。检查结果

环境

进行的操作

BINLOG数量,Previous-GTIDs状态

MySQL 5.7 reset master; set @@global.gtid_purged=”; 1,空

MySQL 5.6 reset master; set @@global.gtid_purged=”; 2,正常

结论

参考: http://bugs.mysql.com/bug.php?id=75767

官方解释: 在5.7版本中,执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged=’’;语句被改成只修改存放GTID的表。

而5.6版本中会进行BINLOG轮转和向Previous_gtids_log_event中添加GTID。如果5.7需要产生和5.6相同结果的话,可以在SET GTID_PURGED语句后手动执行flush binary logs语句。

发表评论

表情:
评论列表 (有 0 条评论,251人围观)

还没有评论,来说两句吧...

相关阅读

    相关 mysql 增量备份还原

    小量的数据库可以每天进行完整备份,因为这也用不了多少时间,但当数据库很大时,就不太可能每天进行一次完整备份了,这时候就可以使用增量备份。增量备份的原理就是使用了mysql的bi

    相关 mysql备份还原

    一、备份常用操作基本命令 1、备份命令mysqldump格式    格式:mysqldump -h主机名  -P端口 -u用户名 -p密码 –database 数

    相关 MySQL备份还原

    MySQL备份与还原 逻辑备份 > 逻辑备份为通过对数据库的操作导出数据文件,常用的逻辑备份有两种,一种是将数据转换为全量的INSERT语句,另一种是将数据以特定的

    相关 Mysql备份还原总结

    Mysql的备份与还原,是很重要、很常见的操作,这里总结一下。linux系统中Mysql备份还原,主要有三种方式:目录复制、转储sql语句方式、shell脚本、压缩方式、bin