我很荣幸地宣布 Debezium 2.1 系列的第一个版本，2.1.0.Alpha1！
Debezium 2.1.0.Alpha1 版本包含许多错误修复，但也包含一些值得注意的改进和新功能，包括但不限于：
-
对 PostgreSQL 15 的支持
-
Debezium 引擎中的单条消息转换 (SMT) predicate 支持
-
在 MySQL 表 topic 中捕获 TRUNCATE 作为变更事件
-
Oracle LogMiner 性能改进
-
新的基于 Redis 的存储模块
让我们花几分钟时间更详细地了解其中的一些内容！
Debezium 引擎中的 SMT predicate 支持
Single Message Transformations (SMT) 是变更事件生命周期中的关键部分，它们可以对发出的变更事件应用任意数量的消息模式。例如，数据库表可能有一个特定的列会作为 Debezium 的变更事件的一部分发出，但您希望排除该字段，以便该字段不会出现在 Kafka 中已持久化的事件中。这可以使用单个消息转换 (SMT) 来完成。
然而，Debezium 会发出多种不同的事件类型，例如心跳、模式更改和数据更改事件。每种事件都有自己的事件结构，并且可能会出现一种情况，即特定的 SMT 应该仅应用于特定的事件类型，或者当特定事件满足某些条件时。评估是否应应用 SMT 的一种方法是在 SMT 本身内部进行评估，检查其事件类型或所有条件，以确定是否应应用 SMT，或者 SMT 是否应保持事件不变。
之后，Kafka Connect 引入了一个名为 *predicates* 的概念，它允许在连接器配置中指定一组外部规则，并且必须对其进行评估以确定是否为事件触发 SMT，或者是否跳过 SMT。这带来了巨大的好处，因为它允许开发人员编写非常具体的转换，专注于单一的变异，而由用户完全决定是否使用 *predicates* 来应用该 SMT。
从 Debezium 2.1 开始，在使用 Debezium Engine 或 Debezium Server 时，可以利用 Single Message Transformation (SMT) predicates 的强大功能。示例文件可能如下所示：
# Define the filter transformation, linking it to the IsFoo predicate/rule
debezium.transforms=Filter
debezium.transforms.Filter.type=org.apache.kafka.connect.transforms.Filter
debezium.transforms.Filter.predicate=IsFoo
# Define the IsFoo predicate/rule
debezium.predicates=IsFoo
debezium.predicates.IsFoo.type=org.apache.kafka.connect.transforms.predicates.TopicNameMatches
debezium.predicates.IsFoo.pattern=foo通过这些额外的 debezium.predicates.* 配置属性，可以定义一组必须进行评估的规则，以确定 Filter SMT 是触发还是跳过转换链。在上例中，predicate 检查事件的主题名称是否与 foo 匹配，如果匹配，则触发 Filter 转换。如果不匹配，则跳过 Filter 转换。
要了解有关使用 predicate 选择性应用 Single Message Transformations (SMT) 的更多信息，请参阅：
捕获 MySQL TRUNCATE 作为变更事件
Debezium 支持发出变更事件来指示 PostgreSQL 和 Oracle 的 TRUNCATE TABLE 场景已有一段时间。从 Debezium 2.1 开始，此行为已扩展到 MySQL 连接器。
默认情况下，连接器配置选项 skipped.operations 会在检测到 TRUNCATE 事件时自动跳过它们。这意味着默认情况下，当连接器检测到此模式时，不会发出任何内容。为了支持此类事件的发出，必须将 skipped.operations 配置属性指定为 none 或不包含 t (truncate) 类型的其他操作类型。
一旦连接器配置为对 TRUNCATE 操作发出事件，就会向表主题发出新的数据更改事件类型。这些事件类型表明表或集合已被截断。事件的 payload 将如下所示：
"payload": {
"source": {
...
},
"op": "t",
"ts_ms": 1465581029523
}这里最值得注意的是，截断事件不包含 before 或 after 状态。
新的基于 Redis 的存储模块
Debezium 最近将其部分代码库（围绕持久化偏移量和模式历史）模块化为一组支持文件和基于 Kafka 的实现的模块。在 Debezium 2.1 中，引入了一个新模块来支持持久化到 Redis 数据存储。
可以使用以下完全限定类名将偏移量或模式历史持久化到 Redis 数据存储：
-
io.debezium.storage.redis.offset.RedisOffsetBackingStore -
io.debezium.storage.redis.history.RedisSchemaHistory
如果您手动安装了 Debezium，请确保将 debezium-storage-redis artifact 包含在类路径中（如果不存在），以便访问这些新实现。
有关此新实现可以配置的选项，请参阅 Debezium Server 文档的 源配置 部分，并查找以 debezium.source.offset.storage.redis.* 或 debezium.source.schema.history.internal.redis.* 为前缀的配置选项。
-
debezium.source.offset.storage.redis.* -
debezium.source.schema.history.internal.redis.*
其他修复
此版本中修复了许多错误并进行了稳定性改进，其中一些值得注意的包括：
-
缺少快照待处理事务 DBZ-5482
-
使用 snapshot.mode ALWAYS 使用来自偏移量的 SCN DBZ-5626
-
MongoDB 多任务监控失调 DBZ-5629
-
当 lob.enabled 为 true 时，具有 NULL 值的 UNIQUE INDEX 会抛出异常 DBZ-5682
-
进行增量快照时未排除列 DBZ-5727
-
在 Oracle 源连接器的表快照过程中抛出 NullPointerException DBZ-5738
-
ARO 中负载均衡的 OCP 服务的时区不可用 DBZ-5753
-
排除 Oracle Compression Advisor 表不被捕获，以避免无限循环 DBZ-5756
-
LSN 为 'LSN{XYZ}' 的消息在 location 阶段的 LSN 中未找到 DBZ-5792
总而言之，本次发布修复了 55 个问题。非常感谢社区中所有为本次发布做出贡献的开发者：Anil Dasari、Anisha Mohanty、Bob Roldan、Chris Cranford、Enzo Cappa、Gabor Andras、Harvey Yue、Helong Zhang、Hubert Dulay、Jakub Cechacek、Jan Werner、Jeremy Ford、Jiri Novotny、Jiri Pechanec、Mark Lambert、Martin Medek、Ondrej Babec、Rajendra Dangwal、Théophile Helleboid、Vojtech Juranek 和 Yang Wu！
下一步是什么？
因此，随着我们继续开发 Debezium 2.1，我们在今天的发布中包含了许多预期的更改，但我们仍然打算在年底前交付用于生成变更事件增量的新的 Single Message Transformation (SMT)。Debezium UI 也有一些备受期待的更改，例如支持编辑连接器配置等等。
您可以在我们最近更新的 路线图 中找到这些信息以及 Debezium 在 2023 年还将带来的其他内容。我们为明年计划了许多新功能，并且我们很乐意听取您对可能不在路线图上但您希望看到的功能的反馈或建议。如果有，请务必在邮件列表中与我们联系。
下次见……
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
