在某些管道中，排序对消费应用程序至关重要。在某些情况下，这可能会影响数据管道的这一方面，例如 Kafka 重新分区发生时。这会导致在事后尝试重建排序时出现易出错的问题。

现在，当启用事务元数据时，这些元数据事件还将对其事务顺序进行编码，以便在发生 Kafka 重新分区或其他改变排序语义的场景时，消费者可以简单地使用新的编码顺序字段来实现事务的确定性排序 (DBZ-7698)。

有些用例中，增量快照信号需要转义完全限定表名中的某些字符。这导致阻塞快照出现一些问题，因为解析要快照的表的过程使用了略有不同的机制。在 Debezium 2.7 中，我们统一了这种方法，现在您可以根据需要将转义的表名与阻塞快照一起使用 (DBZ-7718)。

Debezium 2.7 附带了一个新的全局配置选项 streaming.delay.ms。这个新选项会使连接器在开始流式传输阶段之前执行延迟 (DBZ-7902)。

对于某些部署用例，您可能希望确保在流式传输阶段开始之前至少发生一次偏移量刷新间隔。在此类用例中，用户应确保 streaming.delay.ms 和 offset.flush.interval.ms 这两个属性都已对齐。

默认情况下，Debezium 不会执行延迟，并立即过渡到流式传输阶段，以保持与先前版本行为的一致性。

column.truncate.to.length.chars 配置属性得到了改进，现在支持字符串和数组字段类型的组合 (DBZ-7925)。

Debezium 2.7 引入了对 z/OS 平台上的 Db2 连接器的试验性支持。为了让 Db2 连接器能够与 z/OS 配合使用，需要进行一些配置选项的切换，以使其与 z/OS 平台数据库配合使用 (DBZ-4812)。

在 z/OS 模式下运行的主要切换是通过 db2.platform 进行的，该属性默认为 LUW，用于在 Linux、Unix 和 Windows 上运行。将此配置选项设置为 ZOS 可启用 z/OS。

此外，我们还添加了 cdc.control.schema 和 cdc.change.tables.schema 连接器配置属性。这些属性以前是硬编码为 ASNCDC 的，虽然这仍然是默认值，但如果您的安装使用了不同的 schema，现在也可以进行配置。

虽然 MariaDB 和 MySQL 通常共享许多相似的语法，但遗憾的是，在某些情况下，这两者之间存在细微差别，导致不兼容。其中一种不兼容是 Debezium JDBC sink 构建的 *upsert* 语句，在使用 MariaDB 作为目标数据库时无法执行。

Debezium 2.7 正式引入了 MariaDB 方言支持，用于 JDBC sink 连接器，使用户能够将 JDBC sink 配置为将 Kafka topic 的更改写入 MariaDB 目标 (DBZ-7874)。总的来说，不应有特殊的配置，因为 Hibernate 和 Debezium 都应该能够检测到目标是 MariaDB 并使用正确的方言。

Debezium 2.5 引入了对 MariaDB 的官方支持，作为现有 MySQL 连接器的一部分。在该演进的下一步中，现在有一个新的 MariaDB 独立连接器实现 (DBZ-7693)。

这里有几点值得注意

此连接器的文档仍在进行中，将在未来添加。目前，您可以参考 MySQL 连接器文档中与 MariaDB 相关的大部分内容。

在某些情况下，用户可能会发现生成 MySQL 和 MariaDB 行数估计的查询在某些环境中可能会对性能产生影响。

如果您确定此查询性能不佳，或者该计算不感兴趣，可以通过将 io.debezium.connector.binlog.BinlogSnapshotChangeEventSource.RowEstimate 的日志级别设置为 WARN 来安全地禁用它 (DBZ-7640)。

如果您部署在 Kafka Connect 上，请务必调整 Kafka Connect 的 log4j 配置。如果您使用 Debezium Server 进行部署，请根据 Quarkus 文档调整 application.properties 中的日志配置。

增量快照过程是各种恢复场景中从源表或集合收集部分或全部数据集的关键部分。关系型连接器长期以来都支持在增量快照信号上提供 additional-conditions 值来限制数据集，从而实现对特定数据行的定向重新同步。

我们很高兴地宣布，现在 MongoDB 也支持此功能 (DBZ-7138)。与关系型数据库不同，additional-conditions 应该以 JSON 格式提供。它将应用于指定的集合，使用 find 操作来获取要进行增量快照的文档子集列表。

在 MongoDB ExtractNewDocumentState 单消息转换器的先前版本中，删除事件不提供标识符作为 payload 的一部分。这降低了删除事件的意义，因为消费者收到的数据不足以对这些事件采取行动。此行为已得到改进，删除事件现在包含一个 _id 属性在 payload 中 (DBZ-7695)。

