<p>The server detected that the @@GLOBAL.GTID_EXECUTED value was unexpectedly modified, signaling possible replication drift or manual tampering.</p>
<p>MySQL Error 1843 ER_GTID_EXECUTED_WAS_CHANGED occurs when the GTID set stored in @@GLOBAL.GTID_EXECUTED is altered during runtime, breaking replication consistency. Restore the correct GTID set or restart the server with proper replication settings to resolve the issue.</p>
@@GLOBAL.GTID_EXECUTED was changed from '%s' to '%s'.
The exact message is: @@GLOBAL.GTID_EXECUTED was changed from '%s' to '%s'. The server raises it when the GTID set tracking executed transactions suddenly shifts while MySQL is running.
GTIDs guarantee that every transaction is uniquely identified across the replication topology. If the executed set jumps, slaves can no longer determine which events are missing or duplicated.
The error surfaces during replication startup, binary log rotation, or any internal consistency check that reads @@GLOBAL.GTID_EXECUTED after an unexpected update.
It is common after manual UPDATE statements on mysql.gtid_executed or third-party tools that incorrectly edit relay logs.
Most cases trace back to human actions: restoring snapshots, importing dumps, or using SET GLOBAL GTID_PURGED without restarting the server.
It can also result from bugs in earlier MySQL 5.6/5.7 releases that double-apply GTID sets during crash recovery.
First, stop replication threads to prevent further divergence. Capture the current GTID_EXECUTED value for auditing.
Next, decide on the authoritative GTID set. You can reset it with RESET MASTER or reset slave positions with RESET SLAVE ALL, then re-seed data from a healthy source.
If a backup restore caused the error, re-import with --set-gtid-purged=OFF so GTIDs are not rewritten.
If only one server is affected, use CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 and start replication from a clean snapshot.
Never modify mysql.gtid_executed manually in production. Always perform GTID_PURGED operations while the server is offline.
Automate backups and restores with mysqldump or MySQL Shell, and validate GTID consistency before promotion.
Errors 1236 (binlog out of sync) and 1840 (ER_GRP_RPL_GTID_EXECUTED_WAS_CHANGED) often appear together. They share similar root causes and fixes.
Running UPDATE/INSERT on the internal GTID tables changes the executed set without proper logs.
Setting GTID_PURGED while the server is online rewrites history and confuses slaves.
Importing a dump generated with different GTID sets inserts mismatched values.
Older MySQL versions duplicated GTIDs after an unclean shutdown, leading to diverging sets.
Indicates binary log gap; often follows a GTID mismatch.
Group Replication variant of the same inconsistency.
Raised when GTID_PURGED is modified incorrectly.
Yes. It halts replication until GTID sets are reconciled or logs are reset.
No. Ignoring it risks silent data divergence and inconsistent reads.
Upgrading removes known bugs but you must still reset or align GTID sets.
Galaxy tracks query history and endorses safe administrative commands, reducing accidental GTID edits.
.avif)
.avif){kind=logo}
