Change data capture (CDC) records mutations to a configured table in a corresponding CDC log table. Instead of repeatedly scanning a large table to learn what changed, a consumer can query recorded changes over time and apply them to another system. section 12.1.2 section 12.3
CDC records changes, not a complete copy of each row. A log entry includes fields written by the mutation; a value left untouched by an UPDATE is not repeated merely because it exists in the base row. This makes the log useful for reconstructing a timeline of writes, but consumers must treat each entry as a change event rather than current row state. section 12.1.2 section 12.3
Using CDC involves a small set of database-aware steps:
- Enable CDC per table with the cdc table property; it can also be enabled when creating the table. section 12.1.2
- Find the generated CDC log table, which stores base-table fields alongside CDC metadata such as stream ID, time, batch sequence number, operation, and deletion markers. section 12.1.2
- Query changes by stream ID. Stream IDs are created for stream generations, so queries must account for multiple generations when topology changes. section 12.1.2 section 12.3
- Ingest the resulting events into a secondary store for exports, aggregation, analysis, or an audit-style history of who changed which fields. section 12.1.2
Tracking an author update
Enable CDC for the restaurant-review application's authors table, then insert Charlie Change with a name and bio. The CDC log receives an entry containing those written values. Updating only the bio produces another entry for the bio change; the name is absent from that update entry because the UPDATE did not change it. Adding an edited_by value on each write can let a downstream system build a timeline of article edits. section 12.1.2
cqlsh:reviews> DESCRIBE reviews;
...
CREATE TABLE reviews.authors_scylla_cdc_log ( #1
"cdc$stream_id" blob,
"cdc$time" timeuuid,
"cdc$batch_seq_no" int,
bio text, #2
"cdc$deleted_bio" boolean, #3
"cdc$deleted_elements_image" frozen<set<smallint>>,
"cdc$deleted_image" boolean,
"cdc$deleted_name" boolean,
"cdc$end_of_batch" boolean,
"cdc$operation" tinyint,
"cdc$ttl" bigint,
id timeuuid,
image frozen<image>,
name text,
PRIMARY KEY ("cdc$stream_id", "cdc$time", "cdc$batch_seq_no") #4
) WITH CLUSTERING ORDER BY ("cdc$time" ASC, "cdc$batch_seq_no" ASC)
...
The generated log-table definition makes CDC concrete: stream ID, time, and batch sequence number form its key, while operation and deletion fields describe the mutation alongside changed data. section 12.1.2
