关于GTID模式下备份时 --set-gtid-purged=OFF 参数的实验【转】

刚刚听了吴老师是复制章节课程，对于GTID模式下备份数据--set-gtid-purged=OFF 参数有些不理解，于是乎做了实验，加深理解，得出些结论，如有错漏请批评指正！

部分备份：

[[email protected] mysql]# /usr/local/mysql/bin/mysqldump -uroot -p -S /data/mysql3306/data/mysql3306.sock lyh2 >/home/backup/lyh2-3306-`date +%Y%d%m`.sql
Enter password:
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don‘t want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

检查部分备份文件内容：
出现了SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-347‘;
同时，备份的是指定库（没有像我猜想的会按照全局GTID，备份所有事物）

[[email protected] mysql]# less /home/backup/lyh2-3306-20182802.sql
 -- MySQL dump 10.13 Distrib 5.7.19, for linux-glibc2.12 (x86_64)
--
-- Host: localhost   Database: lyh2
-- ------------------------------------------------------
-- Server version       5.7.19-log
/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE=‘+00:00‘ */;
/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE=‘NO_AUTO_VALUE_ON_ZERO‘ */;
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-347‘;
--
-- Table structure for table `tb2`
--
DROP TABLE IF EXISTS `tb2`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `tb2` (
`id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `tb2`
--
LOCK TABLES `tb2` WRITE;
/*!40000 ALTER TABLE `tb2` DISABLE KEYS */;
INSERT INTO `tb2` VALUES (1);
/*!40000 ALTER TABLE `tb2` ENABLE KEYS */;
UNLOCK TABLES;
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
/*!40103 SET [email protected]_TIME_ZONE */;
/*!40101 SET [email protected]_SQL_MODE */;
/*!40014 SET [email protected]_FOREIGN_KEY_CHECKS */;
/*!40014 SET [email protected]_UNIQUE_CHECKS */;
/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;
/*!40101 SET [email protected]_COLLATION_CONNECTION */;
/*!40111 SET [email protected]_SQL_NOTES */;

完整备份：

[[email protected] mysql]# /usr/local/mysql/bin/mysqldump -uroot -p -S /data/mysql3306/data/mysql3306.sock -A --master-data=2 --single-transaction >/home/backup/full-3306-`date +%Y%d%m`.sql
Enter password:
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don‘t want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

检查完整备份文件内容：
依然出现了SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-347‘;
以及完整的数据备份

[[email protected] mysql]# less /home/backup/full-3306-20182802.sql
-- MySQL dump 10.13 Distrib 5.7.19, for linux-glibc2.12 (x86_64)
--
-- Host: localhost   Database:
-- ------------------------------------------------------
-- Server version       5.7.19-log
/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE=‘+00:00‘ */;
/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE=‘NO_AUTO_VALUE_ON_ZERO‘ */;
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-347‘;
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000006‘, MASTER_LOG_POS=29189664;
--
-- Current Database: `lyh1`
--
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `lyh1` /*!40100 DEFAULT CHARACTER SET utf8 */;
USE `lyh1`;
--
-- Table structure for table `t1`
--
DROP TABLE IF EXISTS `t1`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
省略。。。。。

综上，无论是完整备份，还是部分备份，如果不设置 --set-gtid-purged=OFF 这个参数，最终的备份文件中会有这样一句话：SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-347‘;
这个的区间是主库中当前所完成的所有事务号。这条语句在备份被恢复的时候，起到的作用是，不再从主库同步1-347 这个范围内的事务了。
如果我们是部分备份，我们不应该阻止从库同步1-347全部区间的数据。因此部分备份是加上--set-gtid-purged=OFF 这句，不强行指定跳过这些操作。
 
根据上面实验可以看出，SET @@GLOBAL.GTID_PURGED 可以在从库指定跳过任何事物
那么，如果在从库恢复完数据备份，
SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-348‘;  
指定到任意位置，如348，那么从库就会跳过348号以及以前的所有事物，认为已经同步完成。并且在show slave status 完全看不出空洞。
 
 
本例中从库只恢复到1-347号事务，没有开启同步时，主库执行了348，349号事务，由于从库设置了
SET @@GLOBAL.GTID_PURGED=‘5adbcab4-fcbb-11e7-a900-000c29e774f1:1-348‘;  
从库再开启复制时，从库直接从349号事务开始同步，跳过348号事务，于是348号事务完美的丢失了，没有痕迹。
在从库show slave status

[email protected]:mysql3307.sock [lyh1] >show slave status\G
*************************** 1. row ***************************
。。。。。
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
。。。。。
           Retrieved_Gtid_Set: 5adbcab4-fcbb-11e7-a900-000c29e774f1:349
            Executed_Gtid_Set: 5adbcab4-fcbb-11e7-a900-000c29e774f1:1-349

通过
show master status;  记录已执行的事务号
reset master;
SET @@GLOBAL.GTID_PURGED=‘已执行的事务号‘;  
可以设置多源复制

转自

关于GTID模式下备份时 --set-gtid-purged=OFF 参数的实验 - FireFly Club
http://q.fireflyclub.org/?/question/65

原文地址：https://www.cnblogs.com/paul8339/p/9359770.html

时间： 2024-10-29 03:54:45

关于GTID模式下备份时 --set-gtid-purged=OFF 参数的实验【转】的相关文章

MySQL 5.7 GTID模式下 skip 1032 Error

一个偶然的事情,线上一部MySQL slave 被人误删了数据,然后又在 master上执行了同样的 delete 操作,导致从库报了1032错误. 其实这种情况下,如果能将缺少的记录重新insert 进去,再 start slave就可以完美解决: 问题在于不知道他具体操作了什么数据,所以想直接跳过这个事务. 脑海里回想了下GTID模式下跳过1032 的步骤,大概步骤是: mysql> SET @@SESSION.GTID_NEXT= '4ab8feff-5272-11e8-9320-0800

GTID模式下的replication，跳过错误日志的解决方法

日志错误: 大多数replication错误都是因为日志错误引起的. 主日志和中继日志都可能出错. 评判日志错误的辨别方法: mysqlbinlog  master_binlog_file > /dev/null   屏幕有输出则表示这个binlog有错误,如果没有则表示binlog正常. mysqlbinlog  slave_binlog_file  >/dev/null 跳过日志错误1: 可以使用手动跳过日志错误,可能会造成数据不一致 如果主日志出错,可以再slave上执行(如果有多个错误

[Selenium]Grid模式下运行时打印出当前Case在哪台node机器上运行

当Case在本地运行成功,在Grid模式下运行失败时,我们需要在Grid模式下进行调试,同时登录远程的node去查看运行的情况. Hub是随机将case分配到某台node上运行的,怎样知道当前的case是运行在哪台node上呢? 可以通过这段代码获取node的信息: public void getComputerNameOfNode(WebDriver driver){ String hub = "SZAUTOTEST1"; int port = 4444; HttpClientBui

MySQL MHA--故障切换模式(GTID模式和非GTID模式)

GTID和非GTID故障切换模式选择 MySQL 5.6版本引入GTID来解决主从切换时BINLOG位置点难定位的问题,MHA从0.56版本开始支持基于GTID的复制,在切换时可以采用GTID模式和非GTID模式两种模式进行切换,如何在发生故障切换时如何判断采用哪种切换方式呢? 在MHA/MasterFailover.pm的do_master_failover方法中定义了"主库宕机"情况下的故障切换流程,其中第一步就是检查配置文件和确定故障切换模式 相关代码: my ( $server

不停应用服务,在线建立或重做mysql主从复制的案例,包含一般模式和GTID模式

mysql主从嘛,绝大多数公司都有用到,GTID发展到现在也是越来越多人用,停止应用服务来做主从,略显low了,现在都流行在线做,不影响业务,多实际是吧,不啰嗦了,现在就来看看案例. 先说明,案例分两种方案,实现的意义是一样的,一种是mysqldump方式,一种是xtrabackup方式,视乎实际情况,因为有些业务不一定能用xtrabackup的. 先说mysqldump方式, 因为mysql自带,不需要再做些什么,比较方便易用,不过需要强调一下,数据量太大的话,mysqldump就略显不足了,

（2.6）备份与还原--在简单恢复模式下事务日志的角色

简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如"简单"这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先要了解SQL Server提供的几种不同备份类型. SQL Server提供的几种备份类型 SQL Server所提供的几种备份类型基本可以分为以下三种(文件和文件组备份以及部分备份不在本文讨论之列): 1.完整(Full)备份:直接将所备份的数据的所有区(Extent)

在线修改GTID模式

在线修改GTID模式 1. 在每一台机器上执行命令 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN; 这是很重要的一步,必须确保服务器上没有违反GTID规范的SQL,否则当设置为GTID模式后, 这些业务SQL会被拒绝执行,建议设置上面变量值间隔一天后errorLog没有警告,才可进行下一步. 2. 在每一台服务器上执行 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; 上面参数表示GTID模式下一些SQL会被拒绝执

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 本篇文章是系列文章中的第三篇,前两篇的地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先

Oracle用户管理模式的备份恢复_超越OCP精通Oracle视频教程培训16

oracle视频教程目标 Oracle视频教程,风哥本套oracle教程培训学习oracle数据库用户管理的备份与恢复,归档模式与非归档模式,闪回恢复区,冷备份,热备份,dbverify工具的详解,如何完全恢复丢失的所有数据文件,基于时间点/取消/SCN的不完全恢复案例,归档日志的损坏,联机日志文件的损坏,数据文件无备份的恢复等日常管理与维护. 适用人群 IT相关从业人员.Oracle数据库技术人员.想加工资的.想升职的都可以. 视频在线学习地址: http://edu.51cto.com/co