Description:
Environment
MySQL Server: 8.0.40
mysqldump: 8.0.40
OS/Platform: Ubuntu 22.04 x86_64 (replace with your actual OS)
Topology: Primary-Replica with GTID enabled
Configuration
gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=ON
binlog_format=ROW
Other relevant variables (if applicable): master_info_repository=TABLE, relay_log_info_repository=TABLE
Affected component
Client: mysqldump (8.0.40)
Summary
When running mysqldump 8.0.40, a FLUSH TABLES statement appears to be issued before the dump starts. If this statement is written to the binlog, it generates a new GTID despite not changing user data, causing GTID divergence between primary and replica.
How to repeat:
Confirm baseline GTID on the primary:
SELECT @@GLOBAL.gtid_executed;
Run mysqldump without explicit table locks (replace with your actual command):
mysqldump -q --single-transaction --skip-dump-date --skip-triggers test t1 > t1.sql
Notes:
In our environment, mysqldump 8.0.40 issues FLUSH TABLES prior to dumping.
Check GTID again on the primary:
SELECT @@GLOBAL.gtid_executed;
A new GTID has been added even though no user data changes were performed.
Optional evidence from binlog (replace with your binlog path/reader):
mysqlbinlog /var/lib/mysql/binlog.000123 | grep -n "FLUSH"
The binlog shows a FLUSH TABLES statement around the time mysqldump connected.
Replication impact:
The replica receives the new GTID event, causing divergence and potential confusion for automation that expects no GTID changes during a logical dump.
Suggested fix:
change "FLUSH TABLES" to "FLUSH NO_WRITE_TO_BINLOG TABLES"
