Skippr Docs

Appearance

MySQL CDC to Redshift Final State Guide ​

June 2026

MySQL to Redshift works when the binlog stream and the Redshift staging-plus-MERGE path share one view of row ordering.

Short Answer ​

MySQL CDC to Redshift works by reading MySQL WRITE_ROWS, UPDATE_ROWS, and DELETE_ROWS events, staging those changes in Redshift through the COPY workflow, and then reconciling the target table with MERGE. Skippr creates a _skippr_order_token VARCHAR(MAX) column and a tombstone table automatically so Redshift can reject stale replays for the same key.

A concrete example is subscriptions.id 64 being deleted after a cancellation. MySQL emits DELETE_ROWS, Skippr records that mutation with its order token, and Redshift writes the tombstone and removes the row in the final-state table. If an older insert for id 64 is replayed later, the tombstone prevents it from coming back.

Why Teams Struggle with This ​

This pipeline depends on two kinds of durability at once. MySQL provides the binlog filename and position for restart safety, while Redshift depends on a staging S3 bucket, prefix, and IAM role so the COPY and MERGE steps can finish cleanly.

  • MySQL must emit ROW binlog events with FULL row images.
  • The replication user needs REPLICATION SLAVE and REPLICATION CLIENT privileges.
  • Redshift MERGE correctness depends on the staged batch and the order-token guard, not on when files happen to land in S3.
  • Deletes rely on tombstones to keep replayed older inserts from restoring removed rows.

How Skippr Handles It ​

Skippr keeps the pipeline explicit from source through warehouse. It stores the MySQL binlog filename and position after each committed batch, stages the batch for Redshift with the documented COPY workflow, and then uses MERGE with order-token comparison so newer mutations win. The delete path gets the same protection through tombstones.

That gives teams a pipeline they can debug with evidence instead of intuition. You can trace the source row event, the staging boundary, and the final MERGE decision that produced the current Redshift row state.

  • MySQL row-event CDC with durable binlog-position resumes.
  • Redshift staging through COPY before MERGE reconciliation.
  • Order-token guards on upserts so stale writes lose.
  • Tombstone tables for delete protection.

What the First Useful Version Looks Like ​

This integration fits teams that already query Redshift and want current-state tables sourced directly from MySQL changes.

The most important early check is whether the Redshift merge key and the MySQL row identity are truly the same thing.