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

一、重大改变
- 1.MySQL
- 2.MongoDB
- 3.JDBC
- 4.Core
二、改进和变化
- 1.Redis 架构历史重试现在受到限制
- 2.初始快照的附加通知
- 3.重新选择列
- 4.增量快照水印的 INSERT/DELETE 语义
- 5.MongoDB无缝大文档处理
- 6.Mysql 8.2 support
- 7.Mysql 高精度源时间戳
- 8.从 PostgreSQL 16 备用服务器进行流式传输
- 9.Oracle 流媒体指标变化
- 10.Oracle LOB 行为
- 11.SQL Server 通知改进
- 12.SQL Server 驱动程序更新
- 13.JDBC sink批量支持
- 14.JDBC sink字段包含/排除
- 15.Debezium Server Operator
- 16.Kinesis 接收器改进
- 17.EventHub 分区
- 18.RabbitMQ 流接收器
- 19.Apache Kafka 接收器的 StreamNameMapper
- 20.AWS SQS sink
- 21.Spanner
- 22.IBM Informix Connector
- 23.MariaDB数据库预览支持
- 24.MariaDB支持GTID
三、Debezium生产环境大规模应用实战系列文章汇总

一、重大改变

1.MySQL

MySQL社区宣布MySQL 5.7将于2023年10月下旬进入生命周期结束根据这一上游社区消息，Debezium也像其他供应商一样围绕这一最新消息进行调整。为此，从 Debezium 2.5 开始，如果满负荷，我们将不再测试或支持 MySQL 5.7，因此 MySQL 5.7 进入了我们所谓的“尽力而为”支持。
如果没有设置的话，MySQL BIT 数据类型没有隐式长度。这是不正确的，因为如果未提供，则默认长度为 1。

2.MongoDB

在 Debezium 的早期版本中，用户可以使用 MongoDB 连接器，并在使用 MongoDB 分片部署时在特定分片上执行集合快照。不幸的是，虽然我们知道用户可能利用了此行为，但这是无意的且不受支持。 Debezium 2.5 完全删除了这种功能，完全弃用并删除 MongoDB 中的副本集流模式是未来目标中的一步。
默认连接模式从replica_set更改为sharded，作为其完全删除的准备步骤。该更改将导致现有偏移量失效以及初始快照的静默重新执行。为了防止这种情况发生，添加了一项检查，如果发生这种情况，连接器将在启动时失败。用户可以显式设置replica_set连接模式，也可以删除现有的偏移量。

3.JDBC

报告了一个极端情况，即 JDBC 接收器连接器错误地将具有空值的字段写入目标数据库，并使用默认值而不是 NULL 值。该问题已在 Debezium 2.5中修复。

4.Core

如果您当前正在使用 CloudEvents 转换器发出符合 CloudEvents 格式的事件，请务必注意配置选项metadata.location 已重命名为metadata.source。您需要确保在 Debezium 2.5 及更高版本中更新连接器配置以反映此更改。
Debezium 2.5 团队的部分重点是改善 Debezium 嵌入式引擎的体验。考虑到这一目标，我们将此预览版视为清理嵌入式引擎 API 的机会。
如果您对 Debezium 嵌入式引擎的使用使用了 EmbeddedEngine 上以前已弃用的任何 API，您会发现这些方法已被删除。建议的前进方向是确保您使用 debezium-api 工件提供的 DebeziumEngine 接口。
ComputePartition 是一个 SMT，使用户能够计算所需的分区，并为其在 Kafka 主题中写入事件。此单消息转换 (SMT) 不久前已被弃用，取而代之的是新的 PartitionRouting 单消息转换。 Debezium 2.5 删除了旧的、已弃用的 ComputePartition，并且可能仍在依赖此 SMT 的用户将需要迁移到新的 PartitionRouting SMT（如果尚未这样做的话）。
Cloud Event 标头的架构名称前缀和字母大小写与负载名称不一致。架构名称已对齐，因此标头和有效负载共享相同的命名空间，并遵循相同的字母大小写规则。

