Skippr Docs

Appearance

How MySQL CDC Resume Behavior Works ​

May 2026

MySQL CDC resume behavior is based on binlog filename and position. Skippr stores both after each committed batch and restarts from there.

Short Answer ​

MySQL CDC resume behavior in Skippr uses the binlog filename and position. After each committed change batch, Skippr stores both values. On restart, it resumes the binlog stream from that stored position. When a stored position exists, the initial snapshot is skipped.

That is the key operational detail. Restart is not based on guessing what tables were already loaded. It is based on the exact binlog location that was committed after the last successful batch. Once that position is durable, the source feed can continue from the right place.

Why Teams Struggle with This ​

Restart stories often get muddled because teams combine snapshot logic and streaming logic in one mental model. The docs separate them clearly: when a stored binlog position exists, Skippr resumes the stream and does not repeat the initial snapshot.

  • The durable cursor is the pair of binlog filename and position.
  • That cursor is stored after each committed change batch.
  • Restart resumes from the stored binlog position rather than replaying the initial snapshot.
  • The general CDC guarantee still stops if source retention expires before the runner resumes.

How Skippr Handles It ​

Skippr keeps MySQL recovery simple because it leans on the native log position the source already exposes. There is no need to invent a softer notion of progress when the binlog already provides an exact location.

That also makes downstream reasoning cleaner. A committed warehouse apply can be tied directly to a committed source cursor, which is what you want when you are explaining restart behavior to an operator.

  • Binlog filename and position are stored after each committed batch.
  • Restarts resume the stream from that stored position.
  • The initial snapshot is skipped when a durable stream position already exists.
  • Resume behavior stays aligned with committed source progress.

What the First Useful Version Looks Like ​

MySQL restart behavior is easiest to trust when you think in exact binlog locations instead of in vague job history. The filename and position are the real cursor.

That is what makes restart both specific and explainable.