How to Fix MySQL Binlog Row Format Not Enabled

May 2026

MySQL binlog row format not enabled usually means the server is logging changes in a way that is too thin for row-level CDC.

Short Answer

A MySQL binlog row format not enabled error usually means the server is not using binlog_format = ROW, which is the mode a row-level CDC consumer expects. Skippr reads row events from the binlog. If MySQL is configured for STATEMENT or MIXED, the server may still be writing binlogs, but not in the row-by-row shape the CDC path needs.

That distinction matters most on updates and deletes. A row-based event tells the consumer which row changed and, with the right companion setting, what the row image looks like. A statement-based event only tells you the SQL that ran. UPDATE orders SET status = "shipped" WHERE id = 42 is useful to MySQL, but it is not the same thing as a durable row mutation contract for downstream final-state tables.

Treat this as a source-side prerequisite problem, not a warehouse problem. If MySQL is not emitting row events, no amount of downstream merge logic will make the CDC path trustworthy.

Why This Error Happens

Teams often assume "binlog enabled" is enough for CDC. It is not. The important question is how the binlog records changes. For row-level CDC, the logging format has to preserve row mutations directly.

This error also tends to travel with another MySQL setting: binlog_row_image = FULL. Even after switching to ROW, a partial row image can make updates and deletes harder to reconcile because the downstream consumer no longer sees the complete before-and-after shape the docs call for.

• MySQL is running with binlog_format = STATEMENT or binlog_format = MIXED instead of ROW.
• The team enabled binary logging but did not configure the server specifically for row-level CDC.
• The server changed to ROW, but binlog_row_image = FULL was not verified alongside it.

How to Fix It with Skippr

Start by checking the live server variables rather than the config file you expect to be active. On managed databases and long-lived servers, the running values are what matter. If SHOW VARIABLES LIKE "binlog_format"; returns anything other than ROW, fix that first.

Then check binlog_row_image. If a pipeline is supposed to carry inserts, updates, and deletes cleanly into a final-state destination, FULL is the safe setting because it preserves complete row images. Once those two settings are right, the rest of the MySQL CDC setup becomes much easier to reason about.

• Run SHOW VARIABLES LIKE "binlog_format"; and confirm the server is using ROW.
• Run SHOW VARIABLES LIKE "binlog_row_image"; and confirm it is set to FULL.
• If needed, update my.cnf or the managed MySQL parameter group so the server uses row-based binlogging, then restart if the platform requires it.
• Verify the replication user still has REPLICATION SLAVE and REPLICATION CLIENT privileges.
• Reconnect the MySQL source and retry the CDC pipeline.

When Skippr Is the Better Path

Skippr helps here because the CDC contract is explicit: MySQL CDC depends on binlog replication with row-level events, not on a vague promise that binary logging exists somewhere. That makes the source check fast and concrete.

Once MySQL is emitting the right event shape, the same project can keep moving into destination reconciliation and generated dbt setup without a second translation layer.