Debezium日常分享系列之：Debezium 2.6.0.Beta1发布

最新推荐文章于 2024-05-15 09:05:28 发布

快乐骑行^_^

最新推荐文章于 2024-05-15 09:05:28 发布

阅读量812

点赞数 9

本文链接：https://blog.csdn.net/zhengzaifeidelushang/article/details/136522426

版权

日常分享专栏专栏收录该内容

484 篇文章 89 订阅

订阅专栏

Debezium日常分享系列之：Debezium 2.6.0.Beta1发布

一、重大改变
- 1.Oracle
- 2.Container Images
二、改进和变化
三、总结

一、重大改变

1.Oracle

在旧版本的 Debezium 中，用户需要手动安装 ojdbc8.jar JDBC 驱动程序。在 2.6 中，连接器现在将 Oracle JDBC 驱动程序与连接器捆绑在一起，因此不再需要手动安装。
我们还将驱动程序更新到版本 21.11.0.0，请确认升级到 Debezium 2.6后您没有多个版本。

2.Container Images

connect-base 容器映像中 MAVEN_DEP_DESTINATION 环境变量的处理已更改，该容器映像是 debezium/connect 的基础。
它不再用于下载所有依赖项，包括连接器，而仅用于通用 Maven Central 位于的依赖项。如果您使用依赖于此环境变量的自定义映像，则您的映像构建步骤可能需要修改。

二、改进和变化

1.用于 iSeries 连接器的 Db2

Debezium 2.6 引入了一个全新的连接器，供 IBM 粉丝使用 IBM iJournal 系统传输来自 Db2 iSeries/AS400 的更改。此次合作是社区多年的开发成果，我们很高兴社区允许将其在 Debezium 的保护下进行分发。
可以使用以下坐标从 Maven Central 获取新连接器或直接下载。

<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-connector-ibmi</artifactId>
    <version>2.6.0.Beta1</version>
</dependency>

此新连接器的文档仍在进行中。

2.PostgreSQL 的增量快照行值构造函数

PostgreSQL 驱动程序支持使用 ROW() 函数的称为行值构造函数的 SQL 语法。这允许查询在使用具有合适索引的多列主键时以更有效的方式表达谓词条件。增量快照过程是使用 ROW() 函数的理想选择，该过程涉及发出一系列 select SQL 语句以分块获取数据。理想情况下，每个语句（也称为块查询）应该尽可能高效，以最大限度地减少这些查询的成本开销，从而最大限度地提高主题的 WAL 更改的吞吐量。
不需要进行任何具体更改，但对 PostgreSQL 增量快照发出的查询已进行调整以利用此新语法，因此使用增量快照的用户应该会看到性能改进。
对于一个简单的表，使用的旧查询的示例可能如下所示：

SELECT *
  FROM users
 WHERE (a = 10 AND (b > 2 OR b IS NULL)) OR (a > 10) OR (a IS NULL)
 ORDER BY a, b LIMIT 1024

新的实现使用 ROW() 函数构造此查询，如下所示：

SELECT *
  FROM users
 WHERE row(a,b) > row(10,2)
ORDER BY a, b LIMIT 1024

3.信号表水印元数据

增量快照过程需要一个信号表来写入打开/关闭标记，以协调更改边界与事务日志中记录的数据，除非您使用 MySQL 的只读风格。在某些情况下，用户希望能够跟踪窗口时间段，了解窗口何时打开和关闭。
从 Debezium 2.6 开始，信号表中的数据列将填充时间窗口详细信息，允许用户获取窗口何时打开和关闭。下面显示了两个信号标记各自的数据列的详细信息：

Window Open Marker

{"openWindowTimestamp": "<window-open-time>"}

Window Close Marker

{"openWindowTimestamp": "<window-open-time>", "closeWindowTimestamp": "<window-close-time>"}

4.Oracle 使用 LogMiner 重做每个事件的 SQL

我们改进了 Oracle 连接器的插入、更新和删除事件结构，以选择性地包含由 LogMiner 在源信息块中重建的 SQL。此功能是一项仅限选择加入的功能，您必须启用该功能，因为这很容易使现有事件负载的大小增加一倍以上。

要允许将 REDO SQL 作为更改事件的一部分包含在内，请添加以下连接器配置：

"log.mining.include.redo.sql": "true"

启用该选项后，源信息块包含一个新字段redo_sql，如下所示：

"source": {
  ...
  "redo_sql": "INSERT INTO \"DEBEZIUM\".\"TEST\" (\"ID\",\"DATA\") values ('1', 'Test');"
}

