<p>This error appears when a MySQL replica running with log-slave-updates enabled is not using ROW binlog_format, blocking row-based event replication.</p>
<p>MySQL Error 1536: ER_BINLOG_ROW_RBR_TO_SBR indicates that a replica with log-slave-updates must switch its binary log format to ROW to replay row-based events. Set binlog_format='ROW', restart the replica, and the replication stream will resume.</p>
Slave running with --log-slave-updates must use row-based
Error 1536 fires when a MySQL replica that has the log-slave-updates option turned on is still configured with STATEMENT or MIXED binary logging. Because the upstream source sends row-based binary log (RBR) events, the replica must also record its own binary log in ROW mode to forward those events safely.
Replication halts immediately after the first row-based event arrives, and the SQL thread reports the exact error message: "Slave running with --log-slave-updates must use row-based binary logging to be able to replicate row-based binary log events."
Row-based events include before-and-after images of table rows. To preserve data integrity through chained replication topologies, every server that rewrites or forwards those events must log them in the same ROW format. Allowing a mix of formats could silently corrupt downstream replicas.
The problem usually appears right after enabling log-slave-updates on a replica, promoting a replica to an intermediate relay, cloning configuration files, or upgrading a server without adjusting the binlog_format parameter.
While the error is present, the replica’s SQL thread stops, causing replication lag and potentially stale reads. In multi-tier replication, downstream replicas will also stall, amplifying data freshness issues across environments.
The replica was started with binlog_format=STATEMENT or MIXED, which cannot safely log incoming row events.
Administrators often turn on log-slave-updates to build relay topologies but forget to switch to ROW logging.
MySQL upgrades can overwrite or ignore deprecated my.cnf settings, reverting binlog_format to STATEMENT.
Copying a standard my.cnf from another environment may set binlog_format incorrectly on the new replica.
Occurs when a replica detects potential data drift; often follows format mismatches.
Indicates problems reading the source binary log file or position.
Fires when the replica cannot find or read a required binary log event from the source.
Signals that replication was stopped because of a definer mismatch or privilege issue.
No. When log-slave-updates is enabled, MySQL requires pure ROW format on that server. MIXED or STATEMENT will halt replication.
ROW logs can be larger, but they often perform better on replicas because no statement-based conflict checks are needed. Use row compression and binlog_expire_logs_seconds to control size.
The primary can use MIXED, but when it emits row events the entire chain must forward them in ROW mode. Keeping both tiers on ROW simplifies management.
Galaxy’s SQL editor highlights replica status variables and surfaces replication errors inline. Team members can share the correct SET PERSIST commands in a Collection, ensuring consistent rollout across environments.
.avif)
.avif){kind=logo}
