<p>The session variable @@SESSION.GTID_NEXT_LIST was given a value while global GTID_MODE=OFF, which MySQL forbids.</p>
<p>MySQL Error 1783 ER_CANT_SET_GTID_NEXT_LIST_TO_NON_NULL_WHEN_GTID_MODE_IS_OFF occurs when you assign a non-NULL value to @@SESSION.GTID_NEXT_LIST while @@GLOBAL.GTID_MODE is OFF. Turn GTID_MODE to ON or set GTID_NEXT_LIST=NULL to resolve the issue.</p>
@@SESSION.GTID_NEXT_LIST cannot be set to a non-NULL
Error 1783 is thrown when a session attempts to set @@SESSION.GTID_NEXT_LIST to a value other than NULL while the server has GTID_MODE turned OFF. Global Transaction Identifiers (GTIDs) are disabled in this state, so MySQL blocks all manual GTID assignments.
The error prevents inconsistencies that can corrupt replication topologies. Fixing it quickly is crucial when preparing a server for replication, backups, or point-in-time recovery.
The primary trigger is executing SET @@SESSION.GTID_NEXT_LIST='UUID:NUMBER' or similar while @@GLOBAL.GTID_MODE=OFF. This usually happens in scripts that assume GTID mode is already enabled.
Another cause is restoring logical dumps generated from GTID-enabled servers into a new instance that still runs with GTID_MODE=OFF. The dump contains SET GTID_NEXT statements, which then fail.
Option 1 - enable GTIDs: switch @@GLOBAL.GTID_MODE to ON (or ON_PERMISSIVE) and restart required threads. This makes manual GTID assignment legal.
Option 2 - remove GTID_NEXT_LIST statements from your script or set @@SESSION.GTID_NEXT_LIST=NULL so MySQL generates GTIDs automatically when you later enable GTID mode.
Dump restore: edit the dump to comment out SET @@SESSION.GTID_NEXT or run the restore after enabling GTID_MODE.
Replication setup script: reorder commands so that you turn GTID_MODE ON before you seed data or set GTID_NEXT_LIST.
Always check SELECT @@GLOBAL.GTID_MODE before issuing any GTID-related statements. Automate this check in deployment scripts.
Use ON_PERMISSIVE during migrations; it lets old transactions proceed while allowing new GTID-based ones, reducing downtime.
Error 1781 ER_GTID_MODE_OFF prevents SET GTID_NEXT to UUID:NUMBER when GTID_MODE is OFF. Fix by enabling GTID_MODE.
Error 1789 ER_GTID_MODE_2_STRICT requires GTID consistency and is solved by adjusting enforce_gtid_consistency or code changes.
@@GLOBAL.GTID_MODE is OFF so any attempt to set GTID_NEXT_LIST fails.
Scripts enable GTID mode after issuing SET GTID_NEXT_LIST commands, triggering the error.
Dumps created on GTID-enabled servers include SET GTID_NEXT statements that break on a GTID-disabled target.
Servers downgraded from GTID ON to OFF still run old maintenance jobs that reference GTID_NEXT_LIST.
Occurs when SET GTID_NEXT attempts are made while GTID_MODE is OFF. Solution: enable GTID mode.
Raised when enforce_gtid_consistency is OFF while GTID_MODE is ON. Solution: align both settings.
Triggered by unsupported GTID_NEXT value. Fix by using AUTOMATIC or a valid UUID:NUMBER.
Yes. Set @@SESSION.GTID_NEXT_LIST=NULL or delete GTID statements from your script. MySQL will run transactions without GTIDs.
ON_PERMISSIVE allows a phased migration. Keep it short and monitor replication to avoid mixed GTID/non-GTID transactions for long periods.
No full restart is required, but you must issue FLUSH LOGS and reconnect sessions so they inherit the new GTID state.
Galaxy’s AI copilot inspects server variables before generating GTID statements, flagging GTID_MODE mismatches in real time inside the editor.
.avif)
.avif){kind=logo}
