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

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

部分备份：

[root@localhost 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，备份所有事物）

[root@localhost 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 @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@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 TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

完整备份：

[root@localhost 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';
以及完整的数据备份

[root@localhost 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 @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@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

root@localhost:mysql3307.sock [lyh1] >show slave status\G
*************************** 1. row ***************************
。。。。。Slave_IO_Running: YesSlave_SQL_Running: Yes
。。。。。Retrieved_Gtid_Set: 5adbcab4-fcbb-11e7-a900-000c29e774f1:349Executed_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

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

三星s7不能运行java_在调试模式下启动时Android应用程序崩溃
当我在 debug 模式下运行时,应用程序崩溃了,但是当我正常运行它时它会起作用 . 我认为附加调试器时会出现问题 . 日志: A/art: art/runtime/jdwp/jdwp_event.c ...
MySQL MGR 单主模式下单点故障时的节点角色切换规则
MGR单主模式下,有一个节点可读可写,其余节点都是只读,其中表现为super_read_only被自动设为了ON. 那么,如果可读可写的节点异常宕机了,会进行怎样的切换呢? 在选择新的可写角色时,主要 ...
桥接模式下如何访问光猫后台（小米路由器实验）
问题描述: 相信很多人将光猫改为桥接模式,使用路由器拨号后,发现不能再通过路由器访问光猫后台了. 本文以 Redmi AX5 路由器为例,解决此问题. 光猫LAN地址:192.168.1.1 /24 ...
mysql 5.6 gtid mha_MySQL MHA--故障切换模式(GTID模式和非GTID模式)
GTID和非GTID故障切换模式选择 MySQL 5.6版本引入GTID来解决主从切换时BINLOG位置点难定位的问题,MHA从0.56版本开始支持基于GTID的复制,在切换时可以采用GTID模式和非 ...
在线建立或重做mysql主从复制架构方法（传统模式和GTID模式）【转】
mysql主从复制架构,是mysql数据库主要特色之一,绝大多数公司都有用到. 而GTID模式是基于事务的复制模式的意思,发展到现在也是越来越多人用. 以前很多文章,介绍搭建mysql主从复制架构,是 ...
GTID 模式 - 通过跳过事务解决主从故障
文章目录一.前言二.操作流程 1. 获取最后一个 GTID 操作 2. 跳过一个事务三.案例 1. 问题描述 2. 原因分析 3. 处理过程一.前言很多场景下我们需要跳过一个事务来修复主从关 ...
MySQL——GTID模式应用及数据恢复
GTID介绍 GTID(Global Transaction Identifier)全局事务标识.由主库上生成的与事务绑定的唯一标识,这个标识不仅在主库上是唯一的,在MySQL集群内也是唯一的.GTI ...
第17周翻译：SQL Server中的事务日志管理的阶梯:第5级:在完全恢复模式下管理日志...
来源:http://www.sqlservercentral.com/articles/Stairway+Series/73785/ 作者:Tony Davis, 2012/01/27 翻译:刘琼滨. ...
SQL Server事务日志管理的阶梯，第5级:在完全恢复模式下管理日志
SQL Server事务日志管理的阶梯,第5级:在完全恢复模式下管理日志在本节中,我们将回顾在完全恢复模式下进行日志备份的原因和方法,以及如何使用这些日志备份文件与完整的数据库备份一起执行数据库恢复 ...

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

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

最新文章

热门文章