Skippr Docs

Appearance

What Access Skippr Needs to Read from MySQL ​

June 2026

MySQL access depends on whether you are only reading tables or also asking Skippr to act as a replication client for CDC.

Short Answer ​

Skippr needs a MySQL connection string and a user that can read the selected tables for normal extraction. If you enable CDC, the requirement gets stricter: MySQL must use binlog_format = ROW and binlog_row_image = FULL, and the replication user must have REPLICATION SLAVE and REPLICATION CLIENT privileges so Skippr can read row-level binlog events.

That distinction matters in real environments. A user might read customers and orders from appdb perfectly well through mysql://reader@host:3306/appdb, yet still be unable to stream updates because the server is not emitting the right binlog format or the account was never granted replication privileges.

Why Teams Struggle with This ​

MySQL often looks ready after the first successful query, but CDC is a different access story. Table reads prove the login and network path; they do not prove that the server will emit complete row-change events or allow Skippr to attach as a replication client.

  • Normal extraction needs read access to the selected tables in the configured database.
  • CDC requires binlog_format = ROW and binlog_row_image = FULL, or the emitted changes will not carry the full row information Skippr expects.
  • The replication user needs both REPLICATION SLAVE and REPLICATION CLIENT privileges.
  • If you pass a narrow tables list, any table outside that list is intentionally out of scope even when the user could read it.

How Skippr Handles It ​

Skippr keeps the MySQL access model readable because the same source definition works for table extraction and, when enabled, binlog-based CDC. That helps setup reviews because you can say exactly what changed when the pipeline graduates from batch reads to streaming row mutations.

Operationally, the CDC guide fills in the missing server-side pieces: Skippr stores the binlog filename and position after each committed batch and resumes from there, so the replication privileges and binlog configuration are not optional details. They are part of the correctness model.

  • Uses a standard MySQL connection string rather than custom auth fields.
  • Supports readable table lists or auto-discovery for batch extraction.
  • Consumes row-level binlog events when CDC is enabled.
  • Stores binlog filename and position for restart continuity.

What the First Useful Version Looks Like ​

The first useful version is one readable database and one short table list so you can confirm row counts and schema shape before you touch CDC.

If the real goal is change capture, verify the binlog settings and replication grants early, because a healthy read-only login still is not enough for a durable CDC source.