<p>MySQL raises this error when GTID_MODE is set to OFF_PERMISSIVE without binary logging and slave-update logging enabled.</p>
<p>MySQL Error 1780 (ER_GTID_MODE_REQUIRES_BINLOG) occurs when you set GTID_MODE to OFF_PERMISSIVE but log-bin or log-slave-updates is disabled. Enable binary logging and slave updates, or switch GTID_MODE to OFF, to resolve the issue quickly.</p>
@@GLOBAL.GTID_MODE = ON or ON_PERMISSIVE or
MySQL raises error 1780 (SQLSTATE HY000) when you set @@GLOBAL.GTID_MODE to OFF_PERMISSIVE yet binary logging is disabled or --log-slave-updates is not enabled. The GTID subsystem relies on the binary log to store transaction identifiers, so even permissive modes depend on logging.
The server rejects the SET GLOBAL GTID_MODE statement, returns ER_GTID_MODE_REQUIRES_BINLOG, and keeps the previous mode. Replication or migration procedures halt until the logging prerequisites are satisfied or GTID tracking is disabled entirely.
Attempting to enable GTID_MODE = OFF_PERMISSIVE on an instance with log-bin disabled is the most frequent cause. Without the binary log, GTIDs cannot be recorded or replayed, breaking consistency guarantees.
The error also appears on replicas that have log-bin enabled but omit log-slave-updates. Replicas must write applied transactions back to their own binary log so their GTID sets remain complete.
Enable binary logging by adding log_bin and a unique server_id to my.cnf, then restart the server. For replicas, also add log_slave_updates. After the restart, retry setting GTID_MODE.
If you do not require GTID tracking, set GTID_MODE = OFF instead. This mode works without binary logging at the cost of losing GTID-based replication benefits.
In local development environments, remove GTID_MODE changes or disable GTIDs to avoid unnecessary logging overhead and configuration complexity.
During staged GTID migrations, first deploy log-bin and log-slave-updates across all nodes. Only then raise GTID_MODE progressively: OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON.
Keep binary logging enabled wherever replication might be needed. Consistent configuration across the fleet prevents surprises when enabling GTIDs later.
Automate configuration management with tools like Galaxy, Ansible, or Chef to ensure log-bin and log-slave-updates stay synchronized across primary and replica instances.
Error 1781 ER_GTID_NEXT_TYPE_UNDEFINED_FLAG occurs when GTID_NEXT is set to an invalid value. Reset GTID_NEXT to AUTOMATIC to clear the fault.
Error 1231 ER_VARIABLE_IS_READONLY appears if you attempt a dynamic GTID_MODE change on versions that require a restart. Restart the server with the desired setting to resolve.
GTID_MODE relies on the binary log. When log-bin is OFF, MySQL cannot store GTID events, triggering the error.
Replicas that do not re-log applied events break the global GTID set, so OFF_PERMISSIVE fails without this flag.
Changing GTID_MODE before enabling required logging options causes ER_GTID_MODE_REQUIRES_BINLOG during GTID rollouts.
Appears when GTID_NEXT uses an invalid value. Reset GTID_NEXT to AUTOMATIC.
Occurs when GTID_MODE changes are attempted dynamically on versions that require a restart.
Indicates replication thread issues often seen after improper GTID migrations.
Yes. GTID_MODE=OFF removes GTID tracking and does not require binary logging.
OFF_PERMISSIVE is a transitional mode. Keep it brief and move to ON_PERMISSIVE or ON once binary logging is stable.
No. log_slave_updates is only needed on replicas so they record the GTIDs they apply.
Galaxy highlights server variables, warns about GTID prerequisites, and lets teams share vetted migration scripts, reducing misconfiguration risks.
.avif)
.avif){kind=logo}