二、改进和变化

在本节中，我们将介绍 Debezium 2.5 中的所有新功能和改进。

1.Redis 架构历史重试现在受到限制

Debezium 2.5 引入了一个新的配置选项 schema.history.internal.redis.max.attempts ，旨在限制连接到 Redis 数据库时不可用时的重试尝试次数，以前它只是永远重试。这个新选项默认为 10，但用户可以配置。

2.初始快照的附加通知

Debezium 的通知子系统提供了一种将外部流程和应用程序与某些 Debezium 任务（例如拍摄快照）集成的简单方法。在之前的版本中，初始快照的通知非常基本，并提供了详细信息，例如快照何时开始、每个表何时开始和结束以及最终快照何时结束。
提供有关快照的增强详细信息。例如，IN_PROGRESS 通知将提供有关正在捕获哪些表以及当前正在处理哪些表的更多详细信息，如下所示：

{"id":"6d82a3ec-ba86-4b36-9168-7423b0dd5c1d","aggregate_type":"Initial Snapshot","type":"IN_PROGRESS","additional_data":{"connector_name":"my-connector","data_collections":"table1, table2","current_collection_in_progress":"table1"},"timestamp": "1695817046353"
}

此外，另一个名为 TABLE_SCAN_COMPLETED 的初始快照通知也提供了类似的详细信息，如下所示：

{"id":"6d82a3ec-ba86-4b36-9168-7423b0dd5c1d","aggregate_type":"Initial Snapshot","type":"TABLE_SCAN_COMPLETED","additional_data":{"connector_name":"my-connector","data_collection":"table1, table2","scanned_collection":"table1","total_rows_scanned":"100","status":"SUCCEEDED"},"timestamp": "1695817046353"
}

上面显示的几个字段（例如 data_collection）目前不适用于 MongoDB 快照，仅适用于基于 SQL 的关系连接器。

3.重新选择列

在某些情况下，由于某些源数据库的工作方式，当 Debezium 连接器发出更改事件时，该事件可能会排除特定列类型的值。例如，PostgreSQL 中的 TOAST 列、Oracle 中的 LOB 列或 Oracle Exadata 中的扩展字符串列的值可能全部被排除。
Debezium 2.5 引入了 ReselectColumnsPostProcessor，提供了一种从数据库表中重新选择一个或多个列并获取当前状态的方法。您可以配置后处理器以重新选择以下列类型：
- 空列。
- 包含 unavailable.value.placeholder 标记值的列。

配置 PostProcessor 与配置 CustomConverter 或 Transformation 类似，不同之处在于它适用于可变负载的 Struct 而不是 SourceRecord。

4.增量快照水印的 INSERT/DELETE 语义

引入了属性incremental.snapshot.watermarking.strategy，让用户可以选择在增量快照期间使用的水印策略。
insert_insert（旧行为）方法让 Debezium 在快照期间为每个块在信令数据集合中创建两个条目，以发出快照窗口打开的信号，并使用另一个条目来标记其关闭。
另一方面，使用 insert_delete 选项，在窗口开头的每个块的信令数据集合中写入单个条目。完成后，该条目被删除，并且不再添加相应的条目，以表示快照窗口的关闭。该方法有助于更有效地管理信令数据收集。

5.MongoDB无缝大文档处理

Debezium 在最近的版本中围绕大型文档处理引入了一些更改；然而，这些变化主要集中在使用 MongoDB 4 和 5 处理该用例。虽然这些改进肯定对那些旧版本有帮助，但 MongoDB 社区在 MongoDB 6 中引入了一种在数据库管道级别无缝处理此问题的方法。
Debezium 2.5 的 MongoDB 连接器现在使用 $changeStreamSplitLargeEvent 聚合功能，该功能是 MongoDB 6.0.9 的一部分引入的。这可以避免在处理超出 MongoDB 16MB 文档大小限制的文档时出现 BSONObjectTooLarge 异常。这个新功能由 oversize.handling.mode 选项控制，该选项默认失败。如果您想利用这个新的选择加入功能，请调整此配置。
Debezium 只是利用了 MongoDB 数据库的底层功能。因此，该数据库仍然存在 MongoDB 文档中讨论的一些限制，这些限制仍然可能导致不遵守 MongoDB 拆分规则的大型文档出现异常。

