While we recommend using the default configurations for schema management for all tables, we understand that isn’t always possible for every environment. A common question we often see is how does one snapshot newly added tables, particularly if the connector is configured using store.only.captured.tables.ddl as true.

In this update, we have simplified the process where you can update your connector configuration with the new table, and once the connector task has restarted, sending an ad-hoc blocking snapshot signal will be permitted even on tables that are unknown but match the capture filters (DBZ-4903).

When processing change events, users can control how the connector reacts to specific event handling failures using event.processing.failure.handling.mode; however, this has traditionally only been applicable for streaming changes.

There are some corner cases where emitting snapshot events could also raise failures. To improve this experience, the event.processing.failure.handling.mode now influences failures when dispatching snapshot events, too (DBZ-8433).

When a Debezium source connector starts, it logs all connector configurations. This is very helpful for both the team when diagnosing problems but also for users to identify that their configurations are being understood properly.

In this update, the logging for the connector configuration has changed slightly. You will notice rather than placing each configuration property as a new log entry, each key/value will be appended together separated by new lines, and added to the log as a single entry. This makes it easier to identify these log lines and for tooling to exclude such log entries easier if needed (DBZ-8472).

PostgreSQL 17 introduces a long awaited feature called fail-over for replication slots.

When the replication slot is created, a new property can be specified to enable the replication slot to be created and available on the fail-over replica. The synchronization of the fail-over replication slot can be performed manually by calling pg_sync_replication_slots() or automatically by enabling the sync_replication_slots feature.

When automatic synchronization is enabled, this allows Debezium to consume from that slot immediately on fail-over to the replica and not miss any events.

To take advantage of this new feature, your connector must be configured with slot.failover set to true. Debezium must be connecting to PostgreSQL 17+ and the primary on the cluster, otherwise no fail-over replication slot will be created (DBZ-8412).

A partial rollback event is something unique to Oracle where a user performs an operation, it gets recorded as being performed in the transaction logs, but then a validation check forces the operation to be undone and rolled back. One of the most notable ways to trigger partial rollbacks are with constraint violations.

The new JMX metric, NumberOfPartialRollbackCount, tracks the frequency of this event sequence in the transaction logs (DBZ-8491).

When using Debezium to capture changes from an Oracle database that interacts with Oracle GoldenGate, you may have observed some situations where the low watermark in the offsets did not advance across restarts. This was especially the case when setting lob.enabled to true.

In this update, the Debezium Oracle connector will now skip GoldenGate’s replication marker events, which will prevent those synthetic transactions from cluttering the transaction buffer and forcing users to rely on transaction retention (DBZ-8533).

Several new improvements have been added to Vitess to make the parsing and handling of DDL changes more fault-tolerant (DBZ-8479). These improvements include:

We have improved the Kubernetes Operator by introducing support for the JDBC storage module, allowing it to be configured via the CRD.

In the offset schema reference, a new property section called jdbc has been added, which describes the JDBC offset backing store properties. In the schema history reference, a new property section called jdbc has been added, which describes the JDBC schema history store properties.

This allows users to store offsets and schema history details for a connector deployed using the Debezium Operator in a JDBC data store easily (DBZ-8501).