暂无图片
暂无图片
10
暂无图片
暂无图片
暂无图片

MySQL-GTID和mysqldump中set-gtid-purged到底干了什么

原创 1727 2023-06-09
1581

Snipaste_20231227_093623.png

先来说说mysql中GTID是什么?

请看几个概念

1、mysql在5.6.6中引入了gtid

2、GTID(Global Transaction ID)是全局事务ID,在整个集群中是唯一的

3、GTID实际上是由UUID+TID组成
示例:8cbe8fb4-8e2f-11ec-8d44-00163e16c857:1

那么为什么要有GTID?

其实也就是在没有GTID时有哪些痛点

1、在主从复制中,尤其时半同步复制中,由于master的dump进程一边要发送binlog给slave,一边要等ACK消息,这个过程时串行的,极大影响性能。有了GTID,slave可以直接通过数据流获得GTID信息,并基于逻辑时钟并行回放数据。

2、有了GTID后,slave就不需要一直保存binlog文件名和position,在主从故障切换时直接以GTID为准判断就行了

3、当master crash的时候,GTID有助于保证数据的一致性,因为每个事务都对应唯一GTID,如果在恢复的时候某事务被重复提交,slave会直接忽略。

再来说说GTID的优点

其实从mysql5.7开始,在mysql主从复制中就默认开启GTID模式了

1、简单的实现failover,不用以前那样需要找log_file和log_pos

2、比传统复制更加安全,一个GTID在一个实例中只执行一次,避免重复数据导致主从不一致

#这点相信经历过5.6mysql集群的同学都深有体会,在5.6中主从数据不一致那是常有的事

3、GTID的引入,让每一个事务在集群事务的海洋中有了秩序,使得DBA在运维中做集群变迁时更加方便

最后,每个实例上保存的GTID可能是有很多的

可以通过命令查看

show master status;
或
select * from mysql.gtid_executed;

一个实例中保存了多个GTID信息的原因也很简单,例如从库,他既要保存主库的日志信息,也要保存自己的日志信息。

那么mysqldump时–set-gtid-purged参数到底有什么意义呢

直接分别dump一下看看效果

mysqldump -uxx -pxx -hxxx A a --set-gtid-purged=on > /tmp/t1.sql
----------
mysqldump -uxx -pxx -hxxx A a --set-gtid-purged=off > /tmp/t2.sql

对比导出的两个sql,该参数=on时比=off时多了如下内容

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;

SET @@SESSION.SQL_LOG_BIN= 0;

SET @@GLOBAL.GTID_PURGED=/!80000 ‘+’/ '5029caee-6240-11ea-a39a-00163e0e18ce:1-40068974878

SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

这段多出来的sql实现的内容很简单
就两点

1、整个sql导入实例时,不会产生binlog
2、导入实例会记录导出实例目前全部产生的gtid事务号

翻译翻译就是

当–set-gtid-purged=off时:导入数据就相当于直接手撸了sql,正常记录binlog,也没有其他任何影响。

当–set-gtid-purged=on时:导入的这段数据不会记录binlog,但是会记录导出数据库目前所产生的gtid信息;影响就是导入库无法再同步导出库的历史数据,因为GTID的幂等性,上面讲过GTID重复时会直接忽略。

再用几个场景来说一下什么情况下用on\off

#场景一:

已经构建好了主从,此时从某个实例mysqldump数据导入到该主从中。

那么set-gtid-purged=off,因为导入主从时主库必须记录日志,这样才能同步到下游的从库

#场景二:

只有一个主节点,想mysqldump全量后构建主从

那么set-gtid-purged=on,因为你新的从库必须知道目前全量的数据是在主库的哪个位置点(就是上面提到set @@xxx那些),这样才可以进行后续的增量同步

#场景三:

两个不相关实例间同步,例如线上到测试,数据迁移等

建议set-gtid-purged=off,因为新来的数据和原来的实例没有任何关系,新库需要记录自己的日志。
当然这种场景set-gtid-purged=on也没有问题,只是在下次dump导入时需要先执行reset master;
--------------
注意!!!!
reset master谨慎执行,他会直接重置binlog位置点。
如果你在一个mysql集群中执行了reset master就可以准备跑路了,其灾难程度不亚于勿删库!!!
总结

非构建主从的情况就简简单单用–set-gtid-purged=off就可以了,花里胡哨整–set-gtid-purged=on可能会画蛇添足。

最后修改时间:2023-12-27 10:31:02
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论