Debezium recently introduced the JDBC storage module that allows you to store offsets and schema history data inside a relational database. The JDBC storage module used UTF-16 as its default encoding; however, most databases use UTF-8. This release of Debezium aligns the JDBC storage module’s encoding to use UTF-8 moving forward.

Debezium 2.3 introduces a new PostgreSQL connector feature called "Autoset Replica Identity".

Replica identity is PostgreSQL’s way to identify what columns are captured in the database transaction logs for inserts, updates, and deletes. This new feature allows configuring a table’s replica identity via connector configuration and delegating the responsibility of setting this configuration to the connector at start-up.

The new configuration option, replica.identity.autoset.values, specifies a comma-separated list of table and replica identity tuples. If the table already has a given replica identity, the identity will be overwritten to match what is specified in this configuration if the table is included. PostgreSQL supports several replica identity types, more information on these can be found in the documentation.

When specifying the replica.identity.autoset.values, the value is a comma-separated list of values where each element uses the format of <fully-qualified-table-name>:<replica-identity>. An example is shown below where two tables are configured to have full replica identity:

Be mindful that if the user account used by the connector does not have the appropriate database permissions to set a table’s replica identity, the use of this feature will result in a failure. In the event of a failure due to permissions, you must make sure the proper replica identity is set manually using a database account with the right permissions.

Debezium 2.3 introduces a new notification and channels subsystem. This subsystem allows you to send a signal via a variety of channels that include the filesystem, Kafka topic, and database table out of the box; however, the feature is extendable. In addition, this subsystem also includes the ability to send notifications about the status of the initial snapshots and incremental snapshots if they’re used. These notifications can help facilitate an easier line of communication between Debezium and other third-party systems that may need to know when an incremental or traditional snapshot has finished and whether it finished successfully or not.

In this release, the notification and channels subsystem has been improved to correlate the signal to the notification. So when you send a signal and it is consumed by Debezium, any notification that is raised will contain a reference to the signal, allowing any third-party or external process to know precisely which signal the notification references.

This should help close the gap in distribution communications across applications or processes relying on the new notification and channel subsystem.

There were quite a number of bugfixes and stability changes in this release, some noteworthy are:

Altogether, 22 issues were fixed for this release. A big thank you to all the contributors from the community who worked on this release: Angshuman Dey, Anisha Mohanty, Chris Cranford, Harvey Yue, Ismail Simsek, Jakub Cechacek, Jiri Pechanec, Jochen Schalanda, Kanthi Subramanian, Mario Fiore Vitale, Martin Medek, and Vojtech Juranek!

With Debezium 2.3 being released under a condensed schedule, you can expect the next CR1 release within the next 1-2 weeks. The plan is to release Debezium 2.3.0.Final in the middle of June and for the team to begin preparation on Debezium 2.4.

As we begin to prepare to move toward Debezium 2.4, we would love to hear your feedback or suggestions. The roadmap will be updated in the coming week, so please be sure to get in touch with us on the mailing list or our chat if you have any ideas or suggestions.

Until next time…​