<p>The server is running with GTID_MODE=ON, so the legacy sql_slave_skip_counter variable cannot be used to skip transactions.</p>
<p>MySQL Error 1858 ER_SQL_SLAVE_SKIP_COUNTER_NOT_SETTABLE_IN_GTID_MODE occurs when you try to use sql_slave_skip_counter while GTID replication is enabled. Replace the counter with an empty GTID transaction for every event you need to bypass, then restart replication to resolve the issue.</p>
sql_slave_skip_counter can not be set when the server is
MySQL raises error 1858 when a user attempts to set the sql_slave_skip_counter variable on a replica that is running with @@GLOBAL.GTID_MODE = ON. GTID replication no longer supports skipping events with this legacy counter.
The check was added in MySQL 5.7.1 to enforce transactional consistency. GTID replication tracks every transaction by a Global Transaction Identifier, so skipping by positional counter risks divergent data.
The message shows up immediately after executing SET GLOBAL sql_slave_skip_counter = N or changing the value through a configuration file while GTID mode is enabled on the server.
It can also surface indirectly when automation tools or legacy scripts still rely on sql_slave_skip_counter for error handling on replicas that have been upgraded to GTID.
Replication stops when the command fails, leaving the replica out of sync. An unsynchronized replica undermines high availability, read scaling, and disaster-recovery objectives.
Failing to address the error can also hide deeper data issues that must be investigated before resuming replication.
The root cause is a mismatch between GTID replication requirements and the deprecated skip mechanism. GTID ensures every transaction is applied exactly once, so blindly skipping a number of events is forbidden.
The error is often triggered by leftover administrative habits, custom failover scripts, or monitoring systems unaware of GTID restrictions.
Identify the exact GTID of the problematic transaction from SHOW SLAVE STATUS or performance_schema tables. Then create an empty transaction with the same GTID on the replica, effectively marking it as applied.
After injecting the fake transaction, restart the replica threads with START REPLICA or START SLAVE. Replication will continue from the next event.
On a replica that stopped due to a duplicate primary-key error, use the retrieved_gtid_set to locate the conflicting GTID, inject an empty transaction, and restart replication.
If multiple consecutive transactions need skipping, repeat the empty-transaction procedure for each GTID rather than relying on a single counter value.
Remove every reference to sql_slave_skip_counter from maintenance scripts before enabling GTID. Always handle replication errors with explicit GTID transactions.
Monitor replicas with tools that understand GTID, and test failover routines after major version upgrades. Using Galaxy's modern SQL editor, store vetted skip procedures in shared Collections so the team executes the correct fix consistently.
Error 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG) indicates a broken binary log file and may appear alongside 1858. Resolve by recloning or pointing to a valid log position.
Error 1593 (ER_SLAVE_FATAL_ERROR) covers replication halts due to other GTID mismatches. Empty transactions or re-initialization can help, depending on the scenario.
Old automation still uses positional skipping even after GTID was enabled.
DBAs follow pre-GTID guides that recommend sql_slave_skip_counter commands.
Some replicas run in GTID mode while others use file-position, causing inconsistent administrative steps.
Upgrading from MySQL 5.6 to 5.7+ activates GTID by default, exposing scripts that rely on the obsolete counter.
Indicates the replica cannot read a binary log event. Often requires re-syncing the replica or changing master position.
A generic replication fatal error, frequently triggered by GTID inconsistencies. Follow a similar empty-transaction or clone approach.
Occurs when the relay log is corrupted. Purge and restart replication or reclone the replica.
Yes. The variable works when @@GLOBAL.GTID_MODE = OFF because replication reverts to file-position tracking.
Create an empty transaction for each GTID using a loop in a shell script or stored procedure. Never bundle them into one counter.
No. Empty GTID transactions simply mark the events as applied without altering data, preserving GTID consistency across servers.
Galaxy lets teams store approved skip scripts in shared Collections, track execution history, and run commands directly in its fast SQL editor, reducing human error.
.avif)
.avif){kind=logo}
