CDC is not a connector install. It is a recovery design that defines what happens when a source fails, a schema changes, or a consumer falls behind. This 2026 guide shows how to set up change data capture for databases with Debezium and Kafka Connect without burdening your OLTP primary.

TL;DR

• For how to set up change data capture for databases in 2026, start with a recovery design, not a connector configuration.
• Use Debezium with Kafka Connect for MySQL, PostgreSQL, and MongoDB when Kafka is your event backbone.
• A Debezium MySQL schema-history topic needs exactly one partition; losing its history breaks restart recovery.
• Choose an initial snapshot only when consumers need existing rows; use incremental snapshots for large live datasets.
• Release only after restart, schema-change, and consumer-replay tests pass.

Why this matters

Polling tables and dual-writing from the application create different kinds of failure: polling misses the ordering boundary, while dual writes leave the database and downstream system disagreeing after a partial failure. CDC reads committed changes from the source log and gives each downstream system the same ordered record of that change.

That still does not make CDC safe by default. In 2026, the real production risks are a lost MySQL schema-history topic, a PostgreSQL replication slot retaining WAL until a disk fills, and a consumer that cannot replay idempotently. The connector is the small part; the operating model is the work.

For Mydbops managed database services teams, CDC belongs in the same change-control process as replication, backup recovery, and database upgrades. A 15-minute response target is useful only when the team already knows which offset, log position, topic, and consumer group defines the affected boundary.

Start with the recovery design

Do these four decisions before enabling a binlog, WAL setting, or change stream. They prevent the generic “connect and hope” rollout that fails during the first schema deployment.

Define the source of truth

Write down the source tables or collections, the owning service, the event consumers, and the retention period each consumer needs. A CDC topic is not an archive unless you explicitly provision it as one.

Use a table or collection allowlist from day one. Capturing every non-system object creates expensive snapshots, exposes fields that no consumer needs, and makes later ownership unclear. The expected result is a short, reviewed capture contract, not a wildcard connector.

Define the replay boundary

Choose the point from which a failed consumer can rebuild state: Kafka retention, an immutable sink, or a controlled re-snapshot. Then make every consumer idempotent using the source primary key or document identifier.

Do not promise exactly-once business outcomes merely because the connector stores offsets. A consumer must tolerate a repeated change event after a restart, rebalancing event, or replay. In 2026, an upsert keyed on the source identifier is the practical baseline for materialized views, search indexes, and cache projections.

Assign the failure owner

Name one owner for source-log retention, connector health, topic retention, schema compatibility, and each consumer group. Mydbops recommends that the database owner covers source-log and replication-slot checks while the event-platform owner covers connector tasks and Kafka topics.

What you'll need

• Kafka Connect workers with the engine-specific Debezium connector installed
• A Kafka cluster and persistent storage for connector offsets
• A reviewed table or collection allowlist and unique topic.prefix
• A dedicated, least-privilege database identity for the connector
• Network access from the Connect workers to the source database and Kafka brokers
• A consumer contract covering keys, deletes, schema changes, replay, and ownership
• Alerting for connector state, source-log or WAL pressure, consumer lag, and topic storage
• A maintenance window when changing source configuration requires a restart

Build the pipeline in seven controlled moves

1. Map the event contract before the source configuration

For each captured object, record its key, deletion behavior, restricted fields, consumer owner, and rebuild path. Decide whether the consumer needs before values, after values, or both before registering the connector.

Common mistake: publishing raw events before consumers have a compatibility policy.

2. Prepare the engine-specific log path

Use the branch that matches the production source. Do not apply MySQL settings to PostgreSQL or treat a MongoDB standalone server as a CDC source.

MySQL and MariaDB

Enable binary logging and use row-based events. For Debezium MySQL capture, set binlog_format=ROW; use binlog_row_image=FULL when consumers need complete before and after images rather than changed columns only. Confirm that binlog retention exceeds the longest credible connector outage plus the time needed to decide whether to recover or re-snapshot.

