Kleppman p 707, links my own:
Change data capture makes one database the leader (the one from which the changes are captured), and turns the others into followers. A log-based message broker is well suited for transporting the change events from the source database to the derived systems, since it preserves the ordering of messages.
CDC usually requires a consistent snapshot
Using CDC as a source of truth results in a growing amount of computation needed any time we need to determine the current state of the database. As a compromise, we can maintain a consistent snapshot of the changes, either as a cache or as the foundation of the remaining changelog. This is a form of log compaction.
CDC and Event Sourcing
Change data capture is closely related to event sourcing, but operates at a different level of abstraction.
Kleppman p 713, links my own:
With event sourcing, events are modeled at a higher level: an event typically expresses the intent of a user action, not the mechanics of the state update that occurred as a result of the action. In this case, later events typically do not override prior events, and so you need the full history of events to reconstruct the final state. Log compaction is not possible in the same way.
Downsides:
See Downsides of event sourcing
CDC tools
General
The changelog has historically been an implementation detail of mainstream databases, so CDC frameworks needed to be built for each one.
PostgreSQL:
MySQL
MongoDB:
Oracle: