Airbyte MariaDB CDC resumes inside a row event and stalls every sync

Yesterday's incremental sync succeeded. Today every run fails before new rows land, while downstream reports quietly age. An Airbyte issue describes this pattern for a MariaDB source: the reporter traced a stored offset into a multi-event DELETE and the next run raised MissingTableMapEventException. That diagnosis belongs to the reported setup; a similar error in another installation still needs its own binlog evidence.

Preserve the recovery evidence

Record connector version, MariaDB version, connection state, last successful sync time, failing table, binlog file and position, and the exception trace. Back up the state and relevant database logs before changing either. Confirm that binlogs covering the checkpoint still exist and that database permissions have not changed. A retry that repeats the same error from the same offset is different from intermittent source availability.

Decide the recovery cost explicitly

Airbyte's MySQL source guidance and CDC overview explain state and snapshot behavior. Ask the connector maintainer or support team for a version-specific fix or safe state recovery path. Manually editing CDC state can skip changes or replay rows; do it only with a verified backup, an approved plan and a target reconciliation window. For a full refresh, estimate table size and downstream deduplication work first.

Reconcile after the first green run

Check row counts and high-water marks for affected tables, then sample business keys around the failure time. Compare deletes as well as inserts; a pipeline can appear fresh while retaining records that should have disappeared. Add a freshness alert that measures the time since the last data-changing sync, not merely whether the job scheduler ran.

Adovo’s view

The checkpoint is part of the data product. When it breaks, the first task is preserving what happened; the second is proving that recovery did not lose or duplicate the customer's history.