6.Mysql 8.2 support

MySQL 社区最近于 2023 年 10 月发布了一个新的创新版本 MySQL 8.2.0。这个新版本已经经过 Debezium 的测试，我们很高兴地宣布我们正式支持这个新的创新版本。

7.Mysql 高精度源时间戳

多个 MySQL 复制事件中已包含多个新的高精度时间戳字段。例如，在 MySQL 8.0.1 中，GTID 事件中添加了微秒分辨率的时间戳，指定在直接主数据库上提交事务以及在原始主数据库上提交事务时的时间戳。
Debezium 2.5 现在利用这些值，如果可用，则将它们用于 ts_ms 字段，如果不可用或者您使用的是 8.0.1 之前的 MySQL 版本，则回退到基于秒的精度。

8.从 PostgreSQL 16 备用服务器进行流式传输

在 PostgreSQL 16 中，您现在可以在备用实例上定义复制槽。这带来了大量的新选项，包括从副本而不是生产系统执行更改数据捕获以进行负载分配的能力，特别是在非常活跃的数据库中。
Debezium 2.5 现在支持连接到备用 PostgreSQL 16 服务器和流式更改。

9.Oracle 流媒体指标变化

在 Debezium 的早期版本中，有一个 Oracle 流指标 bean，它公开了跨越所有三个流适配器的所有指标选项。这通常会导致一些关于哪些指标适用于哪个流适配器的混乱，因此我们希望在这种情况下定义明确的区别。
在 Debezium 2.5 中，Oracle 流指标 bean 已分为三种不同的实现，每种适配器类型对应一种实现。对于可观察性堆栈，此更改应该是完全透明的，除非您之前在使用另一种适配器类型时收集一种适配器类型的指标。在这种情况下，您会发现该指标不再可用。
特别是对于 LogMiner 用户，多个指标已被重命名，旧指标已被弃用。虽然您仍然可以在 Debezium 2.5 中使用旧的指标名称，但这些名称计划在未来的 2.7+ 版本中删除。已弃用和重命名的指标如下：

Old/Deprecated Metric	New Metric
CurrentRedoLogFileName	CurrentLogFileNames
RedoLogStatus	RedoLogStatuses
SwitchCounter	LogSwitchCounter
FetchingQueryCount	FetchQueryCount
HoursToKeepTransactionInBuffer	MillisecondsToKeepTransactionsInBuffer
TotalProcessingTimeInMilliseconds	TotalBatchProcessingTimeInMilliseconds
RegisteredDmlCount	TotalChangesCount
MillisecondsToSleepBetweenMiningQuery	SleepTimeInMilliseconds
NetworkConnectionProblemsCounter	No replacement

10.Oracle LOB 行为

Debezium 2.5 调整了快照和流中的 LOB 行为。当 lob.enabled 设置为 false 时，将在快照期间显式包含不可用值占位符，以匹配流的行为。

11.SQL Server 通知改进

Debezium for SQL Server 的工作原理是读取数据库在所谓的捕获实例中捕获的更改。这些实例可以根据用户的需求来来去去，并且很难知道 Debezium 是否已经为给定的捕获实例完成了自己的捕获过程。
Debezium 2.5 通过发出一个名为 Capture Instance 的新通知聚合来解决这个问题，允许任何观察者意识到 Debezium 不再使用捕获实例的时间。此新通知包含各种连接器详细信息，包括连接器名称以及开始、停止和提交 LSN 值。

12.SQL Server 驱动程序更新

