<p>MySQL throws ER_NO_BINARY_LOGGING (error 1381) when a statement that depends on the binary log is executed on a server where binary logging is disabled.</p>
<p>MySQL Error 1381: ER_NO_BINARY_LOGGING appears when you run a binlog-dependent command on a server that was started without the log_bin option. Enable binary logging in my.cnf or via the RDS parameter group, then restart the instance to resolve the issue.</p>
You are not using binary logging
Error 1381 carries the message You are not using binary logging. It means the MySQL server was started without the log_bin option, yet you executed a command that expects binary logging to be active.
The error is common in replication, point-in-time recovery, and audit scenarios, because those workflows depend on the binary log for change capture.
The server raises 1381 whenever you call statements like SHOW BINARY LOGS, SHOW BINLOG EVENTS, RESET MASTER, or FLUSH BINARY LOGS while binary logging is disabled.
It also triggers when stored procedures or triggers that need to write to the binlog execute on a non-logged server.
Binary logging underpins replication and point-in-time backups. If it is off, replicas cannot sync and PITR is impossible, risking data loss and downtime.
Primary cause is the MySQL instance starting with --skip-log-bin or lacking the log_bin directive in my.cnf.
Cloud services such as Amazon RDS or Azure Database may have parameter groups where binlog_format or log_bin is disabled, producing the same error.
Add log_bin, server_id, and a unique log file base name to your my.cnf, then restart MySQL.
In managed services, modify the parameter group to enable binary logging and apply a reboot.
Local development servers often skip binary logging for performance. Enable it only on staging and production, or wrap replication commands in IF clauses to avoid errors.
During logical backups, mysqldump --master-data needs the binlog. Run mysqldump without that flag or turn binary logging on.
Automate configuration management so every production instance has log_bin enabled and validated at boot time.
Use monitoring to alert when the variable log_bin is OFF so the team can respond before replication breaks.
Error 1220 ER_BINLOG_DISABLED is similar but appears when you attempt to change binlog_format on a server without logging. Enabling log_bin resolves both.
Error 1593 ER_SLAVE_CONFIGURATION prevents a replica from starting if the source lacks binary logging; again the fix is enabling log_bin and restarting.
The skip flag disables all binary logging, immediately triggering error 1381 for any binlog call.
If my.cnf lacks log_bin, the server runs silently without logging and raises the error on demand.
Cloud databases can override your settings; a disabled flag in the parameter group causes the same error.
Some replicas are configured without logging to save space; issuing RESET MASTER on them fires 1381.
Triggered when you change binlog_format while binary logging is off.
Occurs when a replica expects binary logs but the source has them disabled.
Appears when trying to turn on log retention features without active binlogging.
Binary logging adds minimal overhead on modern storage. The safety benefits outweigh the cost for most workloads.
No. log_bin is a static variable. You must modify my.cnf or the parameter group and reboot.
Not strictly, but enabling it improves disaster recovery and allows chained replication.
Galaxy highlights server variables in its schema panel, alerting you when log_bin is OFF so you can act before running replication commands.
.avif)
.avif){kind=logo}
