Skippr Docs

Appearance

MySQL CDC to Synapse Final State Guide ​

June 2026

MySQL to Synapse works when binlog row events are translated into deterministic MERGE decisions instead of append-only loads.

Short Answer ​

MySQL CDC to Synapse works by reading WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS from the MySQL binlog and applying them with Synapse MERGE statements. Skippr adds a _skippr_order_token NVARCHAR(4000) column and companion tombstone table automatically so Synapse only updates a row when the incoming token is newer than the one already stored for that key.

For example, if leads.id 44 changes stage from "qualified" to "proposal", MySQL emits UPDATE_ROWS with the full row image and Skippr carries that mutation into Synapse. The MERGE updates the target row only when the new token wins. If DELETE_ROWS arrives later for id 44, Synapse records the tombstone and removes the row from the target table.

Why Teams Struggle with This ​

This integration spans two different operational models. MySQL requires replication privileges plus row-based binlog settings, while Synapse requires a valid ADO.NET connection string and write access to the target schema before MERGE can maintain final state correctly.

  • MySQL CDC requires ROW binlog format and FULL row images.
  • The replication client must have REPLICATION SLAVE and REPLICATION CLIENT privileges.
  • Synapse final-state correctness depends on token-guarded MERGE rather than on batch arrival order.
  • Deletes still need tombstones so replayed older inserts do not recreate removed keys.

How Skippr Handles It ​

Skippr keeps the integration auditable. It stores the MySQL binlog filename and position after each committed batch, then applies the same mutations in Synapse with MERGE, order-token comparison, and tombstone tracking. That gives the destination a deterministic answer when multiple mutations compete for the same key.

Because the path is explicit, you can investigate a wrong row by checking the source event type, the stored ordering point, and the destination token comparison instead of reverse-engineering warehouse history.

  • MySQL binlog CDC with durable resume positions.
  • Synapse MERGE reconciliation guarded by _skippr_order_token.
  • Automatic tombstone tables for delete handling.
  • A documented path from row events into current-state Synapse rows.

What the First Useful Version Looks Like ​

Use this integration when Synapse is the warehouse consumers query and MySQL remains the live OLTP source.

The integration becomes much easier to trust once every team member can explain why a specific UPDATE_ROWS event won or lost in Synapse.