SQL Serer 2019 引入了指定特定于列的敏感度分类的功能，以便为敏感数据提供更好的可见性和保护。不幸的是，Debezium 2.4 及更早版本附带的当前驱动程序不支持此功能。 Debezium 2.5 引入了最新的 12.4.2 SQL Server 驱动程序，以便用户现在可以立即利用此功能。

13.JDBC sink批量支持

Debezium 于 2023 年 3 月首次引入 JDBC 接收器连接器，作为 Debezium 2.2 的一部分。在过去的几个月里，该连接器经历了多次迭代，以提高其稳定性、特性集和功能。 Debezium 2.5 建立在这些努力之上，引入了批量写入。
在以前的版本中，连接器分别处理每个主题事件；但是，新的批量写入支持模式会将事件收集到存储桶中，并使用尽可能少的事务边界将这些更改写入目标系统。此更改提高了连接器的吞吐量能力，并使与目标数据库的交互更加高效。

14.JDBC sink字段包含/排除

Debezium 2.5 引入了新的 JBDC 接收器功能，用户现在可以指定事件负载中的哪些字段要包含在目标数据库写入操作中或从目标数据库写入操作中排除。此功能的工作原理与 Debezium 框架中的任何其他包含/排除组合一样，其中这两个属性是互斥的。
例如，如果我们有一个简单的事件负载，主题客户中包含以下字段：

 {"id": 12345,"name": "Acme","address": "123 Main Street"
}

如果我们想避免将address字段写入目标数据库，而只将id和name字段写入目标表，我们可以使用这个新功能来完成此任务。这可以通过添加 field.include.list 或 field.exclude.list 属性来完成。
阻止将地址字段写入目标的示例

{"field.exclude.list": "customers:address"
}

包含/排除字段的格式为 [:]，其中 topic-name 是可选的，如果您想避免写入所有事件的地址字段，则可以省略。

15.Debezium Server Operator

Debezium Server Operator for Kubernetes 在此 Debezium 2.5 预览版中得到了积极改进。多项改进包括：

能够在 CRD 中设置图像拉取机密
能够在 CRD DBZ-7052 中设置资源限制
将 OLM 捆绑脚本发布到 Maven Central
支持 OperatorHub 发布脚本中的 OKD/OpenShift 目录
显示 OLM 捆绑包中可用的名称和描述元数据
用于收集指标的新指标端点

CRD 的服务帐户

在 Debezium 的早期版本中，无法使用与预定义名称不同的服务帐户。这使得该过程对于用户来说有点麻烦，因为虽然您可以单独向此预定义帐户授予角色和授权，但这意味着您需要使用此预定义服务帐户，而不是您可能已经希望使用的帐户。
Debezium 2.5 简化了此过程，允许您现在使用自己的自定义服务帐户。

16.Kinesis 接收器改进

Debezium Server Kinesis 用户会很高兴地注意到 Debezium 2.5 的接收器适配器的可靠性得到了一些改进。现在，在适配器触发故障之前，Kinesis Sink 将自动重试失败记录的传送，最多尝试 5 次。这应该可以提高接收器适配器的传输可靠性，并有助于解决批量更改可能使接收器端点过载的情况。

17.EventHub 分区

在 Debezium Server 的早期版本中，用户可以指定固定分区 ID 将所有更改流式传输到单个分区，或者提供将在所有批处理操作上设置的静态分区键，这最终有助于将所有更改流式传输到同一个分区目标分区。在某些情况下，这可能会有所帮助，但它更经常导致下游处理的性能问题。
Debezium 2.5 调整了此行为以提高性能。默认情况下，当未定义partitionid或partitionkey时，EventHub接收器将使用循环技术将事件发送到所有可用分区。通过指定分区 ID，可以将事件强制放入单个固定分区中。或者，可以提供分区键来提供固定分区键，该固定分区键将用于将所有事件路由到特定分区。
如果需要额外的分区路由要求，您现在可以结合 PartitionRouting SMT 完成此类任务。

18.RabbitMQ 流接收器

