<p>The server is in GTID_MODE=OFF but tries to read a binary log that contains GTID events, causing replication or startup failure.</p>
<p>MySQL Error 1784: ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF appears when a server with GTID_MODE set to OFF reads a binary log that contains GTID events. Turn GTID_MODE ON (or ON_PERMISSIVE) or purge the offending binary logs to clear the error.</p>
Found a Gtid_log_event or Previous_gtids_log_event when
The error fires when a MySQL instance running with @@GLOBAL.GTID_MODE=OFF encounters a Gtid_log_event or Previous_gtids_log_event in a binary or relay log. Because GTID events require GTID_MODE set to ON or a permissive state, the server halts replication or startup to avoid data corruption.
Versions before 5.7.5 raised Error 1784 directly, while newer releases reject the log with a generic message. Understanding why the mismatch occurs lets you repair replication quickly and safely.
Most cases involve copying or replicating binary logs from a GTID-enabled source into a GTID-disabled replica. Disabling GTID_MODE locally without purging existing logs can also leave GTID events in place, triggering the error on restart.
Upgrades, downgrades, or restoring backups created on servers with different GTID settings frequently introduce the mismatch.
The fastest remedy is to enable GTID_MODE so the server accepts the GTID events. Switch through the safe state sequence OFF - OFF_PERMISSIVE - ON_PERMISSIVE - ON, then restart replication.
If you cannot use GTIDs, purge or rotate the problematic binary logs, create a new replication snapshot, and restart replication with MASTER_AUTO_POSITION disabled.
During replica rebuilds, loading an old dump that still references GTID events causes Error 1784. Enable GTID_MODE temporarily, restore, then disable if required.
When cloning production data for staging, ensure both environments share the same gtid_mode value before transporting binlogs.
Standardize GTID settings across all servers in a topology. Automate variable checks during deployment to flag inconsistencies early.
Regularly expire or purge binary logs so that disabling GTID_MODE never leaves stray GTID events behind.
Error 1843 (ER_GTID_EXECUTED_WO_GTID_MODE) appears when @@GLOBAL.GTID_EXECUTED is non-empty while GTID_MODE is OFF. Fix it by clearing gtid_executed or re-enabling GTIDs.
Error 1839 (ER_GTID_NEXT_LIST_NOT_NEEDED) surfaces when GTID_NEXT is set incorrectly. Reset the session variable or use SET GTID_NEXT='AUTOMATIC'.
Binary logs copied from a master running GTID_MODE=ON land on a replica where GTID_MODE=OFF, leading to Error 1784 during replication start.
Administrators turn GTID_MODE OFF for maintenance but forget to rotate or purge logs that already hold GTID events.
A physical backup taken from a GTID-enabled server is restored onto an instance with GTID disabled, triggering the error during crash recovery.
Raised when gtid_executed is populated but GTID_MODE is OFF. Clear the variable or enable GTID_MODE.
Occurs when GTID_NEXT list has duplicate entries. Use SET GTID_NEXT='AUTOMATIC'.
Appears when replication references purged logs. Re-sync replication or adjust log file positions.
No. The mismatch indicates potential data drift. Resolve it before relying on replication integrity.
The explicit error code was retired after 5.7.5, but the server still stops with a similar message when GTID events are read in GTID_MODE=OFF.
Switching through OFF_PERMISSIVE and ON_PERMISSIVE preserves consistency. Always back up first, then enable GTIDs.
Galaxy's SQL editor surfaces gtid_mode and other variables inline, letting you validate settings before moving binlogs or cloning data, preventing Error 1784.
.avif)
.avif){kind=logo}
