<p>The server refuses to execute a statement because BINLOG_FORMAT=ROW while at least one referenced table uses a storage engine that only supports statement-based logging.</p>
<p>MySQL Error 1662: ER_BINLOG_ROW_MODE_AND_STMT_ENGINE occurs when a query is run with BINLOG_FORMAT set to ROW but involves a storage engine that supports only STATEMENT logging. Switch BINLOG_FORMAT to STATEMENT or MIXED, or move the table to a row-based engine to resolve the issue.</p>
Cannot execute statement: impossible to write to binary
The error message reads: Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = ROW and at least one table uses a storage engine limited to statement-based logging. MySQL halts the statement to preserve replication integrity.
The server cannot safely record row images for engines that do not implement the required row logging calls. For that reason, it blocks the operation instead of risking inconsistent replicas.
The error surfaces on servers with global or session BINLOG_FORMAT set to ROW while executing DML or DDL that touches a table using engines such as MEMORY, BLACKHOLE, or older NDB versions that lack full row logging support.
It is common during migrations, mixed engine deployments, or after changing the binlog format without auditing engine capabilities.
Replication stops if the offending statement executes on a primary but not on replicas. Production outages and data divergence can follow. Resolving the root cause restores safe binary logging and consistent replicas.
Row-based logging requires each storage engine to serialize before and after row images. Engines not compiled with this API cannot comply. Attempting row logging against such engines triggers the safeguard error.
Misconfigured session variables inside applications may switch BINLOG_FORMAT to ROW temporarily, exposing statements that run fine in mixed or statement mode during development.
Most teams either change BINLOG_FORMAT or migrate the table to a row-capable engine. Both approaches eliminate the format mismatch and let the statement proceed.
Bulk loading into a MEMORY table on a replica yields error 1662. Set session BINLOG_FORMAT=STATEMENT for that connection.
After upgrading to row-based replication, legacy BLACKHOLE logging tables start failing. Convert them to InnoDB or mark them replicate_ignore_table on replicas.
Audit engines before enabling ROW logging globally. Keep a checklist of non-row-safe engines and refactor them first.
Automate CI tests that run with BINLOG_FORMAT=ROW to catch incompatible storage engines early.
ERR_BINLOG_ROW_INVOCATION requires similar fixes by aligning engine capabilities with the chosen binlog format. Error 1595 (ER_BINLOG_LOGGING_IMPOSSIBLE) appears when binary logging itself is disabled for a temporary table.
These engines do not expose the row logging interface, so statements touching them fail in ROW mode.
Applications or stored procedures that set SET SESSION BINLOG_FORMAT=ROW trigger the error when touching incompatible tables.
Schemas migrated over time may quietly contain edge-case engines that become visible only after switching the global binlog format.
Promoting a replica with ROW format to primary while older engines exist introduces the error for write traffic.
Occurs when trying to log to the binary log for operations that bypass logging, such as on temporary tables.
Raised when a statement mixes row-based and statement-based changes that cannot be reconciled.
Appears if a trigger attempts row injection while the server uses STATEMENT mode.
Changing the global variable is dynamic but should be coordinated during low traffic to avoid inconsistent behavior across sessions.
MEMORY, BLACKHOLE, FEDERATED, and some third-party engines lack full row logging support.
Yes. Wrap critical statements with SET SESSION binlog_format and reset it afterward to minimize exposure.
Galaxy lets teams store endorsed snippets that enforce correct binlog settings, reducing human error during collaboration.
.avif)
.avif){kind=logo}