RabbitMQ 在 3.9 版本中引入了 Streams，它利用快速高效的协议，可以与 AMQP 0.9.1 结合使用，以支持大扇出、重放和时间旅行以及具有极高吞吐量的大数据集。 Debezium 2.5 通过引入新的本机 Streams 实现来利用这一新的 Streams 实现。为了开始使用这个新的实现，请按如下方式配置 Debezium Server 接收器：

debezium.sink.type=rabbitmqstream
debezium.sink.rabbitmqstream.connection.host=<hostname of RabbitMQ>
debezium.sink.rabbitmqstream.connection.port=<port of RabbitMQ>

此外，如果您需要将任何其他连接参数传递给 RabbitMQ 连接，您可以通过将这些参数添加到带有前缀 debezium.sink.rabbitmqstream.connection 的配置来实现。传递任何配置属性。

19.Apache Kafka 接收器的 StreamNameMapper

现在可以通过自定义逻辑修改 Kafka 接收器行为，为特定功能提供替代实现。当替代实现不可用时，则使用默认实现。

20.AWS SQS sink

Amazon Simple Queue Service (Amazon SQS) 是一种分布式消息队列服务。它支持通过 Web 服务应用程序以编程方式发送消息，作为通过 Internet 进行通信的一种方式。 SQS 旨在提供高度可扩展的托管消息队列，解决常见的生产者-消费者问题或生产者与消费者之间的连接问题。
Debezium 2.5 提供了将事件发送到 Amazon SQS 的可能性。

21.Spanner

支持带有 Spanner 连接器的 Cloud Spanner 模拟器
Vitess 连接器的可恢复快照支持

22.IBM Informix Connector

Debezium 2.5 在其产品组合中引入了一个新的连接器，以收集 IBM Informix 的更改。 IBM Informix 是一种可嵌入的高性能数据库，用于将 SQL、NoSQL、JSON、时间序列和空间数据集成到一个位置。它专为边缘、云端或本地分析而设计。
IBM Informix 连接器与我们的任何社区领先连接器一样进行捆绑，它可以在 Maven Central 上找到，或者可以从Debezium 2.5 版本页面下载插件存档。
Maven 工件坐标为：

<dependency><groupId>io.debezium</groupId><artifactId>debezium-connector-informix</artifactId><version>2.5.0.Final</version>
</dependency>

23.MariaDB数据库预览支持

长期以来一直利用 MySQL 连接器作为捕获 MariaDB 更改的替代方案；然而，这种兼容性主要是最佳情况下的努力。
Debezium 2.5 版本流旨在通过采用非常清晰且有方法论的方法来逐步检查、验证并最终以与 MySQL 相同的能力支持 MariaDB，从而将 MariaDB 作为一流的连接器带到最前沿。我们的目标和希望是我们能够在 MySQL 连接器本身的范围内做到这一点；然而，围绕 GTID 支持仍有大量正在进行的调查，这可能会影响前进的道路。
Debezium 2.5 的第一个预览版本已经迈出了第一步，我们已经验证了该代码适用于单个 MariaDB 数据库部署，测试套件通过了，并且我们已经解决了 Binlog 客户端支持该部署所需的任何更改。我们的下一步是研究 GTID 支持，MariaDB 支持该支持，但使用的方法与 MySQL 不兼容。

24.MariaDB支持GTID

MySQL 和 MariaDB 都支持所谓的全局事务标识符或 GTID。它们在复制中用于唯一地标识整个集群中的事务。 MySQL 和 MariaDB 之间的实现细节存在显着差异，在 Debezium 的早期版本中，我们仅支持 MySQL 的 GTID。
在 Debezium 2.5 中，我们又向前迈出了一步，引入了对 MariaDB 的 GTID 支持，作为 MySQL 连接器产品的一部分。为了利用此行为，您需要通过使用前缀为 jdbc:mariadb 而不是 jdbc:mysql 的 JDBC 连接来使用 MariaDB 驱动程序而不是 MySQL 驱动程序。通过这样做，您现在可以像 MySQL一样充分利用 MariaDB 和 GTID。