由于 LogMiner 重构与 CLOB、BLOB 和 XML 数据类型相关的 SQL 的方式，此功能无法在 lob.enabled 设置为 true 的情况下使用。如果在 lob.enabled 设置为 true 的情况下添加上述配置，连接器将启动并显示有关此错误配置的错误。

5.Oracle LogMiner 事务缓冲区改进

使用 LogMiner 时添加了新的事务注册延迟策略。该策略有效地延迟了缓冲区中事务记录的创建，直到我们观察到该事务的第一个捕获的更改。
对于使用Infinispan缓存或启用了lob.enabled的用户，由于连接器这两种模式下具体操作的处理方式，无法使用此延迟策略。

延迟交易注册有很多好处，其中包括：

减少事务缓存的开销，特别是在高并发事务场景下。
避免长时间运行的事务没有连接器捕获的任何更改。
应有助于在特定场景中更有效地推进偏移中的低水印 SCN。

我们正在研究如何在未来的版本中为基于 Infinispan 的用户探索这一变化；但是，由于 lob.enabled 与 LogMiner 配合使用的性质，该功能对于该用例来说是不可能的。

6.提高了事件时间戳精度

Debezium 2.6 引入了社区要求的新功能，以提高更改事件中时间戳的精度。用户现在会注意到添加了 4 个新字段，其中两个位于信封级别，两个位于源信息块中，如下所示：

{
  "source": {
    ...,
    "ts_us": "1559033904863123",
    "ts_ns": "1559033904863123000"
  },
  "ts_us": "1580390884335451",
  "ts_ns": "1580390884335451325",
}

包络值将始终提供微秒 (ts_us) 和纳秒 (ts_ns) 值，而如果源数据库不提供该精度级别，则源信息块可能具有被截断为较低精度的微秒和纳秒精度值。

7.Informix 将 LSN 附加到事务标识符

Informix 数据库仅在存在并发事务时增加事务标识符，否则对于顺序事务，该值保持相同。对于可能想要在后处理步骤中利用事务元数据来排序更改事件的用户来说，这可能会很困难。
Debezium 2.6 for Informix 现在会将日志序列号 (LSN) 附加到事务标识符，以便用户可以轻松地根据事务元数据对更改事件进行排序。事务标识符字段现在将使用格式 :。此更改会影响交易元数据事件以及更改事件的源信息块，如下所示：

Transaction Begin Event

{
  "status": "BEGIN",
  "id": "571:53195829",
  ...
}

Transaction End Event

{
  "status": "END",
  "id": "571:53195832",
  ...
}

Change Events

{
  ...
  "source": {
    "id": "571:53195832"
    ...
  }
}

8.新的基于任意的有效负载格式

虽然用户通常使用基于 Json、Avro、Protobufs 或 CloudEvents 的序列化，Debezium 可以配置为使用两种新格式，称为简单字符串和二进制。
简单字符串和二进制格式是使用 debezium.format 配置在 Debezium 服务器中配置的。对于 simplestring，有效负载将作为单个 STRING 数据类型序列化到主题中。对于二进制文件，有效负载将使用 byte[]（字节数组）序列化为 BYTES。

9.Oracle LogMiner 混合挖矿策略

Debezium 2.6 还引入了一种名为 hyrid 的新 Oracle LogMiner 挖掘策略，可以通过将配置属性 log.mining.strategy 设置为 Hybrid 值来启用该策略。这种新策略旨在支持默认挖掘策略的所有模式演化功能，同时利用在线目录策略的所有性能优化。
online_catalog 策略的主要问题是，如果挖掘步骤在同一挖掘步骤中观察到模式更改和数据更改，则 LogMiner 无法正确重建 SQL，这将导致表名称为 OBJ# xxxxxx 或列表示为 COL1、COL2 等。为了在使用在线目录策略时避免这种情况，建议用户以锁步模式执行模式更改，以避免同时观察模式更改和数据更改的挖掘步骤；然而，这并不总是可行的。
新的混合策略的工作原理是在数据库级别跟踪表的对象 ID，然后使用该标识符从 Debezium 的关系表模型中查找与该表关联的模式。简而言之，这使得 Debezium 能够完成 Oracle LogMiner 在这些特定的极端情况下无法完成的任务。表名将从关系模型的表名中获取，列将按列位置映射。
不幸的是，Oracle 没有提供一种方法来重建 CLOB、BLOB 和 XML 数据类型的失败 SQL 操作。这意味着新的混合策略无法使用将 lob.enabled 设置为 true 的配置进行配置。如果连接器使用混合策略启动并将 lob.enabled 设置为 true，则连接器将无法启动并报告配置失败。