<p>Error 1788 appears when GTID_MODE is switched without following the mandatory OFF -> OFF_PERMISSIVE -> ON_PERMISSIVE -> ON sequence on every server in the replication group.</p>
<p>MySQL Error 1788 ER_GTID_MODE_CAN_ONLY_CHANGE_ONE_STEP_AT_A_TIME occurs when GTID_MODE is toggled without following the four-state sequence on all nodes. Fix it by moving each server through the intermediate OFF_PERMISSIVE and ON_PERMISSIVE states before reaching the final setting.</p>
The value of @@GLOBAL.GTID_MODE can only be changed one
MySQL raises error 1788 when you attempt to change the global GTID_MODE variable directly from OFF to ON or vice versa without visiting the two permissive modes in between. The server blocks the change to protect replication consistency.
GTID_MODE governs whether transactions are tracked with Global Transaction Identifiers. Because every node in a replication topology must share the same setting, MySQL forces you to step through OFF, OFF_PERMISSIVE, ON_PERMISSIVE, and ON in order.
The error is most often triggered during maintenance when an administrator issues SET GLOBAL GTID_MODE = 'ON' on a server that is still in OFF. Skipping OFF_PERMISSIVE and ON_PERMISSIVE violates the required progression.
Another frequent cause is changing GTID_MODE on only one replica. MySQL checks that all servers stay synchronized; a mismatch anywhere stops the change and surfaces error 1788.
Fix the error by moving every server one step at a time. First go from OFF to OFF_PERMISSIVE, allow replication to catch up, then switch to ON_PERMISSIVE, and finally move to ON.
Always disable super_read_only and verify gtid_executed consistency before each hop. Galaxy users can script these transitions in the editor and share the sequence with teammates for reuse.
On a single-instance test bed, the fix is immediate: apply the four SET commands in order. In multi-primary topologies, coordinate the step on all nodes, wait until Seconds_Behind_Master is 0, then proceed to the next hop.
When promoting a replica to primary, ensure its GTID_MODE already matches the group to avoid surprise 1788 errors during failover.
Create an automation script that reads @@GLOBAL.GTID_MODE and decides the next valid state. Ship the script with your configuration management tool so every server transitions uniformly.
Monitor replication lag with performance_schema and delay each step until all channels are synced. Galaxy can schedule these checks and highlight mode mismatches inside the SQL editor.
Error 1776 (ER_GTID_MODE_REQUIRES_BINLOG) occurs if you enable GTID_MODE while binary logging is off. Enable log_bin first.
Error 1789 (ER_CANT_SET_GTID_MODE) appears when any transaction without a GTID exists. Empty the binary log or purge the offending transactions, then retry the mode change.
Attempting to switch directly from OFF to ON or ON to OFF without using the permissive states.
Altering GTID_MODE on only one replica while others remain in a different mode.
Proceeding to the next mode before all transactions are applied on every node.
Configuration management tools that issue a single SET command instead of a stepped sequence.
Appears when GTID_MODE is turned on while binary logging is disabled. Enable log_bin to resolve.
Raised when existing non-GTID transactions prevent changing GTID_MODE. Purge or convert the logs first.
Occurs if CREATE FUNCTION or TRIGGER is executed while GTID_MODE is OFF and enforce_gtid_consistency is ON.
No. Even in development, the server enforces the intermediate OFF_PERMISSIVE and ON_PERMISSIVE states.
Not necessarily. With careful coordination and short read-only windows, the change can be performed online.
Differing GTID_MODE values break replication guarantees. MySQL therefore requires identical settings.
Galaxy lets teams version the four-step script, run it on every node, and track mode status, reducing human error.
.avif)
.avif){kind=logo}
