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

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						   #开启GITID
enforce-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日志路径
  • include-gtids:截取那些GTID号产生的Binlog日志,可以是一个,也可以是多个连续的GTID号,例如我们想截取6/7/8/9/10/11这5个GTID产生的Binlog,在include-gtids参数中无需填写多个完整的GTID,直接写范围即可,如:e0a2c0cc-f835-11ec-8a3c-005056b791aa:6-11,如果6-11这5个GTID中7/8是不想截取的GTID,那么还可以通过

  • --exclude-gtids:在截取过程中排除那些不想截取的GTID产生的binlog日志,接着include-gtids后续举例,如果6-11这5个GTID中,7/8这两个GTID是不想截取的,可能包含误删除操作,那么就可以通过--exclude-gtids参数将7和8两个GTID排除,在--exclude-gtids参数中如是连续排序的多个GTID,那么也可以写成e0a2c0cc-f835-11ec-8a3c-005056b791aa:7-8这种形式,如果是不连续的几个GTID,在排除时只能一个一个指定了。

例子:

  • 截取9-15这些GTID,但是排除11-13这三个GTID。

    mysqlbinlog --include-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:9-15' --exclude-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:11-13' /data/mysql/mysql-bin.000006
    
  • 截取9-15这些GTID,排除9/11这两个GTID。

    mysqlbinlog --include-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:9-15' --exclude-gtids='e0a2c0cc-f835-11ec-8a3c-005056b791aa:9,e0a2c0cc-f835-11ec-8a3c-005056b791aa:11' /data/mysql/mysql-bin.000006
    

4.2.模拟误删除的场景

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

1.创建table_1表
mysql> use db_3
mysql> 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日志记录,避免还原时又写一遍Binlog
mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

2.恢复数据
mysql> source /root/backup/gtids-binlog.sql

3.查看数据是否恢复成功
mysql> select * from table_1;
+------+---------+
| id   | name    |
+------+---------+
|    1 | huabf   |
|    2 | jiangxl |
|    3 | haha    |
|    4 | ooo     |
+------+---------+
#四条数据均已恢复

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>