<p>The GTID you set in @@SESSION.GTID_NEXT does not appear in @@SESSION.GTID_NEXT_LIST, so MySQL aborts the statement to protect GTID consistency.</p>
<p>MySQL Error 1767: ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST occurs when the GTID assigned to @@SESSION.GTID_NEXT is missing from @@SESSION.GTID_NEXT_LIST, breaking replication safety rules. Reset @@SESSION.GTID_NEXT to AUTOMATIC or add the GTID to the list to resolve the issue.</p>
The system variable @@SESSION.GTID_NEXT has the value %s,
The exact error is: The system variable @@SESSION.GTID_NEXT has the value X, which is not listed in @@SESSION.GTID_NEXT_LIST. MySQL raises it when you attempt to execute a transaction with a user-supplied GTID that is not pre-approved in GTID_NEXT_LIST.
The guard prevents rogue GTIDs from entering replication streams, ensuring every transaction matches the deterministic list exchanged between primary and replica servers.
The error appears during manual GTID operations such as mysqldump --set-gtid-purged=OFF restores, point-in-time recovery, or custom replication maintenance scripts that explicitly set @@SESSION.GTID_NEXT.
It is common after running SET SESSION GTID_NEXT='uuid:transaction_number' but forgetting to include that GTID in GTID_NEXT_LIST or to reset variables after completing a batch.
MySQL enforces that every manually assigned GTID must already exist in @@SESSION.GTID_NEXT_LIST. If the variable is empty or the GTID is mistyped, the check fails and error 1767 is raised before the transaction begins.
The problem also occurs when GTID_NEXT_LIST still contains ONLY_PERMITTED_GTID after a previous SET GTID_NEXT_LIST command, blocking new GTIDs.
Immediately reset GTID handling by running SET SESSION GTID_NEXT='AUTOMATIC'; This returns control of GTID allocation to MySQL and clears the block.
If you must replay a specific GTID, first append the GTID to GTID_NEXT_LIST, then set GTID_NEXT, and finally run the DML statement.
Scenario: Restoring a logical backup that contains explicit GTIDs. Solution: Strip the SET @@SESSION.GTID_NEXT commands or wrap them with matching GTID_NEXT_LIST statements.
Scenario: Manual failover script leaves GTID_NEXT set. Solution: Add a cleanup step that resets GTID session variables before the connection closes.
Keep @@SESSION.GTID_NEXT at AUTOMATIC for normal workloads. Manipulate it only inside controlled maintenance scripts.
After using GTID_NEXT, always reset both GTID_NEXT and GTID_NEXT_LIST in an ENSURE clause or after block to avoid leaking session state.
Error 1782 ER_GTID_NEXT_TYPE_UNDEFINED_GROUP occurs when GTID_NEXT is uuid:0. Reset GTID_NEXT to AUTOMATIC.
Error 1781 ER_GTID_NEXT_TYPE_UNDEFINED_SESSION arises if GTID_NEXT variable is NULL. Set a valid GTID or AUTOMATIC.
You set @@SESSION.GTID_NEXT to a specific GTID but never populated GTID_NEXT_LIST, so the value is rejected.
A misspelled server UUID or transaction number means the GTID is not recognised in the list, triggering error 1767.
You previously limited GTID_NEXT_LIST to ONLY_PERMITTED_GTID. Any new GTID fails the inclusion test, so statements abort.
Scripts that forget to reset GTID_NEXT leave the session in a restricted state, causing the next consumer to fail immediately.
Raised when GTID_NEXT is set to uuid:0. Use a non-zero transaction number or reset to AUTOMATIC.
Occurs if GTID_NEXT is NULL. Set a valid GTID or AUTOMATIC before running statements.
Thrown when the chosen GTID exists in GTID_SKIP_LIST. Remove it from the skip list or choose another GTID.
The list guarantees that manually specified GTIDs are validated against the replica’s expectation, preventing divergent replication histories.
No. The safety check is hard-coded. Instead, keep GTID_NEXT set to AUTOMATIC unless you have a controlled use case.
Yes. If unhandled, the transaction never enters the binary log, so replicas may miss data. Fix the error before continuing.
Galaxy surfaces session variable changes inline and lets you enforce query templates that reset GTID variables, eliminating this error in team workflows.
.avif)
.avif){kind=logo}
