<p>MySQL fails to write a row event into the binary log, stopping replication or crash recovery.</p>
<p>ER_BINLOG_ROW_LOGGING_FAILED (MySQL 1534) occurs when the server cannot write a row event to the binlog because of oversized rows, missing primary keys, disk exhaustion, or corrupted events. Free disk space, correct table design, and adjust binlog_row_image to FULL to resolve the error.</p>
Writing one row to the row-based binary log failed
MySQL raises ER_BINLOG_ROW_LOGGING_FAILED when it cannot record a row change in the binary log. The binary log is essential for replication, point-in-time recovery, and audit trails. When logging fails, replication stops and crash recovery becomes impossible, so quick resolution is critical.
The error appears with SQLSTATE HY000 and message Writing one row to the row-based binary log failed. It is reported during INSERT, UPDATE, DELETE, LOAD DATA, or bulk import operations that use row-based or mixed binlog format.
Logging fails when the row image exceeds the configured max allowed packet or binlog cache size. Missing primary keys in tables with duplicate rows also trigger the error because the server cannot uniquely identify the changed row.
Disk full, read-only file systems, or permission misconfigurations block the mysqld process from appending to the binlog file, producing the same error. Corrupted binlog files or incompatible row images after an upgrade can also be root causes.
First check disk usage with df -h and free space on the partition holding the binlog. If it is full, purge old logs with PURGE BINARY LOGS or extend storage.
If disk space is fine, confirm the table has a PRIMARY KEY. Add one if missing, then retry the transaction.
Increase max_allowed_packet and binlog_cache_size, then restart MySQL to allow larger row images.
Bulk inserts failing - switch to STATEMENT format temporarily or chunk inserts into smaller batches.
Replication stop on replica - skip the event with SET GLOBAL sql_slave_skip_counter=1 then restart replication, but investigate the master to avoid data drift.
Always define primary keys on replicated tables. Monitor disk space and automate binlog purging in production.
Set binlog_row_image=FULL to guarantee the replica can uniquely apply row events. Test major upgrades in a staging environment.
Error 1595 BINLOG_ROW_INJECTION_HOOK_FAILED arises when a row image hook fails. Causes and fixes overlap with ER_BINLOG_ROW_LOGGING_FAILED.
Error 1213 DEADLOCK when the failed transaction rolls back, causing deadlock in concurrent sessions. Resolve by retrying the workload.
The partition hosting the binary logs is full, leaving no room for new row events.
Tables without primary keys cause ambiguous row identification during logging.
Large BLOB or TEXT columns exceed max_allowed_packet or binlog_cache_size limits.
mysqld process lacks write permissions to the binlog directory.
Previous crashes leave partial events, preventing further appends.
Raised when custom hook fails during row insertion into binlog.
Replica cannot read corrupted master binlog, often following error 1534.
Replication user lacks privileges to read or write binary logs.
Switching from ROW to STATEMENT can bypass large row images but sacrifices detailed replication and should be temporary.
Yes, use SET GLOBAL sql_slave_skip_counter=1 then START SLAVE but investigate and fix the master to keep data identical.
Purge only logs that are backed up and older than the oldest replica position to avoid breaking replication.
Galaxy flags long row events, suggests packet and cache adjustments, and lets teams version critical binlog settings to prevent repeat failures.
.avif)
.avif){kind=logo}
