MySQL Bugs: #107474: Missing 'SET @@GLOBAL.GTID

Bug #107474	Missing 'SET @@GLOBAL.GTID_PURGED' inside the dump file
Submitted:	3 Jun 2022 4:28	Modified:	4 Jun 2022 21:06
Reporter:	Ashraf Sharif	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: mysqldump Command-line Client	Severity:	S3 (Non-critical)
Version:	5.7.37	OS:	Any
Assigned to:	MySQL Verification Team	CPU Architecture:	Any

Description:
This was working up until 5.7.35. Running a mysqldump on a GTID-enabled server does not produce a GTID_PURGED value inside the dump file anymore. 

How to repeat:
$ mysqldump --set-gtid-purged=ON --all-databases | head -100

You should see the following output:

SET @@GLOBAL.GTID_PURGED='.....'

But there is none instead.

Suggested fix:
The workaround is to downgrade to version 5.7.35.

Hi,

I am not reproducing the issue. Are you sure gtid_purged is set? 

Can you do select @@GLOBAL.gtid_purged; before you do mysqldump?

thanks

I believe the SET @@GLOBAL.GTID_PURGED='..' has changed its location between 5.7.35 and 5.7.36, according to the release note https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-36.html .

It used to be at the beginning of the dump file. Excerpt from mysqldump 5.7.35:
--
-- GTID state at the beginning of the backup
--

SET @@GLOBAL.GTID_PURGED='9b8f7373-e41d-11ec-84e2-5254004d77d3:1-6';

For mysqldump 5.7.36:
--
-- GTID state at the end of the backup
--

SET @@GLOBAL.GTID_PURGED='9b8f7373-e41d-11ec-84e2-5254004d77d3:1-6';

The above has changed the logic of our deployment pipeline because we used to grep the head (we don't want to grep every line if the dump size is 10G+ in size). I guess from 5.7.36, we need to grep the tail instead. 

This issue can be closed.