MySQL raises error 3190 (ER_CANT_RESET_MASTER) when the RESET MASTER command is blocked because the server is in a state that makes purging the binary log unsafe.
ER_CANT_RESET_MASTER appears when MySQL blocks the RESET MASTER command to protect replication consistency. Check for running replication threads, active GTID transactions, or binary log file locks, then stop replication and retry RESET MASTER to resolve the issue.
ER_CANT_RESET_MASTER
MySQL error 3190, condition name ER_CANT_RESET_MASTER, is thrown when you run RESET MASTER but the server decides the operation is unsafe. The %s placeholder in the error message is replaced with a reason such as "slave running" or "super_read_only enabled".
RESET MASTER deletes all existing binary log files and creates a new one. MySQL therefore blocks the command if replication threads are active, global transaction identifier (GTID) state is inconsistent, or the server is read only. Fixing the error quickly is vital to keep replication healthy and free disk space.
The error is usually caused by active replication activity. If IO_THREAD or SQL_THREAD is running, MySQL refuses to purge binary logs to prevent data loss on replicas.
Another cause is super_read_only or read_only mode. When these flags are ON, administrative commands that modify data or logs are disallowed, including RESET MASTER.
In GTID mode, pending transactions must be flushed to the binary log before it can be reset. Any gap forces MySQL to abort the RESET MASTER request.
First, stop all replication threads with STOP SLAVE or STOP REPLICA, depending on your version. Confirm they are no longer running by inspecting SHOW SLAVE STATUS.
Next, disable read only restrictions by issuing SET GLOBAL super_read_only = OFF and SET GLOBAL read_only = OFF if they are enabled. Ensure you have SUPER privilege.
Finally, run RESET MASTER again. MySQL should create a fresh binary log file, clearing the error. Remember to start replication threads afterward with START SLAVE or START REPLICA.
On primary servers with replicas connected, DBAs forget to stop replication before purging logs. A quick STOP SLAVE IO_THREAD is sufficient to allow RESET MASTER.
Cloud environments may enable super_read_only automatically during failover. Turning it off temporarily lets you reset the binary log.
During major maintenance, GTID_PURGED might be non-empty. FLUSH TABLES WITH READ LOCK then UNLOCK TABLES ensures all GTIDs are flushed so RESET MASTER can succeed.
Automate log rotation with PURGE BINARY LOGS TO 'mysql-bin.XXXXXX' or based on binlog_expire_logs_seconds so manual RESET MASTER is rarely needed.
Always stop replication and verify the node is a standalone primary before running destructive commands. Use scripts that perform safety checks.
Monitor read only flags and GTID consistency with performance_schema tables or an observability tool so issues are caught early.
Error 1186 (ER_BINLOG_PURGE_PROHIBITED) appears when PURGE BINARY LOGS is unsafe for similar reasons. The fix is the same: stop replication and clear read only state.
Error 1792 (ER_GTID_PURGED_WAS_CHANGED) surfaces when GTID_PURGED is altered incorrectly. Restoring consistent GTID_PURGED eliminates the problem.
RESET MASTER cannot execute while IO_THREAD or SQL_THREAD is running because replicas still need the binary logs.
These server modes block administrative changes, stopping RESET MASTER until they are disabled.
Pending GTID events must be written to the binary log before it is reset; otherwise consistency is at risk.
Occurs when PURGE BINARY LOGS is unsafe. Stop replication and disable read only modes to resolve.
Raised when GTID_PURGED is changed inconsistently. Fix by setting GTID_PURGED to a correct contiguous set.
Appears when writes are attempted in read only mode. Turning off super_read_only clears the error.
Do not run RESET MASTER on a replica that still needs binary logs from the primary. Use PURGE BINARY LOGS on replicas or wait until they have processed all events.
The command resets binary log files but preserves GTID_EXECUTED and GTID_PURGED information, keeping GTID replication intact.
Yes. PURGE BINARY LOGS TO or PURGE BINARY LOGS BEFORE removes only older logs while keeping the current file. This is less disruptive.
Galaxy lets you script safety checks into shared, versioned queries. Team members can run vetted maintenance snippets that automatically stop replication and verify server state before issuing RESET MASTER.
.avif)
.avif){kind=logo}
