文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

第80讲:GTID全局事务标识符的基本概念以及在Binlog中应用GTID

2023-12-23 11:33

关注

1.GTID的基本概念

1.1.为什么要引入GTID

对于误删除操作进行数据恢复,是从Binlog日志中根据事件的开始标识位号和结束标识位号,截取需要的Binlog日志,然后进行数据恢复,在Binlog中查找想要恢复的数据对应的事件开始和结束标识位,一条SQL可能就包含一个开始/结束标识位号,查找开始/结束标识位是非常麻烦的一个过程。

还有一个场景:当我们想要恢复的数据对应的事件,位于开始位200到结束位3000之间的数据,在这个标识位范围内如果还包含了多次DELETE误删除的语句,这时我们不想截取DELETE语句产生的SQL,避免数据恢复的不完整,那么此时还用老办法截取日志就非常麻烦,我们还需要一个个的找出DELETE语句对应的事件,在这个事件之前进行截取,如果少量的DELETE还好,如果发生了多次DELETE的误删除,此时还利用标识位在Binlog中还原数据将会非常复杂。

基于这种场景,通过事件的开始结束标识位号截取Binlog日志非常复杂,MySQL从5.6版本开始加了一个新的特性,也就是GTID,GTID在MySQL主从复制中会使用到,通过GTID来解决此问题。

1.2.什么是GTID

GTID的全称为全局事务标识符(global transaction identifiner),是MySQL5.6版本中引入的新特性,并且在MySQL5.7版本中进行了加强,在MySQL5.7版本中,GTID即使不开启也会有自动生成。

GTID可以保证MySQL数据库中的每一个事务都有一个全局唯一的标识号,这个标识号在当前MySQL实例,甚至是MySQL主从复制集群中都会保证是全局唯一的标识号,从而保证数据的一致性。

在GTID中,DDL、DCL每一条语句(事件)都会被当成一个事务,并且会拥有一个GTID号。DML语句的每一个完整的事务,都会占用一个GTID号。

GTID开启后,会在Binlog中针对每一个事务增加一个GTID号,我们可以根据这个GTID号去截取Binlog数据。

当Binlog中增加了GTID后,我们就不需要再通过事件的开始/结束标识位号去截取某个范围的Binlog日志,我们可以直接通过GTID号来截取想要的事务操作的数据,并且mysqlbinlog中还有参数可以排除不想截取的GTID号,当多个事务标识号GTID中有误删除的操作时,我们不想截取删除的操作,此时可以在截取日志时排除对应事务的GTID号,保障截取的Binlog都是我们需要的日志内容。

GTID的定义如下:

GTID = server_uuid:transaction_id例如e0a2c0cc-f835-11ec-8a3c-005056b791aa:27

server_uuid也就是当前实例的UUID号,32字节+1字节的字符串,在MySQL第一次启动时会生成这个UUID,并将这个UUID会保存在数据目录中的auto.conf文件中,如果该配置文件丢失,MySQL会重新生成一个UUID,相同server uuid中的事务对应的transaction_id(全局事务唯一ID)在Binlog日志中是自增并且连续有序的。

[root@mysql ~]# cat /data/mysql/auto.cnf [auto]server-uuid=e0a2c0cc-f835-11ec-8a3c-005056b791aa或者mysql> system cat /data/mysql/auto.cnf[auto]server-uuid=e0a2c0cc-f835-11ec-8a3c-005056b791aa

2.开启GTID全局事务标识符的功能

GTID全局事务标识符的功能默认是没有开启的,但是在MySQL5.7版本中会有地方字自动生成GTID。

1.开启GTID[root@mysql ~]# vim /etc/my.cnf [mysqld]gtid-mode=on   #开启GITIDenforce-gtid-consistency=true#强制GTID的一致性2.重启mysql[root@mysql ~]# systemctl restart mysqld

3.模拟产生Binlog日志观察开启GTID功能的区别

下面我们来模拟产生Binlog日志,然后观察开启GTID功能前后,在Binlog中会有什么变化。

当前的Binlog记录格式是MIXED类型,俗称MBR。

image-20220701232614534

3.1.模拟产生Binlog日志

开启GTID后,DDL、DCL语句都会被当做一个事务,并且会分配唯一的GTID号,DML每一个完整的事务也都会分配一个GTID号。