Create a dedicated account with the required replication and read permissions for the captured schemas. Where the environment uses GTIDs and high availability, document the source instance and failover sequence before go-live.

Expected outcome: a connector can read a consistent starting position and continue from the stored binlog offset after a restart.

PostgreSQL

Set wal_level=logical, size max_replication_slots and max_wal_senders for the connector, and create a dedicated replication user. Use the native pgoutput plug-in for PostgreSQL 10 and later unless a specific compatibility requirement says otherwise.

A logical replication slot retains WAL until the consumer advances. Monitor retained WAL and replication slots as a capacity risk, not just a CDC metric; an unavailable connector can consume the filesystem that the database needs to operate.

Expected outcome: the connector can create or use a replication slot and publication, then resume from its recorded LSN after a controlled restart.

MongoDB

Use a replica set or sharded cluster. A standalone MongoDB server has no oplog and cannot support the Debezium MongoDB connector. A production replica set should have at least three members, and the connection string must describe the replica-set topology rather than one host.

The connector reads MongoDB change streams and resumes from recorded oplog positions. If the oplog no longer holds that position, it must establish a new snapshot boundary.

Expected outcome: a forced primary election or temporary worker loss reconnects without silently switching to a different data contract.

3. Choose the initial state deliberately

Use snapshot.mode=initial when consumers require existing rows before processing future changes. The initial snapshot establishes a consistent baseline, then the connector streams from the log position captured at that boundary.

For large, busy tables, prefer an incremental snapshot over an uncontrolled full scan when your connector and source support it. Debezium documents a default chunk size of 1,024 rows for PostgreSQL and MongoDB incremental snapshots; set a lower or higher value only after measuring source load and completion time.

Do not run an initial snapshot against a write-heavy primary without a source-load plan. In 2026, a clean snapshot strategy is more valuable than a faster connector configuration because it determines whether recovery is possible without production impact.

Common mistake: treating a snapshot as a one-time data load. Snapshot READ events share a topic with later change events, so consumers need to handle both states correctly.

4. Register a narrow connector

Configure topic.prefix as a stable, unique source name and use include lists for databases, schemas, tables, or collections. Set the connector identity, source hostname, and capture allowlist explicitly; avoid broad defaults that expand when a new database object appears.

Start with one bounded source domain and a small task count. More workers will not fix a blocked snapshot, slow source log, or weak Kafka capacity.

Expected outcome: the connector reaches RUNNING and only approved objects emit events.

5. Protect offsets and schema history as recovery assets

Kafka Connect offsets identify where the connector resumes. Treat the offset storage topic as protected production state: retain it, back it up according to the event platform’s recovery policy, and never delete it during routine troubleshooting.

For Debezium MySQL, the internal schema-history topic is equally important. It contains the DDL history needed to reconstruct the table shape at a prior binlog position. Configure it with exactly one partition so event order remains global, and prevent retention from silently removing the history required after a restart.

Do not expose the internal schema-history topic as an application contract. If applications need DDL notifications, use a consumer-facing schema-change stream or a separately governed schema registry.

6. Prove the three failure paths

Run these tests in staging before any production cutover, then repeat the relevant tests after a major source upgrade.

1. Connector restart: stop a worker, restart it, and verify that the connector resumes from its stored position without a full unexpected snapshot.
2. Schema change: add a compatible column, confirm the event shape, then verify that every consumer either accepts the field or ignores it safely. Apply the same release discipline used for automated database schema migrations.
3. Consumer replay: reset a non-production consumer group to a known point and confirm its writes are idempotent.

Add a fourth test for your engine’s likely infrastructure failure: a MySQL source switch, PostgreSQL slot recovery, or MongoDB primary election. Use an automated failover-testing runbook to record the recovery boundary. The expected result is not simply “the connector is green”; it is a documented recovery time and no unaccounted event gap.