在 Debezium MongoDB 连接器的先前版本中，变更流可以针对部署和数据库范围打开，这对于具有严格权限限制的环境并不总是理想的。Debezium 2.7 引入了一种新的变更流模式，连接器可以在单个集合范围上运行，从而实现此类细粒度的权限配置 (DBZ-7760)。

添加了一个名为 collection 的新捕获范围值，可以通过 capture.scope 设置。如果连接器仅部署用于捕获 MongoDB 中单个集合的更改，则此设置非常有用。

请参阅 文档了解此新试验性功能的局限性。

在某些情况下，用户可能会发现生成 MySQL 和 MariaDB 行数估计的查询在某些环境中可能会对性能产生影响。

如果您确定此查询性能不佳，或者该计算不感兴趣，可以通过将 io.debezium.connector.binlog.BinlogSnapshotChangeEventSource.RowEstimate 的日志级别设置为 WARN 来安全地禁用它 (DBZ-7640)。

如果您部署在 Kafka Connect 上，请务必调整 Kafka Connect 的 log4j 配置。如果您使用 Debezium Server 进行部署，请根据 Quarkus 文档调整 application.properties 中的日志配置。

虽然 Oracle 建议用户避免使用基于 RAW 的列，但出于向后兼容性原因，这些列在标准 Oracle 表中仍然被广泛使用。但也有一些业务场景，继续使用 RAW 列而不是其他数据类型是有意义的。

Debezium 2.7 引入了一个专门针对 Oracle 的新自定义转换器，名为 RawToStringConverter (DBZ-7753)。这个自定义转换器旨在让您能够使用 STRING schema 类型，快速将 RAW 列的字节数组内容转换为基于字符串的字段。这对于您使用 RAW 列存储字符数据，而不需要 VARCHAR2 的排序开销，但仍需要将此字段作为基于字符串的数据发送给消费者的情况很有用。

要开始使用此自定义转换器，请参阅 文档以获取更多详细信息。

安装 Debezium 2.7 Oracle 连接器时，您可能会注意到一个新依赖项 orai18n.jar。此依赖项正在自动分发，以提供对某些方言的扩展字符集支持 (DBZ-7761)。

虽然 ROW_ID 在表在其生命周期内并非所有行的唯一标识，但在某些情况下，当表的生命周期和行的生命周期以非常严格的方式管理时，可以使用它。应社区的要求，我们在 Oracle 连接器的变更事件源信息块中添加了一个新的 row_id 字段 (DBZ-4332)。新字段将根据以下条件填充 ROW_ID 值

不符合标准的任何事件将不包含 row_id 字段，因为它被标记为 *可选*。

在 Debezium 的先前版本中，Oracle 连接器严格设计为在连接器用户账户的默认表空间中创建 LogMiner flush 表。这对于用户默认表空间可能不是理想位置的情况并不总是很有用，并且 DBA 会更希望该表存在于单独的表空间中。

以前，用户需要修改用户账户或使用一个具有正确表空间的新用户，才能在正确的表空间位置创建该表。使用 Debezium 2.7，这不再是必需的，您可以安全地在配置中包含目标 schema/表空间的名称 (DBZ-7819)。

schema 名称是可选的，如果未提供，连接器将继续使用与之前相同的遗留行为，在用户默认表空间中创建 flush 表并检查其是否存在。

Debezium Oracle 连接器可以轻松支持单个连接器部署中的数千个表；但是，您可能发现您想使用 IN 模式自定义查询过滤器。此模式用于在将更改传递给 Debezium 进行处理之前，在数据库级别过滤掉大量其他表的更改。

在早期版本中，当 log.mining.query.filter.mode 设置为 in 且包含的表列表包含超过 1000 个元素时，用户可能会注意到生成 SQL 错误。Oracle 不允许在 in-clause 中包含超过 1000 个元素；但是，Debezium 2.7 通过在多个 1000 个元素 in-clause 列表的桶之间进行析取来解决此限制 (DBZ-7847)。

JDBC sink 连接器支持将源列映射到 Kafka ARRAY 类型 payload 字段。使用 Debezium 2.7，您现在可以将 ARRAY 类型字段序列化到目标 PostgreSQL 数据库，无需更改配置。新支持应该是完全透明的 (DBZ-7752)。

增量快照是 Debezium 的一项功能，用于通过临时的信号启动快照来捕获源数据库中一个或多个表的全部或部分历史数据。此过程通常需要写入信号数据库表，以在事务日志中维护打开/关闭的 watermark，以便与与增量快照流重叠的变更流进行去重。

Debezium 已支持 MySQL 和 MariaDB 等其他数据库供应商的只读增量快照；但是，Debezium 2.7 引入了对 PostgreSQL 的只读增量快照支持。如果您想要了解更多信息，请查看 设计提案。

此过程通过使用 pg_current_snapshot 函数来获取有关数据库当前活动事务的信息，该函数仅在 PostgreSQL 13 上可用。这意味着要使用只读增量快照，您必须使用 PostgreSQL 13 或更高版本。

