<p>MySQL raises error 1768 when you attempt to change @@SESSION.GTID_NEXT inside an open transaction while GTID_NEXT_LIST is NULL.</p>
<p>MySQL Error 1768: ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION_WHEN_GTID_NEXT_LIST_IS_NULL appears when @@SESSION.GTID_NEXT is modified within an active transaction. End or roll back the transaction, then set GTID_NEXT outside of transactional scope to resolve the issue.</p>
The system variable @@SESSION.GTID_NEXT cannot change
The server blocks any attempt to change the session variable @@SESSION.GTID_NEXT while a transaction is still open and GTID_NEXT_LIST is NULL. MySQL enforces this rule to preserve global transaction identifier integrity.
You will see the message as soon as a SET GTID_NEXT statement runs after a START TRANSACTION or when autocommit is disabled and at least one data-modifying statement has executed.
Leaving the session in an unrecoverable state stalls replication setup scripts, migration jobs, and point-in-time recovery tasks. Prompt correction prevents replication gaps and downtime.
The root cause is issuing SET @@SESSION.GTID_NEXT while a transaction remains uncommitted. Because GTID_NEXT_LIST is NULL, MySQL cannot split or re-order GTID assignment safely.
Finish the current transaction with COMMIT or ROLLBACK, then set GTID_NEXT. Alternatively, move the SET statement to a new connection or enable autocommit before changing GTID_NEXT.
Replication provisioning scripts often disable autocommit, run a series of DDL or DML statements, and then attempt to change GTID_NEXT for a special transaction. Re-order the script so GTID_NEXT changes only occur at a clean autocommit boundary.
Always set GTID_NEXT in its own autocommit session. Use explicit COMMIT after every logical group of statements when GTIDs are involved. Monitor @@SESSION.GTID_NEXT and @@SESSION.GTID_NEXT_LIST before issuing changes.
Errors 1840 (ER_GTID_NEXT_TYPE_UNDEFINED_GTID) and 1853 (ER_GTID_UNSAFE_NON_TRANSACTIONAL_TABLE) also involve GTID mis-configuration. Their fixes likewise center on correct GTID session handling.
The application sets autocommit = 0 and later changes @@SESSION.GTID_NEXT without committing.
A DML statement inside the procedure starts a transaction, then a SET GTID_NEXT occurs.
Scripts that copy data then switch to GTID mode forget to commit before the switch.
An administrator runs START TRANSACTION, updates a table, and immediately attempts to set GTID_NEXT.
Raised when GTID_NEXT is set to a value not permitted in the current context.
Occurs when non-transactional tables are modified in a GTID-enabled session.
Indicates GTID_MODE requires enforce_gtid_consistency to be ON.
No. MySQL does not provide a setting to bypass the safety check. Always end the current transaction first.
The specific error code 1768 was removed after 5.7.5, but the rule still exists. Newer versions raise ER_CANT_SET_GTID_NEXT_WHEN_GTID_MODE_IS_OFF instead.
The error can appear on replicas if a transaction is open in a session where you manually change GTID_NEXT.
Galaxy highlights active transactions, shows session variables inline, and warns before you run SET GTID_NEXT in an open transaction, preventing the error proactively.
.avif)
.avif){kind=logo}
