docusaurus/platform_versioned_docs/version-2.0/understanding-airbyte/cdc.md
Many common databases support writing all record changes to log files for the purpose of replication. A consumer of these log files (such as Airbyte) can read these logs while keeping track of the current position within the logs in order to read all record changes coming from DELETE/INSERT/UPDATE statements.
The orchestration for syncing is similar to non-CDC database sources. After selecting a sync interval, syncs are launched regularly. We read data from the previously synced position in the logs up to the start time of the sync. We do not treat CDC sources as infinite streaming sources. You should ensure that your schedule for running these syncs is frequent enough to consume the logs that are generated. The first time the sync is run, a snapshot of the current state of the data will be taken. This snapshot is created with a SELECT statement and is effectively a Full Refresh (meaning changes won't be logged). Subsequent syncs will use the logs to determine which changes took place since the last sync and update those. Airbyte keeps track of the current log position between syncs.
A single sync might have some tables configured for Full Refresh replication and others for Incremental. If CDC is configured at the source level, all tables with Incremental selected will use CDC. All Full Refresh tables will replicate using the same process as non-CDC sources.
The Airbyte Protocol outputs records from sources. Records from UPDATE and DELETE statements appear the same way as records from INSERT statements. We support different options for how to sync this data into destinations using primary keys, so you can choose to append this data, delete in place, etc.
We add some metadata columns for CDC sources which all begin with the _ab_cdc_ prefix. The actual columns synced will vary per source, but might look like:
_ab_cdc_lsn of _ab_cdc_cursor the point in the log where the record was retrieved_ab_cdc_log_file & _ab_cdc_log_pos (specific to mysql source) is the file name and position in the file where the record was retrieved_ab_cdc_updated_at is the timestamp for the database transaction that resulted in this record change and is present for records from DELETE/INSERT/UPDATE statements_ab_cdc_deleted_at is the timestamp for the database transaction that resulted in this record change and is only present for records from DELETE statementsDELETE/INSERT/UPDATE. For example, changes made from TRUNCATE/ALTER won't appear in logs and therefore in your destination.When using CDC, each schema included in the sync will first undergo an initial snapshot (equivalent to a full refresh).
If you create a new schema/column that is not yet being synced, it must first be snapshotted before CDC can begin tracking changes. Upon schema updates, you should see a Schema changes detected notice in the Schema section. If the schema/column is not visible, click Refresh source schema to retrieve the latest structure from your source.
CDC tracks changes only for schemas that are included in the sync. To add a new schema/column:
To avoid unintentional sync issues, we recommend enabling Approve all schema changes myself under the
Detect and propagate schema changes in the Setting section. This prevents newly added detected changes from being included in the sync without a proper snapshot,
reducing the risk of LSN issues and sync failures.
:::tip
Adding new schemas/columns to a CDC-enabled database does not automatically enable CDC tracking on them. We recommend manually verifying that CDC is enabled on any newly added database objects. Since each source database uses different commands to configure and verify CDC, be sure to follow the appropriate steps for your specific database. For an example of how to enable CDC on a new schema in MSSQL, visit our MSSQL Troubleshooting page.
:::