当 Oracle 连接器执行其初始查询以从 LogMiner 获取数据时，database.query.timeout.ms 连接器配置属性将控制查询的持续时间，之后查询将被取消 (DBZ-8830)。升级时，请检查连接器指标 MaxDurationOfFetchQueryInMilliseconds 以确定此新属性是否可能需要调整。默认超时时间为 10 分钟，但设置为 0 时可禁用。

我们深知数据库包含各种信息，其中一些列可能包含敏感信息。我们很自豪能够确保信息安全可靠。因此，我们通常倾向于避免在 INFO、WARN 或 ERROR 级别记录敏感信息。

然而，在某些潜在的极端情况下，敏感列的值可能会在 DEBUG 或 TRACE 级别被记录。我们在几年前添加了 io.debezium.util.Loggings 类来集中处理此事，但并非所有实例都使用了该 Loggings 类 (DBZ-8525)。

默认情况下，用户会注意到 Loggings 类将敏感信息记录在日志中，而不是包含在原始日志条目中的记录器中。如果您希望省略敏感信息，可以使用日志配置为 io.debezium.util.Loggings 设置一个特定的日志级别。

例如，如果您需要向他人提供日志，但又想省略敏感信息，则以下配置可以实现该目标。

此配置将省略所有敏感信息，同时在 TRACE 级别记录所有非敏感信息。

我们收到了社区的一些报告，称在高峰期，一些数据库出现了异常高的 CPU 利用率。经过调查，我们发现一些 SQL 查询执行过于频繁，导致 CPU 占用过高，并降低了连接器的写入吞吐量 (DBZ-8570)。现在，用户应该会发现 JDBC sink 的写入吞吐量更高，CPU 利用率也比之前更合理。

对于 Kafka Connect producer，如果连接器抛出 RetriableException，并且 Kafka Connect 配置为支持错误重试，那么运行时将自动停止并重启连接器。这提供了一种处理资源销毁和重新创建（如数据库连接）的有用方法。

但对于 Kafka Connect consumer (sink)，连接器的生命周期工作方式不同。当连接器抛出错误时，生命周期不会停止和重启连接器，而是再次调用 put 方法。在某些连接错误的情况下，这可能会出现问题，因为某些资源不会自动重新创建。

从 Debezium 3.1 开始，新的 JDBC sink 连接器属性 connection.restart.on.errors 将允许 JDBC sink 重试连接失败 (DBZ-8727)。

新增了一个 JDBC sink 映射，用于将 Kafka BYTES 字段转换为 VARBINARY 列数据类型 (DBZ-8790)。这允许源连接器将未知或其他二进制数据序列化为 Kafka BYTES 字段，并正确映射到具有 VARBINARY 列数据类型的 SQL Server 目标。

对于大多数连接器，Debezium 遵循对所有 SQLException 或 IOException 相关失败进行重试的理念。这种策略非常有用，允许用户根据需要利用运行时重试机制。

然而，对于 MySQL，这会产生一个独特的极端情况，即在配置的服务器 ID/UUID 出现冲突时。MySQL 使用服务器 ID/UUID 在集群拓扑中唯一标识一个实例。如果多个服务器使用相同的 ID/UUID，该实例将抛出 SQLException 并在启动时进入重试/回退循环。

在 Debezium 3.1 中，对于这个特定的独特情况，错误处理倾向于采用快速失败的策略 (DBZ-8786)。如果您是 MySQL 用户，并且发现您的连接器更频繁地进入 FAILED 状态，我们建议您检查是否适用此用例。如果适用，您应该确保您的配置始终使用唯一的服务器 ID/UUID 值。

从 Vitess v21 开始，为 VStream 引入了一种新的 binlog 水印策略。这项新功能会发送一个“心跳”类事件，表示 VStream 客户端已收到截至提供时间戳的 shard binlog 事件。

可以通过将新的配置选项 vitess.stream.keyspace.heartbeats 设置为 true 来包含写入 keyspace 心跳表的这些心跳事件 (DBZ-8775)。table.include.list 也应该包含心跳表，格式为 <keyspace>.heartbeat。

我们在 DBZ-6387 中引入了新的时间精度模式 IOSTRING，它允许将时间值序列化为 ISO8601 格式的字符串。我们很高兴地报告 Vitess 连接器支持这种新模式 (DBZ-8826)。

在 Debezium 3.1 中，我们改变了通过配置路由事件的方式。这种新方法采用了基于策略的设计，保留了旧的行为并引入了新的基于键的路由机制 (DBZ-8752)。

首先，rabbitmq.routingKeyFromTopicName 已弃用，将在未来版本中删除。此功能已合并到新的 rabbitmq.routingKey.source 配置属性中，可以设置为以下值之一

Change Data Capture (CDC) 在各种场景中得到广泛应用，例如微服务通信、遗留系统现代化和缓存失效。此模式的核心思想是检测和跟踪数据源（例如数据库）中的更改，并近乎实时地将它们传播到其他系统。Debezium 是一个 CDC 平台，为大多数数据源提供了广泛的连接器。除了捕获更改外，它还通过直观的 UI 提供转换功能，用于定义 Debezium 实例。

查看我们最近的博客 Superfast Debezium，其中介绍了使用 Debezium 和 GraalVM 的最新示例！