In Debezium 2.7.0.Final, we mistakenly missed including the new Debezium for MariaDB connector in the container images, which necessitated users to manually install the MariaDB connector. This has been fixed and Debezium 2.7.1.Final’s container images now include all connectors like they did previously (DBZ-8008).

In Debezium 2.7 with the separation of MariaDB and MySQL into their unique connectors, each also use a unique grammar to parse SQL statements. A regression was identified that the new MariaDB grammar did not support the SQL syntax for RENAME TABLE (DBZ-8066). This has been fixed and is fully supported in both MySQL and MariaDB.

In prior versions of the Debezium JDBC sink, users may have noticed several strange messages in their connector logs that may resemble the following output:

Thanks to a user report (DBZ-7946), it was identified that the JDBC sink connector was not properly handling the rebalance of partitions across multiple tasks. This regression has been fixed in 2.7.1.Final, and when a partition rebalance occurs, the partition will be closed by the task that no longer will manage the partition; ergo, the above messages will no longer be written to the connector logs.

In Debezium 2.7, users may have noticed that if you picked the insert_delete watermark strategy for handling signal table entries, that the connector would eventually fail with a StackOverflowError (DBZ-8011). With Debezium 2.7.1.Final or later, this regression has been fixed and users can once again use the insert_delete watermark strategy.

In addition, there was also a report where sending an ad-hoc snapshot signal that contained a regular expression that matches no database tables would cause the ad-hoc snapshot process to fail with an "Unexpected result ." error (DBZ-8050). This has also been fixed so the ad-hoc snapshot will gracefully skip the signal as no matching tables were found.

Finally, it was also identified that ad-hoc blocking snapshots could lead to a CommunicationsException due to how the connection was being managed by the initial and blocking snapshot code paths (DBZ-8058). This has been fixed in Debezium 2.7.1.Final by having the blocking snapshot validate and re-open the connection if required.

The new asynchronous embedded engine was recently released by the Debezium team and continues to improve across releases. As a part of our continuous improvements, it was identified that single message transforms did not have their close() method being called. This could easily lead to resource leaks depending on what the transformation does.

This release introduces a fix to automatically close transformations to avoid this problem (DBZ-8106).

A change was added to the Debezium Oracle connector (DBZ-8055) that to address several race concerns with Oracle LogMiner and capturing changes. Unfortunately, that change introduced a corner case where the connector would recalculate the upper mining range, and in such cases would lead to a NullPointerException.

A new fix (DBZ-8119) was included in Debezium 2.7.1.Final to correct the problem. Oracle connector users are recommended to upgrade to 2.7.1.Final and to skip 2.7.0.Final to avoid this regression.

It was identified that there were some corner cases where the transaction epoch value was being reset when a transaction ID was unavailable (DBZ-8087). This is unexpected behavior as the transaction epoch should monotonically increase, and the resetting to zero broke that expectation. A fix has been added to avoid the reset and to restore the expected transaction epoch behavior.