由于刚刚开启GTID时重启了MySQL,后面再执行SQL时就会写入到新的Binlog日志文件中,执行以下操作产生新的Binlog日志。

1.创建db_3数据库mysql> create database db_3;2.在db_3数据库中创建一张表mysql> use db_3;mysql> create table table_1 (id int,name varchar(10));3.在表中插入数据、删除数据、再插入数据mysql> insert into table_1 values (1,'huabf');mysql> insert into table_1 values (2,'jiangxl');mysql> insert into table_1 values (3,'haha');mysql> delete from table_1 where id = 3;mysql> insert into table_1 values (4,'ooo');

3.2.观察Binlog日志中的事件信息

产生Binlog日志之后,在Binlog日志的事件信息中,每一个DDL语句都被看成一个事务,会产生一个GTID,每一个DML的事务也会产生一个GTID号。

此时查看Binlog日志的事件信息时,就不需要再看事件的开始/结束标识位号,只需要分析Binlog中产生的全局事务ID即可,主要看Info一列,无论是DDL语句还是DML语句,都会产生一个事务,并且都有独立的GTID号。

之前找事件的开始/结束标识位非常麻烦,每一条SQL都对应一个开始/结束标识位,比较庞大,当使用GTID后,一个事务内的SQL拥有一个GTID,同时可以清晰的看到一个GTID下包含了那些数据的SQL语句,截取时按照需求,指定数据所在的GTID范围即可成功截取。

由于我的Binlog记录格式是MBR,因此针对DML语句可以清晰的看到具体的SQL,当我们要截取部分Binlog日志时,只需要在Binlog中找到要恢复数据对应的SQL语句,然后再找到这些SQL语句对应的GTID号,根据GTID号进行截取即可。

mysql> show binlog events in 'mysql-bin.000004';

事件信息如下,就如我们所说的那样,每一个DDL语句都被看做是一个事务,并且分配唯一的GTID号,每一个DML语句的完整事务也都会分为一个唯一的GTID号,GTID号的定义也是节点的UUID加全局事务ID号组成的,GTID号会按照顺序自增。

image-20220701234356734

3.2.观察节点状态有什么变化

mysql> show master status;

在查看节点状态时,除了能看到当前正在使用的Binlog日志是哪个外,在最后一列Executed_Gtid_Set中简单的展示了当前MySQL数据库中有多少个GTID号。

e0a2c0cc-f835-11ec-8a3c-005056b791aa:当前MySQL的UUID号。

1-7:这个1-7表示,当前MySQL中一共有一个GTID号,从1开始到7结束(我们使用GTID截取Binlog日志时,就可以使用这种连续的方法截取出连续DGTID事务所产生的Binlog日志)。

image-20220701234934592

3.3.观察Binlog日志会有什么变化

Binlog日志也会有明显的变化,当使用GTID之后,几乎就可以不去看事件的开始/结束标识位了,如下图所示,一个事务就对应一个GTID号,在这个GTID内,可能会包含多条SQL语句,当我们需要截取部分Binlog时,根据我们的需求,分析要截取的部分位于那些GTID中,然后根据涉及的GTID范围进行截取即可。

image-20220701235726077

4.使用GTID来截取Binlog中部分日志

当Binlog中具备GTID之后,就可以通过GTID来截取某些事务的BInlog日志。

4.1.使用GTID来截取Binlog日志的方法

语法格式如下:

mysqlbinlog --include-gtids='GTID号范围' --exclude-gtids='排除不截取的GTID号' Binlog日志路径

例子:

4.2.模拟误删除的场景

下面我们来模拟误删除的场景,首先创建一张表,再里面正常插入数据,然后误删除一条数据,最后误删除整张表。

1.创建table_1表mysql> use db_3mysql> create table table_1 (id int,name varchar(10));2.正常插入的数据mysql> insert into table_1 values (1,'huabf');mysql> insert into table_1 values (2,'jiangxl');mysql> insert into table_1 values (3,'haha');3.误删除了id为3的数据mysql> delete from table_1 where id = 3;4.又正常插入了id为4的数据mysql> insert into table_1 values (4,'ooo');5.又误删除了整张表mysql> drop table table_1;

