Debezium日常分享系列之：Debezium 2.3.0.Final发布

一、重大改变

通常会尝试尽可能避免次要版本中的重大更改，但不幸的是，有时此类更改是不可避免的，特别是如果某个功能可能是作为实验性引入的。 Debezium 2.3 引入了两项重大更改：

• PostgreSQL / MySQL 安全连接更改
• JDBC 存储编码更改

二、PostgreSQL / MySQL 安全连接更改

• Debezium for PostgreSQL 和 MySQL 可以配置为使用安全的 SSL 连接。对于 PostgreSQL，这可以通过配置database.sslmode 来完成，而对于MySQL，这可以通过database.ssl.mode 来完成。
• 在 Debezium 2.3 中，此配置选项不再默认为禁用 (PostgreSQL) 或禁用 (MySQL)，而是默认为首选 (PostgreSQL) 和首选 (MySQL)。这意味着，当尝试使用加密的安全连接进行连接不可用时，连接器将默认使用不安全的连接，除非另有配置。

三、JDBC 存储编码更改

• Debezium 2.3.0.alpha1 引入了新的实验性 JDBC 存储模块。该存储模块默认使用UTF-16作为默认编码；但是，大多数数据库更喜欢将 UTF-8 作为默认值。如果您从 Debezium 2.3.0.Alpha1 升级，则 Debezium 2.3.0.Beta1 及更高版本现在在使用 JDBC 存储模块存储数据时使用 UTF-8，以与典型数据库默认值保持一致。

四、新功能和改进

Debezium 2.3 包含大量新功能改进，其中包括：

• Kubernetes 的 Debezium Server Operator
• 新的通知子系统
• 具有新通道的新型可扩展信号子系统
• JMX 信号和通知集成
• 新的 JDBC 存储模块
• PostgreSQL 流式传输的恰好一次传送
• PostgreSQL 副本身份更改
• Oracle RAC 改进

五、Kubernetes 的 Debezium Server Operator

• 此版本引入了新 Debezium Operator 的预览版本，提供了在 Kubernetes 中部署和管理 Debezium Server 实例的能力。 Debezium Server 允许您将更改事件从数据源流式传输到各种消息传递基础设施。我们的目标是为希望利用 Kubernetes 实现可扩展性和高可用性部署的 Debezium 社区提供一种无 Kafka 的替代方案。
• 目前，由于运营商处于早期孵化阶段，相关文档很少；然而，我们确实打算在即将到来的发布周期中对此进行改进。您可以在 github 存储库中找到自定义资源规范的部署示例和基本描述，您可以将其用作短期参考。
• 我们目前不建议将此组件进行生产部署；但是，我们鼓励用户提供社区反馈。这些反馈对于评估组件是否已准备好功能或是否仍有需要改进的地方来满足每个人的需求非常有价值。

六、新的通知子系统

• Debezium 2.3 引入了一个名为通知的全新功能，允许 Debezium 发出可供任何外部系统使用的事件，以了解 Debezium 生命周期各个阶段的状态。
• 通知事件表示为一系列键/值元组，其结构包含多个开箱即用的字段。以下是一个简单通知事件的示例。

通知事件示例

{"id": "c485ccc3-16ff-47cc-b4e8-b56a57c3bad2","aggregate_type": "Snapshot","type": "Started","additional_data": {...}
}

每个通知事件由一个 id 字段、一个用于标识通知的 UUID、一个基于域驱动设计概念与通知相关的aggregate_type 字段、一个用于提供有关聚合类型本身的更多详细信息的 type 字段组成，以及一个可选的 extra_data 字段，该字段由基于字符串的键/值对的映射以及有关事件的附加信息组成。

目前 Debezium 支持两种通知事件类型：

• 初始快照的状态
• 增量快照监控

初始快照通知：

初始快照是连接器首次启动时对现有数据的一致捕获。初始快照事件将具有值为“初始快照”的聚合类型，并且事件类型将由三个逻辑值之一组成：

• SKIPPED：代表初始快照被跳过
• ABORTED：表示初始快照已中止。
• COMPLETED：表示初始快照已成功结束。

以下是有关初始快照完成的通知示例：

快照完成事件示例

{"id": "5563ae14-49f8-4579-9641-c1bbc2d76f99","aggregate_type": "Initial Snapshot","type": "COMPLETED"
}

增量快照通知：

增量快照是在连接器主动传输更改时从一组配置的表中捕获现有数据。增量快照事件将具有值为“增量快照”的聚合类型，并且该类型将由以下几个逻辑值之一组成：

• STARTED：表示增量快照已经开始
• PAUSED：表示增量快照已暂时暂停。
• RESUMED：表示已暂停的增量快照现已恢复。
• STOPPED：表示增量快照已停止。
• IN_PROGRESS：指示增量快照正在进行中。
• TABLE_SCAN_COMPLETED：指示给定表的增量快照已结束。
• COMPLETED：表示所有表的增量快照已结束。

配置通知：
Debezium 通知是通过连接器的配置进行配置的。以下示例展示了如何配置开箱即用的基于 Kafka 主题或日志的通道。

使用 Kafka 主题

{"notification.enable.channels": "sink","notification.sink.topic.name": "debezium_notifications",...
}

使用连接器日志

{"notification.enable.channels": "log"
}

七、新的可扩展信号子系统

自 Debezium 1.x 中引入增量快照功能以来，Debezium 就支持信号的概念。信号很重要，因为它允许您提供元数据来指示 Debezium 执行给定任务，无论该任务是向连接器日志写入条目还是执行临时增量快照。

在 Debezium 2.3 中，信号子系统经过重新设计，引入了称为通道的概念，它代表 Debezium 观察或收听信号并对信号做出反应的媒介。在以前的版本中，有一个跨连接器普遍支持的通道，即数据库信号表。在此版本中，这些渠道已统一，并且以下内容可供开箱即用：

