Skippr Docs

Appearance

What MySQL CDC Capture Shape Looks Like ​

May 2026

MySQL CDC capture shape is the row-based binlog. If you want trustworthy warehouse mutations, the key prerequisites are ROW format and FULL row images.

Short Answer ​

MySQL CDC capture shape in Skippr is the row-based binary log. The docs require binlog_format = ROW and binlog_row_image = FULL. Skippr reads WRITE_ROWS events as inserts, UPDATE_ROWS as updates with a full row image, and DELETE_ROWS as deletes.

A concrete example helps. If row id = 42 changes from status "trial" to "paid", the useful capture shape is a row-level update event with the information needed to build the after state for that row. That is why FULL row images matter. The warehouse needs row mutation meaning, not just a vague statement that some SQL ran.

Why Teams Struggle with This ​

MySQL CDC gets much easier to trust when you stop thinking in terms of query history and start thinking in terms of row events. The supported path is row-based replication, not statement replay.

  • CDC requires binlog_format = ROW, not statement-based logging.
  • The docs require binlog_row_image = FULL so the mutation has the row context needed for reconciliation.
  • The replication user needs REPLICATION SLAVE and REPLICATION CLIENT privileges.
  • The capture unit is the changed row, which is why the event names are WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS.

How Skippr Handles It ​

Skippr keeps the MySQL source contract explicit. The prerequisites, event types, and restart cursor are all documented in the source docs, so the team can verify that the feed is really shaped for CDC before it ever reaches the warehouse.

That is valuable because warehouse reconciliation is much simpler when the source is already delivering row-level insert, update, and delete meaning instead of leaving those semantics to inference.

  • MySQL CDC uses binlog replication with row-level events.
  • Supported captured events are WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS.
  • Updates rely on FULL row images for the right mutation context.
  • The resulting CDC stream carries mutation kind and native ordering metadata into the destination contract.

What the First Useful Version Looks Like ​

If your MySQL source is not configured for row-based logging with full row images, you do not really have the capture shape the warehouse wants.

Once those two settings are in place, the rest of the CDC path becomes much more legible.