<p>MySQL error 1840 occurs when SET GLOBAL GTID_PURGED is executed while GTID_EXECUTED already contains transactions.</p>
<p>MySQL Error 1840: ER_CANT_SET_GTID_PURGED_WHEN_GTID_EXECUTED_IS_NOT_EMPTY means GTID_PURGED can be set only on a server whose GTID_EXECUTED set is empty. Fix it by running RESET MASTER or by provisioning a fresh instance before issuing SET GLOBAL GTID_PURGED.</p>
@@GLOBAL.GTID_PURGED can only be set when
Error 1840 fires when you run SET GLOBAL GTID_PURGED on a server that already has transactions in @@GLOBAL.GTID_EXECUTED. MySQL blocks the statement to protect GTID consistency.
The error typically appears during replication setup, point-in-time recovery, or after importing a dump created with --set-gtid-purged=ON. Clearing GTID_EXECUTED or starting from a clean server resolves the conflict.
The main trigger is a non-empty GTID_EXECUTED set. MySQL allows GTID_PURGED to be set only when the server has executed no GTID transactions, ensuring that purged GTIDs align with real history.
Attempting to replay a dump containing SET GLOBAL GTID_PURGED statements on an active server, or reinitializing replication without cleaning metadata, will also raise the error.
Make GTID_EXECUTED empty, then reissue SET GLOBAL GTID_PURGED. The quickest method is RESET MASTER; it wipes binary logs and resets GTID_EXECUTED.
On production systems, provision a fresh replica or clone of the primary, apply the dump, then start replication. This avoids data loss risk caused by RESET MASTER.
Importing Logical Dump - Restore the dump on a new server created with --initialize-insecure so GTID_EXECUTED starts empty, then run the included SET GLOBAL GTID_PURGED.
Re-configuring a Replica - Stop replication, run RESET MASTER, restore a fresh dump, set GTID_PURGED, then start replication with CHANGE MASTER TO MASTER_AUTO_POSITION=1.
Always restore GTID-based backups on clean instances. Automate environment creation with containers or cloud snapshots so GTID_EXECUTED is guaranteed empty.
Before running SET GLOBAL GTID_PURGED in scripts, check SELECT @@GLOBAL.GTID_EXECUTED. Abort if the result is not empty to prevent runtime failures.
Error 1236: MASTER_LOG_POS invalid often follows an incorrect GTID_PURGED operation. Resynchronize by running RESET SLAVE ALL and CHANGE MASTER TO with AUTO_POSITION.
Error 1712: Slave SQL running but encountering GTID gaps can occur when GTID_PURGED was mis-set. Rebuild the replica from a fresh snapshot to eliminate inconsistencies.
The server already executed transactions, so GTID_EXECUTED is not empty when SET GLOBAL GTID_PURGED runs.
Dumps made with --set-gtid-purged=ON include SET GLOBAL GTID_PURGED, which fails on servers with existing GTIDs.
Resetting replication metadata but forgetting RESET MASTER leaves GTID_EXECUTED populated, triggering the error.
Shows when replication starts from an incorrect binary log position.
Indicates missing GTID transactions on a replica, often after wrong GTID_PURGED settings.
Fires if GTID_PURGED is altered after transactions exist, similar root cause.
No. GTID_EXECUTED must be empty. Use a fresh instance or RESET MASTER.
It removes binary logs and GTID metadata but leaves table data intact. Always back up first.
Server side. MySQL rejects the SET GLOBAL GTID_PURGED statement.
Galaxy surfaces GTID variables in the editor sidebar, warns if GTID_EXECUTED is non-empty, and suggests safe execution plans.
.avif)
.avif){kind=logo}