• 数据库信号表
• Kafka信号主题
• 文件系统
• JMX

但这还不是全部，信号通道合约是可扩展的，允许您编写自定义实现并轻松地将其提供给您的连接器。

八、JMX 信号和通知集成

Debezium 2.3 之前引入了新的信号通道和通知功能。此功能允许外部应用程序轻松与 Debezium 集成，发送信号来执行各种任务（例如临时增量快照），并接收有关此类任务进度的通知。此版本建立在该功能之上，允许通过 JMX 发送信号和接收通知。

发送信号

在此版本中，信号通道子系统已得到改进，支持通过 JMX 发送信号。从 jconsole 窗口中，您现在可以看到连接器有两个新的小部分，即通知和信号部分，如下所示：

新的信号部分允许您调用 JMX bean 上的操作，以便将信号传输到 Debezium。该信号类似于逻辑信号表结构，它接受 3 个参数：唯一标识符、信号类型，最后是信号有效负载。下面说明了 jconsole 中的情况：

接收通知

新的通知部分允许您接收来自 Debezium 的 JMX bean 捕获的通知并做出反应。 Debezium JMX bean 将缓冲所有通知以确保不会错过任何通知。下面说明了 jconsole 中的情况：

JMX bean 不会自动清除通知队列。为了避免内存问题，请务必在处理完所有通知后调用通知 bean 上的重置方法。

九、新的 JDBC 存储子系统

Debezium 2.3 引入了一种新的存储模块实现，支持通过 JDBC 在数据存储中持久保存模式历史记录和偏移数据。对于您可能无法轻松访问持久文件系统的环境，这提供了另一种通过远程持久存储平台进行存储的替代方案。

为了利用这个新模块，必须将以下依赖项添加到您的项目或应用程序中：

Maven coordinates

<dependency><groupId>io.debezium</groupId><artifactId>debezium-storage-jdbc</artifactId><version>2.3.0.Final</version>
</dependency>

以下示例展示了如何通过 JDBC 存储模块配置偏移量或架构历史记录存储：

Offset JDBC 存储配置示例

{"offset.storage.jdbc.url": "<jdbc-connection-url>","offset.storage.jdbc.user": "dbuser","offset.storage.jdbc.password": "secret","offset.storage.jdbc.offset_table_name": "debezium_offset_storage"
}

架构历史 JDBC 存储的配置示例

{"schema.history.internal.jdbc.url": "<jdbc-connection-url>","schema.history.internal.jdbc.user": "dbuser","schema.history.internal.jdbc.password": "secret","schema.history.internal.jdbc.schema.history.table.name": "debezium_database_history"
}

十、PostgreSQL 流式传输的恰好一次传送

Debezium 传统上是一种至少一次交付解决方案，保证不会错过任何更改。 Exactly-Once 是 Apache Kafka 社区提出的一项提案，作为 KIP-618 的一部分。该提案旨在解决生产者（源连接器）的常见问题，当生产者重试时，它可能会重新向 Kafka 代理发送一批事件，即使该批次已经由代理提交。这意味着在某些情况下可能会发送重复的事件，并且并非每个消费者（接收器连接器）都能够轻松处理此类情况。

Debezium 计划以分阶段的方式推出一次性交付语义。快照和流媒体存在一些特定的极端情况，这些情况可能因连接器而异。就这样，Debezium 2.3 首先专门只在 PostgreSQL 的流阶段添加对一次语义的支持！

为了利用一次性交付，无需更改连接器配置；但是，您的 Kafka Connect 工作线程配置需要调整才能启用此功能。

如果您在同一个连接集群上混合支持和不支持精确一次传送的连接器，则您将无法在工作配置中将正好.once.support 设置为 required，因为这将导致不支持此功能的连接器启动时验证失败。

十一、PostgreSQL 副本身份更改

Debezium 2.3 引入了一个新的 PostgreSQL 连接器功能，称为“自动设置副本身份”。

副本身份是 PostgreSQL 识别在数据库事务日志中捕获哪些列以进行插入、更新和删除的方法。这项新功能允许通过连接器配置来配置表的副本身份，并在启动时将设置此配置的责任委托给连接器。

新的配置选项replica.identity.autoset.values指定以逗号分隔的表和副本身份元组列表。如果表已经具有给定的副本标识，则该标识将被覆盖以匹配此配置中指定的内容（如果包含该表）。 PostgreSQL 支持多种副本身份类型。

指定replica.identity.autoset.values时，该值是一个以逗号分隔的值列表，其中每个元素使用<完全限定表名称>:<副本身份>的格式。下面显示了一个示例，其中两个表配置为具有完整副本标识：

{"replica.identity.autoset.values": "public.table1:FULL,public.table2:FULL"
}

十二、Oracle RAC 改进

连接到 Oracle RAC 安装时，您必须指定 rac.nodes 配置属性，其中至少包含集群中所有单个节点的主机或 IP 地址。旧版本的连接器还支持多种格式，允许为每个节点包含一个端口，因为并非集群上的每个节点都可以使用相同的端口。

Debezium 2.3 还承认每个节点不一定使用相同的 Oracle 站点标识符 (SID)，从而改进了 Oracle RAC 支持，因此，SID 现在也可以包含在 rac.nodes 配置属性中以支持此类安装。

以下示例说明了连接到两个 Oracle RAC 节点，每个节点使用不同的端口和 SID 参数：

配置示例

{"connector.class": "io.debezium.connector.oracle.OracleConnector","rac.nodes": "host1.domain.com:1521/ORCLSID1,host2.domain.com:1522/ORCLSID2",...
}