4.3.使用GTID来截取要恢复的Binlog日志

table_1这张表一下有两次误操作行为了,我们需要通过Binlog日志来恢复误删除的数据。

1)首先查看当前数据库使用的是哪个Binlog日志

使用的是mysql-bin.000006这个Binlog日志。

mysql> show master status;+------------------+----------+--------------+------------------+-------------------------------------------+| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |+------------------+----------+--------------+------------------+-------------------------------------------+| mysql-bin.000006 |     1992 |              |                  | e0a2c0cc-f835-11ec-8a3c-005056b791aa:1-15 |+------------------+----------+--------------+------------------+-------------------------------------------+

2)确定要截取Binlog日志的那些GTID号

通过事件信息,来确定我们要还原那些GTID产生的Binlog数据。

mysql> show binlog events in 'mysql-bin.000006';

我们首先找到创建table_1这张表的事务GTID号,找到之后,就是从这个GTID号处开始截取,如下图所示,创建这张表的GTID是9,然后一直找到删除这张表的GTID号,如下图所示,删除表的GTID是15,那么截取GTID号的范围就是9-15之间,但是在9-15之间又包含了误删除的操作,如果我们不排除掉,那么恢复之后数据还是丢失的,DELETE误删除的操作为13GTID号中,DROP删除表的误操作行为位于15这个GTID号,因此我们就可以确定要截取的GTID号范围是9-15,但是在截取过程中排除掉13和15这两个GTID号。

这里为什么要一直找到删除表的GTID呢?因为我们不能确定在删除表之前那条数据时该表最后的写入数据,因此到删除表的GTID是最全面的,截取的时候排除掉这些删除行为的GTID就可以了。

image-20220702091733100

3)截取日志

截取9-15这6个GTID产生的Binlog日志,然后排除掉13/15这两个GTID产生的Binlog日志,最后输出到SQL文件里。

[root@mysql backup]# mysqlbinlog --include-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:9-15' --exclude-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:13,e0a2c0cc-f835-11ec-8a3c-005056b791aa:15' /data/mysql/mysql-bin.000006 > gtid-binlog.sql

成功截取了9-15这些GTID产生的Binlog,但是同时也排除了13和15这两个GTID产生的数据。

image-20220702092956846

虽然我们成功的截取到了要恢复的Binlog日志,但是此时拿着这个日志去还原数据会报错,这就要说说GTID的幂等性问题了。

4.4.GTID的幂等性问题

虽然在4.3中用GTID截取除了Binlog日志,也输出到SQL文件中了,但是此时如果使用这个Binlog去恢复数据,那么就会报错,会提示还原的数据中有指定的GTID号,和当前数据库的GTID冲突,重复的GTID对应的事务就不会执行了,这就是GTID的幂等性问题。

当我们开启了GTID,还使用事件的标识位截取Binlog时,也会遇到此问题。

如何解决这个问题呢?其实也很简单,只需要将截取的Binlog日志中关于GTID声明的语句剔除就可以了。

image-20220702094949719

手动删除可能会漏,mysqlbinlog的--skip-gtids参数可以跳过Binlog日志中的GTID属性,跳过后我们就可以正常恢复数据了。

[root@mysql backup]# mysqlbinlog --skip-gtids --include-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:9-15' --exclude-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:13,e0a2c0cc-f835-11ec-8a3c-005056b791aa:15' /data/mysql/mysql-bin.000006 > gtids-binlog.sql

跳过GTID属性的Binlog日志和原Binlog日志是由很大区别的,因此不建议手动的改,直接通过--skip-gtids参数跳过即可。

image-20220702095142476

4.5.利用GTID截取的Binlog还原误删除的数据。

1.临时关闭Binlog日志记录,避免还原时又写一遍Binlogmysql> set sql_log_bin=0;Query OK, 0 rows affected (0.00 sec)2.恢复数据mysql> source /root/backup/gtids-binlog.sql3.查看数据是否恢复成功mysql> select * from table_1;+------+---------+| id   | name    |+------+---------+|    1 | huabf   ||    2 | jiangxl ||    3 | haha    ||    4 | ooo     |+------+---------+#四条数据均已恢复

来源地址:https://blog.csdn.net/weixin_44953658/article/details/135099985

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