虽然开发仍然稳步进行，我们继续推进 Debezium 2.4，我很兴奋地宣布 Debezium 2.4.0.Beta1 现已发布。
虽然此版本主要侧重于稳定性和错误修复，但有几项值得注意的新功能，包括 TimescaleDB 支持、使用 JSON 载荷的 JMX 通知、Oracle 连接器指标和嵌入式 Infinispan 缓冲区实现的多个改进、SQL Server 心跳、Vitess 无分片策略，以及 JDBC sink 的 SQL Server 基于标识的插入，等等。让我们深入探讨所有这些新功能及更多内容。
TimescaleDB 支持
TimescaleDB 是一个基于 PostgreSQL 的开源时间序列数据库。这意味着许多用于直接支持 TimescaleDB 的功能都来自现有的 PostgreSQL 连接器；然而，TimescaleDB 的某些方面，如 chunk（分块）、hypertable（超级表）和 aggregate（聚合），却不是。
因此，如果您想开始使用 Debezium 2.4 和 TimescaleDB，集成需要结合 PostgreSQL 连接器以及一个新的 TimescaleDb 单消息转换 (SMT)。这两者的结合能够从 TimescaleDB 环境中流式传输更改，并根据 chunk、hypertable 和 aggregate 提供适当的表名。
TimescaleDb 转换可作为 io.debezium.connector.postgresql.transforms.timescaledb 使用，负责在处理 chunk、hypertable 和 aggregate 时调整最终的主题名称。此外，此转换会向更改事件添加元数据头，以便您了解原始 chunk 名称、chunk 表、hypertable 模式和相应的表名。
JMX 通知支持 JSON 用户数据
Debezium 2.4 更改了 JMX 通知提供用户数据的方式。在以前的版本中，通知使用了 toString() 风格的实现，虽然它能工作，但与 JSON 等更结构化的格式相比，它不提供任何良好的向前或向后兼容性语义。
今后，JMX 通知的用户数据将以 JSON 格式提供，使其更容易、更可靠地解析，并且未来能够以更少的向后兼容性担忧来支持可扩展性。我们希望这能使此功能在未来更容易使用，并欢迎任何额外的反馈。
Oracle 连接器 SCN（系统更改号）指标
Oracle 在其 JMX 指标中跟踪各种系统更改号 (SCN) 值，包括 OffsetScn、CurrentScn、OldestScn 和 CommittedScn。这些 SCN 值是数字，并且经常会超过 Long 数据类型的上限，因此 Debezium 传统上将这些值暴露为 String。
不幸的是，Grafana 和 Prometheus 等工具无法处理基于 String 的值，而且社区多次提出希望能够从指标收集框架中查看这些值。随着 Debezium 2.4 的发布，这些 JMX 指标的行为发生了一个小变化，它们不再暴露为 String 值，而是现在暴露为 BigInteger 值。
这种行为的改变允许 Grafana 和 Prometheus 等工具现在可以自动从 JMX Bean 中抓取这些值，用于报告和可观察性堆栈。
| 如果您之前曾为其他目的收集这些值，请注意它们不再是基于字符串的，并且今后应将其解释为 |
Oracle 连接器最大事务年龄指标
Oracle 连接器为 LogMiner 提供了大量指标，包括 OldestScn 指标，该指标表示连接器事务缓冲区中最老的系统更改号。这个 SCN 对于了解事务相对于当前系统更改号 CurrentScn 仍可能缓冲多久非常有用。然而，系统更改号仅仅是数字值，需要使用数据库函数调用才能知道更改何时发生。
从 Debezium 2.4 开始，连接器还将通过提供一个名为 OldestScnAgeInMilliseconds 的新指标来跟踪最老的系统更改号的年龄。此指标是通过获取 OffsetScn 的时间戳，并计算该时间与指标的查询时间之间的差值来计算的，从而给出缓冲区中尚未提交或回滚的最老事务的大致毫秒年龄。
如果您对其他可能有帮助的指标感兴趣，请随时联系我们。
Oracle 嵌入式 Infinispan 配置更改
Oracle 连接器支持三种不同的缓冲技术，一种基于 JVM 堆，另外两种基于 Infinispan 的堆外存储。在使用 Infinispan 时，您可以选择使用远程集群（缓存通过远程连接存储和管理），或者使用嵌入式集群（集群由连接器本身在本地管理）。
在使用远程 Infinispan 集群时，部分集群配置是在 Infinispan 安装本身中完成的，这通常被称为全局或集群配置。然而，在使用嵌入式 Infinispan 集群时，Debezium 仅使用了嵌入式集群的默认配置，这可能并不总是为每个环境提供所有必需的行为。
Debezium 2.4 引入了一个新的配置属性 log.mining.buffer.infinispan.cache.global。此属性允许指定 Infinispan "全局" 或 "集群" 配置的 XML 配置。
<infinispan>
<threads>
<blocking-bounded-queue-thread-pool
max-threads="10"
name="myexec"
keepalive-time="10000"
queue-length="5000" />
</threads>
</infinispan>借助 Debezium 2.4，如果您使用 Infinispan 嵌入式缓冲区，现在可以安全地配置 Infinispan 的整体嵌入式全局配置，这可以使您在使用嵌入式 Infinispan 引擎时调优和提高整体性能。
SQL Server 心跳改进
数据库在一段时间内没有相关更改是很常见的情况，这可能是由于不活动，或者即使发生更改，连接器根据配置也对其不感兴趣。在这些情况下，连接器管理的偏移元数据在这些期间内保持与偏移后端存储同步至关重要，这样连接器的重启才能按预期工作。
使用 Debezium 2.4 时，如果 SQL Server 变更捕获循环没有找到任何更改，或者发生的更改与连接器无关，只要启用了心跳，连接器将继续发出心跳事件。这应该可以提高各种用例中偏移后端存储中存储的偏移量的可靠性。
Vitess 无分片命名策略
Debezium 2.4.0.Alpha2 引入了一种通过使用分片名称作为目录来处理每个分片的模式更改的机制，用于标识表的关联标识符。在使用 DefaultTopicNamingStrategy 时，这产生了一个副作用，即分片会包含在主题名称中，这可能不是期望的。
Debezium 2.4.0.Beta1 引入了一种新的策略，称为 TableTopicNamingStrategy，该策略能够启用旧的行为。
下表显示了基于不同策略的主题名称的输出差异
| 策略 | 主题输出 |
|---|---|
|
|
|
|
要配置表主题命名策略，请在连接器中包含以下配置
topic.naming.strategy=io.debezium.connector.vitess.TableTopicNamingStrategyJDBC sink SQL Server 标识符插入
每个数据库处理向基于标识符的列插入值的方式都不同。对于 SQL Server，这需要在插入之前显式启用 IDENTITY_INSERT，并在之后禁用此功能。在 Debezium 2.4 中，Debezium JDBC sink 连接器为目标数据库提供了此支持。
为了利用基于标识符的插入，JDBC sink 连接器必须配置一个新的基于方言的属性 dialect.sqlserver.identity.inserts，该属性可以设置为 true 或 false。默认情况下，此功能设置为 false，如果您希望插入到基于标识符的列中，则必须启用它。
启用后，所有 *insert* 和 *upsert* 操作将包装如下
SET IDENTITY_INSERT <table-name> ON;
<the insert or upsert statement>
SET IDENTITY_INSERT <table-name> OFF;其他修复和改进
本次发布中有几处 bug 修复和稳定性改进，其中一些值得注意的有：
-
Debezium heartbeat.action.query 在写入 WAL 之前不会启动 DBZ-6635
-
使用自定义主题命名策略时，模式名称已更改 DBZ-6641
-
JdbcSinkConnector 的 quote.identifiers 行为错误 DBZ-6682
-
Toasted UUID 数组未正确处理 DBZ-6720
-
Debezium 在解析 MySQL DDL 语句 (特定 JOIN) 时崩溃 DBZ-6724
-
阻塞快照必须从信号中获取快照配置 DBZ-6731
-
当使用 Postgres 连接器的 pgoutput 时，不支持十进制值中的 (+/-)Infinity DBZ-6758
-
Outbox 转换可能导致连接器崩溃 DBZ-6760
-
MongoDB 新文档状态提取：add.headers 的非存在字段 DBZ-6774
-
在 7.0-rc 版本上执行时，Mongodb 连接器测试大量失败 DBZ-6779
-
Dbz 在解析 MySQL DDL 语句 (SELECT 1.;) 时崩溃 DBZ-6780
-
在未指定任何配置的情况下执行时，Mysql 连接器测试失败 DBZ-6791
-
Dbz 在解析 MySQL DDL 语句 (SELECT 1 + @sum:=1 AS ss;) 时崩溃 DBZ-6794
-
MySQL DDL 解析器 - 不接受 REPEAT 函数 DBZ-6803
-
修复 getSnapshottingTask 的错误 DBZ-6820
-
Dbz 在 DDL 语句时崩溃（变量中包含非拉丁字符） DBZ-6821
-
解析 MySQL DDL 时，不对 BIGINT 和 SMALLINT 类型默认值进行修剪 DBZ-6824
-
PostgresConnectorIT#shouldAddNewFieldToSourceInfo 随机失败 DBZ-6839
-
错误过滤的注释 DBZ-6840
-
间歇性测试失败：BaseSourceTaskTest.verifyTaskRestartsSuccessfully DBZ-6841
-
当使用
skip.messages.without.change=true时，每个记录都会报告一个 WARN 日志消息 DBZ-6843
总共有 39 个问题在此版本中得到修复。 Andreas Martens, Anil Dasari, Anisha Mohanty, Bob Roldan, Chris Beard, Chris Cranford, Matan Cohen, Emre Akgün, Eric Pangiawan, Hang Ruan, Harvey Yue, Jeremy Ford, Jiri Novotny, Jiri Pechanec, M. Gökhan Akgül, Mario Fiore Vitale, Nancy Xu, Ondrej Babec, Rajendra Dangwal, Shuran Zhang, Stein Rolevink, Sun Xiao Jian, Thomas Thornton, Vojtech Juranek, Wu Zhenhua, Xiaojian Sun
展望与下一步？
随着我们进入 Debezium 2.4 的 beta 阶段，接下来的几周将主要专注于错误修复和稳定性，我们将继续朝着九月底的最终发布迈进。我们还在对 Oracle 的 OpenLogReplicator 摄取方法进行最后的调整，一旦完成，预计 Beta2 将很快发布。此外，Debezium 2.3.3.Final 的维护版本将于下周初发布，并且很可能还会有另一个 2.3 版本发布，以便在本月晚些时候过渡到 Debezium 2.4 作为新的稳定版本。
此外，Debezium 社区活动议程和日期将于本周晚些时候公布，敬请关注。最后，我们将在本月晚些时候的 Kafka Summit 2023（又名 Current 2023）上发表演讲。如果您计划参加并想向专家提问，请务必与我或团队中的任何成员联系，我们可以安排见面并讨论任何与 Debezium 和 CDC 相关的内容。
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
