The Debezium 2.2 release ushers in a new era for Debezium which has had a longstanding focus purely on providing a set of source connectors for relational and non-relational databases. This release alters that landscape, introducing a new JDBC sink connector implementation.

水槽De开云体育官方注册网址bezium JDBC连接器非常与众不同t from other vendor implementations in that it is capable of ingesting change events emitted by Debezium connectors without the need for event flattening. This has the potential to reduce the processing footprint in your pipeline, simplifies the pipeline’s configuration, and allows Debezium’s JDBC sink connector to take advantage of numerous Debezium source connector features such as column type propagation and much more.

Getting started with the Debezium JDBC sink connector is quite simple, lets take a look at an example.

Let’s say we have a Kafka topic calledordersthat contains Debezium change events that were created without using theExtractNewRecordStatetransformation from MySQL. A simple configuration to ingest these change events into a PostgreSQL database might look this the following:

In this example, we’ve specified a series ofconnection.*properties that define the connection string and credentials for accessing the destination PostgreSQL database. Additionally, records will useUPSERTsemantics when writing to the destination database, choosing to use an insert if the record doesn’t exist or updating the record if it does. We have also enabled schema evolution and specified that a table’s key columns should be derived from the event’s primary key.

The JDBC sink connector presently has support for the following relational databases:

We do intend to add additional dialects in the future, and if there one you’d like to see, please get in touch with us either on our mailing list, in chat, or opening a Jira enhancement.

When using the Debezium for MongoDB connector in a sharded cluster deployment, the connector opens a connection with each of the shard’s replica sets directly. This is not a recommended approach and instead MongoDB suggests that the connectoropen a connection with the mongos instance(the router) instead.

This release aligns with this recommended strategy and users should be prepared to adjust their configurations slightly and when using the connector in such a deployment, point the connector as themongosinstance instead. There should be be other changes required.

Google’s Cloud Spanner platform supports a PostgreSQL interface, which combines the scalability and reliability of the Google Spanner platform with the familiarity and portability of PostgreSQL. When operating Google Spanner with this PostgreSQL interface, metadata of columns and tables is different than when using the standard GoogleSQL dialect.

This release extends the Debezium Spanner connector support not only for the GoogleSQL dialect but also for users that use the Spanner PostgreSQL dialect feature. This means regardless of which dialect your spanner environment relies on, you will be able to capture change events from Spanner using the Debezium Spanner connector seamlessly.

So if you’re using Spanner’s PostgreSQL dialect, upgrade to Debezium 2.2.0.Beta1 or later and start capturing changes!

Debezium Server is a ready-made Quarkus-based runtime for Debezium source and sink connectors. Debezium Server provides the capability to send Debezium change events from any source connector to a variety of messaging infrastructure platforms, particularly for users who would prefer something other than Apache Kafka.

In this release, a new sink adapter has been added to the Debezium Server portfolio, allowing Debezium users to send change events to RabbitMQ. The following configuration shows a simple example of how easy it is to configure:

Thedebezium.sink.rabbitmq.connection.*properties are required while the latter two properties forroutingKeyandackTimeout是可选的或预设违约,应be sufficient for most use cases.

There were quite a number of other improvements, bug fixes, and stability changes in this release, some noteworthy are:

Altogether,52 issueswere fixed for this release. A big thank you to all the contributors from the community who worked on this release:Đỗ Ngọc Sơn,Anatolii Popov,Anisha Mohanty,Bob Roldan,Chris Cranford,Gunnar Morling,Harvey Yue,Hossein Torabi,Jakub Cechacek,Jiri Pechanec,Mario Fiore Vitale,Nir Levy,Plugaru Tudor,Robert Roldan,Russell Mora,Vojtech Juranek,Vojtěch Juránek, andtony joseph!

As we approach the end of the Debezium 2.2 development cycle, with a final release expected in the next two weeks, we’re going to begin to turn our attention toward Debezium 2.3. The Debezium 2.3 release will be a much more condensed and focused release, as our goal is to release it in late June.

We will be refining ourroadmapin the coming days, so I would pay close attention to this to get an understanding of what lies ahead in the near future for Debezium 2.3. We would like to hear your feedback or suggestions, so if you have anything you’d like to share be sure to get in touch with us on themailing listor ourchat.

DevNexus 2023 is also underway this week, from April 4th until April 6th and I will be presenting a talk on CDC Patterns with Distributed Systems using Debezium. If you’re in the Atlanta area and plan to attend DevNexus on Thursday, April 6th, drop me a line.

Until next time, let the changes continue to stream…