Debezium日常分享系列之：Debezium 3.1.0.CR1发布

这个新版本包括对JDBC接收器和MySQL连接器的多项改进，支持ISO字符串时间值和使用Vitess的键空间心跳，基于键的RabbitMQ路由等。让我们深入了解这些新功能和改进。

重大改变

查询超时现在适用于 Oracle LogMiner 查询

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

新功能和改进

升级到 Debezium 3.1.0.CR1 引入了多个组件中的几个新功能和改进：

核心：集中记录敏感数据

我们理解数据库中存储了各种信息，其中某些列可能包含敏感信息。我们致力于确保这些信息的安全性和保密性。因此，我们通常避免在 INFO、WARN 或 ERROR 级别记录敏感信息。

然而，在某些潜在的特殊情况中，敏感列的值可能会在 DEBUG 或 TRACE 级别被记录。为了集中处理这一点，我们在几个版本前引入了 io.debezium.util.Loggings 类，但并非所有实例都在使用这个 Loggings 类。

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

例如，如果您需要将日志提供给某人但希望省略敏感信息，以下配置可以实现这一目标。

log4j.logger.io.debezium=TRACE,stdout
log4j.logger.io.debezium.util.Loggings=ERROR,stdout

JDBC: 提高了性能

• 我们收到了多个社区报告，指出在高峰时段，某些数据库出现了异常高的CPU利用率。经过调查，我们发现有几个SQL查询执行过于频繁，导致CPU占用率高，并降低了连接器的写入吞吐量。现在用户应该会发现JDBC接收器的写入吞吐量更高，CPU利用率也比之前更合理。

JDBC: 连接错误时自动重试

• 对于 Kafka Connect 生产者，如果连接器抛出一个 RetriableException，并且 Kafka Connect 配置为支持错误重试，运行时会自动停止并重新启动该连接器。这提供了一种有用的方式来处理资源的释放和重新创建，例如数据库连接。
• 但对于 Kafka Connect 消费者（接收端），连接器的生命周期工作方式不同。当连接器抛出错误时，其生命周期不会停止并重新启动连接器，而是再次调用 put 方法。这在某些连接错误的情况下可能是个问题，因为特定资源不会被自动重新创建。
• 从 Debezium 3.1 开始，新的 JDBC 接收端连接器属性 connection.restart.on.errors 将允许 JDBC 接收端在连接失败时重试 (DBZ-8727)。

JDBC: 将BYTES处理为SQL Server目标的VARBINARY

• 新增了一个JDBC下沉映射，用于将Kafka的BYTES字段转换为SQL Server的VARBINARY列数据类型。这使得源连接器可以将未知或其他二进制数据序列化为Kafka的BYTES字段，并正确映射到具有VARBINARY列数据类型的SQL Server目标。

MySQL: 改进重复服务器ID/UUID的错误处理

• 对于大多数连接器，Debezium 采用了重试所有与 SQLException 或 IOException 相关故障的策略。这一策略非常有用，允许用户根据需要利用运行时的重试机制。
  然而，对于 MySQL，当配置的服务器ID/UUID存在冲突时，这会带来一个独特的边缘情况。MySQL 使用服务器ID/UUID在集群拓扑中唯一标识一个实例。如果多于一个服务器使用相同的ID/UUID，实例将抛出一个SQLException，并在启动时进入重试/退避循环。
  在 Debezium 3.1 中，错误处理对这种特定的独特情况采取了快速失败（fail-fast）的方法。如果您是 MySQL 用户并且发现您的连接器更频繁地进入FAILED状态，我们建议检查这种情况是否适用于您。如果是，您应确保您的配置始终使用唯一的服务器ID/UUID值。

Vitess: 增加了键空间心跳支持

• 从 Vitess v21 开始，为 VStream 引入了一种新的二进制日志水印策略。此新功能发送一种类似于“心跳”的事件，表示该分片的二进制日志事件已由 VStream 客户端接收至所提供的时间戳。
• 可以通过将新的配置选项 vitess.stream.keyspace.heartbeats 设置为 true 来包含写入到键空间心跳表的心跳事件。同时，table.include.list 应该包含心跳表，格式为 <‍键空间‍>.heartbeat。

Vitess: 支持 ISO 字符串模式时间精度模式

• 我们在 DBZ-6387 中引入了新的时间精度模式 ISOSTRING，允许使用 ISO8601 格式将时间值序列化为字符串。我们很高兴地报告，Vitess 连接器现在支持这一新模式。

Debezium Server: 对 RabbitMQ 的键路由支持

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

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

• static
  • 当使用静态路由源时，RabbitMQ 消费端将使用您在消费端配置中指定的 rabbitmq.routingKey 静态值。由于该值在配置中设置并在消费端启动时读取，因此它是静态的，在消费端运行期间不会改变。
• topic
  • 当使用主题路由源时，RabbitMQ 消费端将根据目标主题名称生成路由键。此模式替换了现已弃用的 rabbitmq.routingKeyFromTopicName 配置属性行为。
• key
  • 当使用新的键路由源时，RabbitMQ 消费端将根据事件的记录键生成路由键。这提供了灵活性，可以选择使用原始的 Debezium 变更事件的键，或者通过自定义转换在发送事件到 RabbitMQ 之前更改事件的键。

示例：针对 GraalVM 优化的 Debezium

• 变更数据捕获（CDC）在各种场景中广泛应用，例如微服务通信、传统系统现代化和缓存失效。这种模式的核心思想是检测和跟踪数据源（例如数据库）中的变化，并将这些变化实时或接近实时地传播到其他系统。Debezium 是一个 CDC 平台，提供了广泛的数据源连接器。除了捕获变化之外，它还通过直观的用户界面提供定义 Debezium 实例的转换能力。