mysql gtid坑_通过mysqlbinlog --skip-gtids恢复后再备份可能造成的坑

最新推荐文章于 2023-03-28 18:33:08 发布
最新推荐文章于 2023-03-28 18:33:08 发布
阅读量688 收藏
点赞数
文章标签： mysql gtid坑
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_28848833/article/details/113327062
版权

版本

[root@uz22199 backup]# innobackupex --version

innobackupex version 2.4.8 Linux (x86_64) (revision id: 97330f7)

[root@uz22199 backup]# mysql -e"select @@version"

+------------+

| @@version |

+------------+

| 5.7.18-log |

+------------+

源库

表结构与数据

root@mysqldb 21:51: [fandb]> show create table users\G

***************************1. row ***************************

Table: users

Create Table: CREATE TABLE `users` (

`email` varchar(10) DEFAULT NULL,

UNIQUE KEY `email` (`email`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

1 row in set (0.00 sec)

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 | +-------+

插入一条数据

insert into users values(50); --GTID=1297

再删掉

delete from users where email=50; ----GTID=1298

当前Executed_Gtid_Set

root@mysqldb 18:35: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000005 | 495 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1298 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

源库再次应用一下已经执行过得binlog, 再次应用insert into users values(50); 这一条

这里先不考虑有没有可能这样子去恢复数据,只做实验

[root@test43100 backup]# mysqlbinlog --skip-gtids --include-gtids='5c351518-78ec-11e7-8e7a-005056a610c3:1297' mysql-bin.000005 |mysql

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 | +-------+

root@mysqldb 18:43: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000005 | 617 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

源库Executed_Gtid_Set 已经到1299了

备份

innobackupex --user=backup --password='backup' --stream=tar /tmp | gzip -> full.tar.gz

170907 18:45:15 Backup created in directory '/tmp/'

MySQL binlog position: filename 'mysql-bin.000005', position '617', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1299'

170907 18:45:15 [00] Streaming

170907 18:45:15 [00] ...done

170907 18:45:15 [00] Streaming

170907 18:45:15 [00] ...done

xtrabackup: Transaction log of lsn (3112759) to (3112768) was copied.

170907 18:45:16 completed OK!

从备份输出信息和xtrabackup_binlog_info都可以看到,这个全备备份了1-1299

[root@uz22199 full2]# more xtrabackup_binlog_info

mysql-bin.000005 617 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299

把备份随便搞到一个地方恢复出来

(恢复过程省略)

查看恢复出来的库的Executed_Gtid_Set

root@mysqldb 18:48: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1298 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

虽然知道1298,但是50这条数据有了

root@mysqldb 18:43: [fandb]> select* from users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 | +-------+

如果此时我们直接将该库作为从库,change master到源库,那么start slave会报错,1299会再执行一边insert 50,会报1062错误.这就是坑

而如果我们flush binary logs一次,再做全备

root@mysqldb 21:51: [fandb]> flush binary logs;

Query OK, 0 rows affected (0.19 sec)

root@mysqldb 21:59: [fandb]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000006 | 194 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

170907 22:00:58 Backup created in directory '/tmp/'

MySQL binlog position: filename 'mysql-bin.000006', position '194', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1299'

170907 22:00:58 [00] Streaming

170907 22:00:58 [00] ...done

170907 22:00:58 [00] Streaming

170907 22:00:58 [00] ...done

xtrabackup: Transaction log of lsn (3115326) to (3115335) was copied.

170907 22:00:58 completed OK!

[root@uz22199 full3]# more xtrabackup_binlog_info

mysql-bin.000006 194 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299

Executed_Gtid_Set依旧是1-1299

再次将备份恢复出来,查看新恢复出来的库

root@mysqldb 22:02: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1299 | +------------------+----------+--------------+------------------+---------------------------------------------+

此时恢复出来的库Executed_Gtid_Set为1-1299了

总结

那么要么以后通过mysqlbinlog –skip-gtids 恢复数据之后flush 一下binary logs;

要么恢复出来的库都手动根据xtrabackup_binlog_info去set global gtid_purged

又做了一次

源库:

root@mysqldb 17:14: [(none)]> flush binary logs;

Query OK, 0 rows affected (0.24 sec)

root@mysqldb 17:16: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 194 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1300 | +------------------+----------+--------------+------------------+---------------------------------------------+

root@mysqldb 17:17: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 | +-------+

7 rows in set (0.00 sec)

root@mysqldb 17:23: [(none)]> insert into fandb.users values(70);

Query OK, 1 row affected (0.06 sec)

root@mysqldb 17:23: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 448 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1301 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:24: [(none)]> delete from fandb.users where email=70;

Query OK, 1 row affected (0.05 sec)

root@mysqldb 17:24: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 702 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1302 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:24: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 | +-------+

7 rows in set (0.00 sec)

mysqlbinlog --skip-gtids --include-gtids='5c351518-78ec-11e7-8e7a-005056a610c3:1301' /data/mysqldata/3306/binlog/mysql-bin.000008 |mysql

root@mysqldb 17:26: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000008 | 956 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1303 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:26: [(none)]> select * from fandb.users order by 1;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 |

| 70 | +-------+

8 rows in set (0.00 sec)

innobackupex --user=backup --password='backup' --stream=tar /tmp | gzip -> full4.tar.gz

MySQL binlog position: filename 'mysql-bin.000008', position '956', GTID of the last change '5c351518-78ec-11e7-8e7a-005056a610c3:1-1303'

170908 17:27:42 [00] Streaming

170908 17:27:42 [00] ...done

170908 17:27:42 [00] Streaming

170908 17:27:42 [00] ...done

xtrabackup: Transaction log of lsn (3121237) to (3121246) was copied.

170908 17:27:42 completed OK!

[root@uz22199 full4]# more xtrabackup_binlog_info

mysql-bin.000008 956 5c351518-78ec-11e7-8e7a-005056a610c3:1-1303

[root@uz22199 full4]# more xtrabackup_binlog_pos_innodb mysql-bin.000008 956

恢复出来的库:

root@mysqldb 17:31: [(none)]> show master status;

+------------------+----------+--------------+------------------+---------------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+

| mysql-bin.000001 | 154 | | | 5c351518-78ec-11e7-8e7a-005056a610c3:1-1300 | +------------------+----------+--------------+------------------+---------------------------------------------+

1 row in set (0.00 sec)

root@mysqldb 17:31: [(none)]> select * from fandb.users;

+-------+

| email | +-------+

| 1 |

| 10 |

| 20 |

| 30 |

| 5 |

| 50 |

| 60 |

| 70 | +-------+

8 rows in set (0.00 sec)

root@mysqldb 17:37: [(none)]> reset slave all;

Query OK, 0 rows affected (0.03 sec)

root@mysqldb 17:38: [(none)]> change master to master_host='10.4.3.100',master_port=3306,master_user='repl',master_password='repl',master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.26 sec)

root@mysqldb 17:38: [(none)]> start slave;

Last_SQL_Error: Could not execute Write_rows event on table fandb.users; Duplicate entry '70' for key 'email', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000008, end_log_pos 417

萌萌哒的黄桃
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysqlbinlog数据恢复，--skip-gtids=true
weixin_40524659的博客
05-04 2803
mysqlbinlog工作中最常用的功能可能就是解析binlog了，写成脚本，一次可以解析多个，今天玩玩mysqlbinlog恢复数据的用法. 1，单个binlog恢复数据。 先看看test库下t1表的数据情景，不小心误删数据。 现在使用mysqlbinlog工具试着恢复数据： 首先确认目前写的binlog是mysql-bin.000001 恢复过程： 首先分析应该恢...
MySQL--Skip GTID CAP
weixin_34227447的博客
07-10 81
import os script_file = "./skip_file.sql" def write_script(script_content): file_handle = open(script_file, 'a+') file_handle.writelines(script_content + "\n") file_handle.clo...
Mysql GTID模式下跳过错误
yygr的博客
05-09 1356
https://www.jianshu.com/p/2aed9584c80c GTID（全局事务标示符） 最初由google实现，在MySQL 5.6中引入。GTID在事务提交时生成，由UUID和事务ID组成。UUID会在第一次启动MySQL时生成，保存在数据目录下的auto.cnf文件里,事务id则从1开始自增。使用GTID的好处主要有两点： 不再需要指定传统复制中的 master_log_files和master_log_pos，使主从复制更简单可靠 可以实现基于库的多线程复制，减小主从复制的延
MySQL 5.7 GTID模式下 skip 1032 Error
digou7109的博客
09-29 676
一个偶然的事情，线上一部MySQL slave 被人误删了数据，然后又在 master上执行了同样的 delete 操作，导致从库报了1032错误。 其实这种情况下，如果能将缺少的记录重新insert 进去，再 start slave就可以完美解决； 问题在于不知道他具体操作了什么数据，所以想直接跳过这个事务。 脑海里回想了下GTID模式下跳过1032 的步骤，大概步骤是: my...
通过mysqlbinlog --skip-gtids恢复后再备份可能造成的坑
FaN()
09-11 4277
通过mysqlbinlog –skip-gtids恢复后再备份可能造成的坑版本[root@uz22199 backup]# innobackupex --version innobackupex version 2.4.8 Linux (x86_64) (revision id: 97330f7) [root@uz22199 backup]# mysql -e"select @@version" +
mysql-5.7.34-1.el7.x86_64.rpm-bundle.zip
07-19
MySQL 5.7.34 是一个非常重要的数据库管理系统版本，尤其对于那些依赖于高性能、高可用性和数据安全性的企业而言。此版本的 RPM 包是专为 CentOS 7 操作系统设计的，x86_64 架构表明它是为64位系统编译的。RPM（Red ...
mysql-5.7.28-linux-glibc2.12-x86_64.tar.gz
02-24
5. **复制功能升级**：MySQL 5.7的复制功能更加先进，包括GTID（Global Transaction Identifier）全局事务ID，实现了无主次服务器的概念，简化了故障转移和恢复过程。 6. **分区表改进**：分区表的性能和可用性得到...
mysql-8.0.27-macos11-x86_64.tar.gz
11-18
1. **增强的性能**：MySQL 8.0通过优化查询执行和存储引擎，提供了更快的数据检索速度。InnoDB存储引擎的改进，如更好的索引压缩和并行查询处理，显著提高了性能。 2. **窗口函数**：MySQL 8.0引入了SQL标准的窗口...
MySQL Community Server 8.0.27（mysql-8.0.27-macos11-x86_64.dmg）
11-18
MySQL Community Server 8.0.27 是 MySQL 数据库管理系统的一个重要版本，专为 macOS 11 平台设计，支持 x86 架构的 64 位系统。这款软件是开源的，允许用户自由下载、使用和分发，是开发、测试和部署数据库应用的...
mysql-5.6.38-linux-glibc2.12-x86_64.tar.gz
06-14
在解压这个压缩包后，你将得到一个名为"mysql-5.6.38-linux-glibc2.12-x86_64"的目录，其中包含了MySQL服务器的所有组件和配置文件。安装过程通常包括设置环境变量、初始化数据目录、配置服务器选项，以及启动服务。...
基于gtid的备份_恢复_注意事项_mysqldump_skip-gtids_include-gtids_exclude-gtids
最新发布
细致-专业-实操
03-28 890
是否使用–skip-gtids=true 参数，要根据情况来定；第一种情况：如果我们是要恢复数据到源数据库或者和源数据库有相同 GTID 信息的实例，则使用mysqlbinlog进行导出时候，需要使用该参数。如果不带该参数的话，是无法恢复成功的。因为包含的 GTID 已经在源数据库执行过了，根据 GTID 特性，一个 GTID 信息在一个数据库只能执行一次，所以不会恢复成功。
mysqlbinlog 使用
{'name':'hqman','type':'宅男'}
09-23 169
1:先确定 打开binlog   log_bin = /var/log/mysql/mysql-bin.log binlog_do_db           = include_database_name     2: shell>mysqlbinlog mysql-bin.000027   3: ./mysqlbinlog  --database="database" --socket=/...
常见数据库备份方式：MySQLbinlog数据恢复详解
weixin_50205273的博客
01-10 291
数据备份有哪些种？# MySQL中数据备份的方式还是蛮多的，常见的有冷备份、逻辑备份、热备份、快照备份。 什么是冷备份？ 所谓的冷备份，说白了就是在数据库停止运行的情况下，直接备份磁盘中MySQL用来存储数据的那些数据文件。 在前面的文章中，白日梦跟大家分享过MySQL的表空间。看过那篇文章的同学都是知道，MySQL中的数据最终都存储在表空间中的。表空间 == 表空间文件。其实而所谓的空间，本质上对应着存在于操作系统磁盘上的肉眼能看到的物理文件。 下面你可以看一下我的MySQL的表空间文件都是怎么
mysql-mysqlbinlog的使用详解
line_on_database的博客
04-17 1万+
一、背景 最近总在学习新知识，担心老的知识不用会忘，所以梳理一下，新欢旧爱都要宠着 二、介绍 1.参数简介 Option Name Description Introduced Deprecated --base64-output Print binary log entries using base-64 encoding --bind-address Use specified network interface to connec...
mysql5.7数据库的两种备份方式（mysqldump，XBK）超详细
热门推荐
关于自己学习笔记哟
12-11 1万+
mysqldump 时间错恢复 和GTID恢复 XBK 工具 物理备份
MySQL备份与恢复
Haibolun的博客
08-08 628
MySQL备份与恢复
GTID介绍和功能
sjsjshhs134654的博客
02-27 159
指定要截取哪些范围的数据（截取6和8的数据）：--include-gtids='92289477-445d-11eb-a0dc---skip-gtids //作用:在导出时,忽略原有的gtid信息,恢复时生成最新的gtid信息。--skip-gtids 作用：在导出时,忽略原有的gtid信息,恢复时生成最新的gtid信息。如果拿有GTID的日志去恢复时，检查当前系统中是否有相同GTID号，有相同的就自动跳过。#vim /etc/my.cnf //在[mysqld]中加。会影响到binlog恢复和主从复制。
《童虎学习笔记》11分钟学会MySQL基于时间点的恢复(gtid方式)
tonghu_note的博客
05-01 1707
1
binlog解析技巧
easydb.net
07-08 2896
MySQL binlog解析技巧
MySQL 5.6 OCP 1Z0-883：解决 Slave 错误与重置GTID策略
然后在修复了表结构后，可以执行其中一个GTID相关的语句（如E选项），接着再执行`START SLAVE`来继续复制。 总结来说，这道题目主要考察考生对MySQL主从复制、事务处理以及解决主键冲突的理解，同时测试他们在实际...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值