<p>The server cannot write the current transaction to the binary log because row-based logging is active while at least one table relies on a statement-only storage engine.</p>
<p>MySQL Error 1664 ER_BINLOG_ROW_INJECTION_AND_STMT_ENGINE happens when row-based binlogging meets a statement-only storage engine. Set binlog_format to STATEMENT or migrate the affected tables to InnoDB to resolve the conflict.</p>
Cannot execute statement: impossible to write to binary
The error appears with the message "Cannot execute statement: impossible to write to binary log since statement is in row format and at least one table uses a storage engine limited to statement-based logging." MySQL refuses to proceed because it cannot safely record the transaction in its binary log.
The problem surfaces during INSERT, UPDATE, DELETE, or LOAD DATA operations when the server is configured for ROW or MIXED binlog_format, yet one of the referenced tables uses a storage engine that only supports STATEMENT logging, such as BLACKHOLE or MEMORY in older versions.
If the transaction is skipped, replication slaves will miss data changes, leading to drift between primary and replicas. This inconsistency can corrupt reports, backups, and failover procedures. Fixing the logging conflict preserves data integrity across the cluster.
Error Code: 1664. SQLSTATE: HY000. Condition Name: ER_BINLOG_ROW_INJECTION_AND_STMT_ENGINE. Scope: Binary logging and replication. Affected Versions: MySQL 5.7 and 8.0 when using row or mixed logging with statement-only engines.
Applications experience an immediate SQL exception, and the current transaction rolls back. High-throughput services may see elevated latency and retries until the underlying binlog configuration mismatch is corrected.
binlog_format is set to ROW or MIXED but some tables require STATEMENT logging, creating an unresolvable mismatch during runtime.
Tables stored in MEMORY, BLACKHOLE, or custom plugins that do not support row-based logging trigger the error whenever data-changing statements target them.
Developers sometimes switch binlog_format to ROW inside sessions for debugging, forgetting to revert it before running code that touches statement-only tables.
Stored procedures or triggers created under STATEMENT mode still operate, but servers later upgraded to ROW mode expose the conflict when they execute.
Occurs when the server cannot replicate because the binlog format differs between master and slave.
Raised when a row-based event is attempted in STATEMENT mode.
Indicates a conflict between storage engines when mixing row and statement replication types.
No. Ignoring it risks replication gaps and data loss on replicas.
BLACKHOLE, MEMORY in some versions, and custom engines that do not implement row events.
It resolves the error but reduces replication safety for non-deterministic queries. Prefer converting tables to InnoDB.
Galaxy flags errors instantly, offers AI-generated fixes, and lets teams convert engines or toggle binlog_format from an integrated, version-controlled editor.
.avif)
.avif){kind=logo}