为了在 PostgreSQL 13 或更高版本上激活只读增量快照，您只需在连接器配置中添加 read.only 连接器配置属性并将其设置为 true。当设置为 true 时，增量快照实现将选择使用只读实现，这与 MySQL 和 MariaDB 的行为类似 (DBZ-7917)。

heartbeat.action.query 连接器配置属性允许连接器在 heartbeat.interval.ms 定义的间隔执行写入操作到源数据库。写入操作旨在生成一个变更事件，该事件由连接器捕获，并发送到 Kafka 或目标系统。

在正在积极捕获更改的数据库中，您无需担心设置 heartbeat.action.query，因为持续的更改流足以使偏移量与事务日志中的读取位置同步。但是，如果连接器从对非捕获表更改量高于对捕获表更改量的源进行捕获，则此功能有助于使偏移量中的读取位置与较低的捕获活动同步。

在 Debezium 2.7 中，我们为 SQL Server 添加了对该属性的支持 (DBZ-7801)。有关更多详细信息，请参阅 SQL Server 文档。

Cassandra 连接器在 Debezium 2.7 中也进行了一些更改，特别是性能优化方面。KafkaRecordEmitter 的实现依赖于一个线程同步块，这降低了吞吐量。此外，该实现还进行了一些不必要的刷新，这也影响了性能。这段代码已经重写，以提高吞吐量并减少不必要的刷新调用 (DBZ-7722)。

Debezium 关系型连接器依赖于配置选项 time.precision.mode 来控制如何将时间值添加到变更事件中。在某些情况下，您可能希望使用与 Kafka 类型对齐的模式，例如使用 connect 模式。在其他情况下，您可能更希望通过使用默认的 adaptive_milliseconds 模式来避免精度损失。

Debezium for Vitess 连接器传统上不遵循此模型，而是将时间值作为基于字符串的类型发出。虽然这有助于在使用 connect 模式时避免精度损失问题，但它会给消费者带来不必要的开销来解析和操作这些值。

在 Debezium 2.7 中，Vitess 将此行为与其他关系型连接器保持一致，使用 time.precision.mode 来控制时间值的发送方式 (DBZ-7773)。默认情况下，它将使用 adaptive_milliseconds 模式，但您可以根据需要自定义为使用 connect 模式。已移除基于字符串的时间值发出。

Debezium 提供了一种机制，可以通过 heartbeat.action.query 连接器配置属性定期写入数据库以发出同步事件。对于 Vitess，这没有必要，因为 Vitess/VStream 提供了开箱即用的 HeartbeatInterval 标志。

Debezium 2.7 使用 HeartbeatInterval VStream 标志，用户只需在连接器配置中设置 heartbeat.interval.ms。由于在 VStream 中观察到心跳标志，将根据该间隔发出心跳事件 (DBZ-7962)。

Debezium Server 的 NATS 流式传输 sink 适配器得到了改进，支持 JWT/seed 身份验证 (DBZ-7829)。要开始使用基于 JWT/seed 的身份验证，请在配置中提供以下必要值

有关此和其他更多信息，请参阅 NATS 文档，了解有关 JWT 和 NKey seed 身份验证的详细信息。

Debezium Server 的 NATS JetStream sink 在 Debezium 2.7 中也包含身份验证和加密支持的改进。现在支持多个新的配置属性，用于将密钥库详细信息传递给 sink 适配器 (DBZ-7922)。

要开始使用新的身份验证和加密功能，只需将上述三个配置包含在您的 Debezium Server 配置中，并使用适当的值。

JMX Exporter 代理已作为 Debezium Server 容器镜像的一部分添加。这应该使用户能够轻松获取连接器指标，而无需额外配置即可运行 Debezium Server (DBZ-7913)。

要启用 JMX Exporter，只需在创建基于 debezium/debezium-server:2.7 或更高版本的容器时指定 JMX_EXPORTER_PORT 环境变量，并确保代理的端口在容器外部可访问。

为了改进 Debezium Operator 的部署，可以使用 https://charts.debezium.io 上的 Helm Chart 进行安装。这避免了将 Operator 安装到单独命名空间中的复杂部署模型，最大限度地减少了在 Kubernetes 上管理多个 Debezium Server 部署的复杂性。

如果您使用 Debezium Operator 在 Kubernetes 上部署 Debezium Server，则可以直接通过 Operator 自定义资源启用 Debezium Server 中的新 JMX Exporter 功能 (DBZ-7914)。要开始与 Operator 一起使用 Exporter，已添加新的配置操作

在自定义资源中，jmxExporter.enabled 用于启用或禁用 Exporter。此外，可以使用 jmxExporter.configFrom 部分中的键/值对提供指标配置。

使用注解 debezium.io/stop=true 将副本缩减到零时，Debezium Server 将被停止 (DBZ-7953)。