@kapa.ai What would happen if I modified a MySQL daily sync

Full Refresh - Append

non-cdc source connector to become an

Incremental - Append

with cdc? The destination is a Snowflake direct-load final table.

Here's what you should expect when switching from Full Refresh - Append (non-CDC) to Incremental - Append with CDC on a MySQL source syncing to Snowflake: First Sync After the Change The first sync after enabling CDC will perform an initial snapshot — essentially a full refresh via a

SELECT

statement — to capture the current state of all selected tables. This is equivalent to a Full Refresh and establishes the baseline log position. [CDC docs] Subsequent Syncs After the snapshot, Airbyte will read from MySQL's binary logs (binlog) to detect

INSERT

,

UPDATE

, and

DELETE

changes since the last sync position, rather than re-reading the entire table. [CDC docs] Key behavioral differences from your previous setup: • No cursor field required — CDC uses the binlog position instead of an

updated_at

-style cursor. [MySQL CDC tutorial] • Deletions are captured — CDC logs

DELETE

statements, which standard incremental sync cannot detect. Records deleted at the source will appear in the destination with a populated

_ab_cdc_deleted_at

metadata column. [CDC docs] • Intermediate changes are captured — If a record is updated multiple times between syncs, all intermediate changes are logged and transmitted, unlike cursor-based incremental sync. [CDC tutorial] • Added metadata columns — Records will include

_ab_cdc_

prefixed columns such as

_ab_cdc_log_file

,

_ab_cdc_log_pos

,

_ab_cdc_updated_at

, and

_ab_cdc_deleted_at

. [CDC docs] Impact on Your Snowflake Destination (Incremental - Append) Since you're using Append mode (not Deduped), records from

UPDATE

and

DELETE

statements will be appended as new rows — they will not overwrite or remove existing rows. This means: • Your Snowflake table will accumulate multiple versions of the same record over time. • Deleted records won't disappear from the table; instead, a new row with

_ab_cdc_deleted_at

populated will be appended. [CDC docs] Important Limitations to Be Aware Of • Primary keys required: CDC incremental is only supported for tables that have primary keys. Tables without primary keys can only be synced as Full Refresh. [CDC limitations] • Binlog retention: You must ensure your MySQL binlog retention period is long enough to cover the interval between syncs (daily in your case). If the binlog is purged before the next sync, the sync will fail. • `TRUNCATE`/`ALTER` not captured: Changes made via

TRUNCATE

or

ALTER

won't appear in the logs and won't be replicated. [CDC limitations] • New tables/columns: Any new tables or columns added after the initial snapshot require a manual refresh before CDC begins tracking them. [CDC limitations] Summary 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai and what happens to the existing final tables on that first sync after changing the source connector?

The knowledge sources do not contain enough information to answer this with full confidence for your specific scenario (switching sync modes on an existing connection with a Snowflake direct-load destination). However, based on what the knowledge sources do say: What We Know Incremental - Append mode never deletes or mutates existing rows. Since you're using Append (not Overwrite), the existing rows in your Snowflake final table should not be wiped. New rows from the CDC initial snapshot will be appended to the existing table. [Incremental Append docs] The initial CDC snapshot is a full

SELECT

of the source tables, so you will likely end up with duplicate rows in your Snowflake table — the data already there from your previous Full Refresh - Append syncs, plus the newly snapshotted rows appended on top. [CDC docs] *New metadata columns (

_ab_cdc_*

) will be added* to records going forward. Existing rows in the destination that were written before the switch will not have these columns populated. This schema change may trigger Airbyte to alter the destination table structure. What Is Uncertain • Whether the Snowflake direct-load connector handles the schema change (adding

_ab_cdc_*

columns) via an

ALTER TABLE

or by recreating the table. The knowledge sources note that direct-load connectors use

ALTER TABLE

for schema evolution, but that this can fail in some edge cases. [Direct load docs] • Whether Airbyte treats this mode switch as requiring a soft reset/table recreation. Recommendation Given the risk of duplicates and schema changes, you may want to: 1. Clear or back up your existing Snowflake table before making the switch, to avoid a messy mix of pre-CDC and post-CDC rows. 2. Monitor the first sync closely for any schema evolution errors on the Snowflake side. For a definitive answer on the exact destination table behavior, I'd recommend checking with Airbyte support or the Airbyte community forum. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.