liveBook · Manning

Change-data-capture

As explained in Apache Kafka in Action

Change data capture is a technique that monitors and records changes made to a data source rather than repeatedly reading its complete current contents.

A core system may need to feed new applications without being repeatedly queried or modified for each one. Change data capture (CDC) monitors changes to its data rather than repeatedly reading the complete current contents. For a relational database, a connector can follow the transaction log, where changes are recorded, and send the resulting data to Kafka. section 11.9 section 18.2

Why not just poll a table? A JDBC Source Connector can track an incrementing column or timestamp, but those choices can miss changes. An update to an existing row does not give it a new ID; two changes sharing a timestamp can also cause one to be skipped. JDBC bulk mode reloads the entire table and is inefficient. A CDC connector such as Debezium addresses the change-tracking problem instead. section 11.8.3 section 11.10

For a PostgreSQL-to-Kafka setup:

  • Set PostgreSQL’s wal_level to logical and restart the server so the connector can monitor the necessary changes. section 11.9.1
  • Create a database user with REPLICATION privilege, then install and configure the Debezium connector. section 11.9.1
  • Configure database connection details and table filtering; use topic.prefix to organize generated Kafka topic names and avoid conflicts. section 11.10
# Linux file path: /etc/postgresql/<version>/main/postgresql.conf
# Windows file path: C://Programs/PostgreSQL/<version>/data/postgresql.conf
wal_level = logical

The PostgreSQL configuration line needed before the Debezium connector can monitor changes. section 11.9.1

Getting changes into Kafka is not the same as making them ready for other teams. Core-system data may retain unfamiliar formats and be spread across many normalized tables. Build new, usable data structures from the captured data rather than asking downstream applications to consume the raw tables directly; consolidation can require substantial joins and state stores. section 18.2 section 18.6

How Apache Kafka in Action covers it

How deep it goes
Defines change monitoring, contrasts it with JDBC polling, and walks through PostgreSQL preparation; leaves Debezium installation to its documentation.
Examples
Uses missed timestamp-based changes and a PostgreSQL customers table with a Debezium connector.
What it assumes
Assumes familiarity with relational tables and connector configuration while showing the PostgreSQL database, user, and table setup.
What you can do after
Operate/configure it with Debezium and PostgreSQL, while recognizing why raw captured tables need downstream restructuring.
How it connects
Connects CDC to transaction logs, Kafka Connect, JDBC source connectors, and downstream data modeling.

Also explained in

Compare how 5 books explain change-data-capture →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Apache Kafka in Action. The section links point to the parts of the book it draws on.