7. Release with operating gates, not optimism

Release only when source-log headroom, connector state, offsets, and consumer replay are visible to their named owners.

Use these gates:

• Captured objects match the reviewed allowlist
• Snapshot completion is confirmed and baseline events are understood
• Offsets and MySQL schema history are protected
• Lag budget and alert threshold are assigned per consumer group
• Connector restart and consumer replay tests have evidence
• The rollback action is written before the first production change

Mydbops Remote DBA teams should review these gates with the application and event-platform owners before connecting CDC to a compliance-sensitive production database.

Troubleshooting by failure signature

• Connector starts but emits nothing: check the capture allowlist, source-log settings, grants, and source object names. For PostgreSQL, verify the publication and replication slot; for MongoDB, verify the replica-set or sharded-cluster connection string.
• Restart triggers a snapshot: compare stored offsets with available binlog, WAL, or oplog history. The old source position or the offset state is missing; establish whether consumers can safely accept a re-snapshot.
• PostgreSQL disk use rises: inspect replication-slot activity and retained WAL. Restore a connector only after it can process its backlog; dropping a slot discards its recovery position.
• MySQL fails after DDL: inspect the single-partition schema-history topic before rebuilding. Recover its ordered DDL history before clearing offsets or changing snapshot mode.
• Replay creates duplicates: use upserts or deduplication keyed on the source primary key or document identifier.
• Snapshot affects the primary: narrow capture scope or move to an incremental snapshot where supported, then measure source load before retrying.

Tools and resources

• Debezium and Kafka Connect for capture, offsets, and connector lifecycle
• Kafka topic policies and a schema registry for replay and consumer compatibility
• Source monitoring for MySQL binlogs, PostgreSQL WAL and replication slots, or MongoDB oplog capacity
• Mydbops managed database services for database-level review and failover planning

What to do next

Run a one-source pilot with one operational consumer and one analytical consumer. Keep the source allowlist small, capture the restart and replay evidence, then extend the pattern to the next domain only after the first pipeline has survived an intentional failure test.

FAQ

What is the best way to set up change data capture for databases in 2026?

Use Debezium with Kafka Connect when MySQL, PostgreSQL, or MongoDB changes must enter Kafka as ordered events. Start with the recovery and consumer-replay design before configuring the connector.

Does CDC replace batch ETL?

CDC replaces batch extraction when downstream systems need committed changes quickly. Batch jobs still fit large periodic transformations and reporting that does not need event-level latency.

Does MySQL need row-based binlogs for Debezium CDC?

Yes. Debezium MySQL capture requires row-based binary log events, so set `binlog_format=ROW` before deploying the connector.

What does PostgreSQL need for CDC?

PostgreSQL CDC requires logical decoding, a replication user, a replication slot, and a publication for the captured tables. Monitor retained WAL because an inactive slot can consume disk capacity.

Can a standalone MongoDB server use CDC?

No. A standalone MongoDB server has no oplog, so the Debezium MongoDB connector requires a replica set or sharded cluster.

Why does a Debezium connector take an initial snapshot?

The initial snapshot establishes a consistent baseline of existing rows before the connector streams later changes. Consumers must recognize snapshot `READ` events alongside ongoing change events.

How do you avoid duplicate CDC events?

Make downstream consumers idempotent with the source primary key or document identifier. A restart or replay can legitimately present the same change more than once.

What is the most important Debezium MySQL recovery setting?

Protect the internal schema-history topic and keep it to one partition. The connector uses its ordered DDL history to reconstruct table state after a restart.

Build CDC for recovery, not just speed

The strongest CDC design question is not “how quickly can this connector start?” It is “which exact source position, topic, and consumer state can reconstruct the system after a bad deployment?” Answer that before production, and your CDC pipeline becomes an operating capability rather than another fragile integration.

Review your CDC recovery design

Have a certified remote DBA assess source-log settings, connector recovery, and production failure paths.