Debezium Db2 连接器

Db2 的复制功能并非旨在存储数据库更改的完整历史记录。因此，Debezium Db2 连接器无法从日志中检索数据库的整个历史记录。为了使连接器能够建立数据库当前状态的基线，连接器首次启动时，它将对处于 捕获模式 的表执行初始*一致快照*。对于快照捕获的每个更改，连接器都会向捕获表的 Kafka 主题发出一个 read 事件。

By default, a connector runs an initial snapshot operation only after it starts for the first time. Following this initial snapshot, under normal circumstances, the connector does not repeat the snapshot process. Any future change event data that the connector captures comes in through the streaming process only. (默认情况下，连接器仅在首次启动后运行初始快照操作。在初始快照之后，在正常情况下，连接器不会重复快照过程。连接器捕获的任何未来变更事件数据仅通过流式传输过程进入。)

However, in some situations the data that the connector obtained during the initial snapshot might become stale, lost, or incomplete. To provide a mechanism for recapturing table data, Debezium includes an option to perform ad hoc snapshots. You might want to perform an ad hoc snapshot after any of the following changes occur in your Debezium environment (但是，在某些情况下，连接器在初始快照期间获取的数据可能会过时、丢失或不完整。为了提供重新捕获表数据的机制，Debezium 提供了一个执行即席快照的选项。您可能希望在 Debezium 环境中发生以下任何更改后执行即席快照：)

You can re-run a snapshot for a table for which you previously captured a snapshot by initiating a so-called ad hoc snapshot. Ad hoc snapshots require the use of signaling tables. You initiate an ad hoc snapshot by sending a signal request to the Debezium signaling table. (您可以通过启动所谓的即席快照来重新运行之前捕获了快照的表的快照。即席快照需要使用信号表。通过向 Debezium 信号表发送信号请求来启动即席快照。)

When you initiate an ad hoc snapshot of an existing table, the connector appends content to the topic that already exists for the table. If a previously existing topic was removed, Debezium can create a topic automatically if automatic topic creation is enabled. (当您启动现有表的即席快照时，连接器会将内容追加到该表已存在的主题中。如果之前存在的主题已被删除，并且启用了自动主题创建，则 Debezium 可以自动创建主题。)

Ad hoc snapshot signals specify the tables to include in the snapshot. The snapshot can capture the entire contents of the database, or capture only a subset of the tables in the database. Also, the snapshot can capture a subset of the contents of the table(s) in the database. (即席快照信号指定要包含在快照中的表。快照可以捕获数据库的全部内容，或仅捕获数据库中表的部分内容。此外，快照还可以捕获数据库中表的部分内容。)

You specify the tables to capture by sending an execute-snapshot message to the signaling table. Set the type of the execute-snapshot signal to incremental or blocking, and provide the names of the tables to include in the snapshot, as described in the following table (您可以通过向信号表发送 execute-snapshot 消息来指定要捕获的表。将 execute-snapshot 信号的类型设置为 incremental 或 blocking，并提供要在快照中包含的表名称，如下表所示：)

您可以通过向信号表添加具有 execute-snapshot 信号类型的条目，或 向 Kafka 信号主题发送信号消息 来启动临时增量快照。在连接器处理消息后，它将开始快照操作。快照过程会读取第一个和最后一个主键值，并使用这些值作为每个表的开始和结束点。基于表中的条目数量以及配置的块大小，Debezium 将表分成块，然后逐个快照每个块。

有关更多信息，请参阅 增量快照。

You initiate an ad hoc blocking snapshot by adding an entry with the execute-snapshot signal type to the signaling table or signaling topic. After the connector processes the message, it begins the snapshot operation. The connector temporarily stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the connector resumes streaming. (您可以通过向信号表或信号主题添加具有 execute-snapshot 信号类型的条目来启动即席阻塞快照。在连接器处理消息后，它将开始快照操作。连接器将暂时停止流式传输，然后启动指定表的快照，遵循其在初始快照期间使用的相同过程。快照完成后，连接器将恢复流式传输。)

有关更多信息，请参阅 阻塞快照。

To provide flexibility in managing snapshots, Debezium includes a supplementary snapshot mechanism, known as incremental snapshotting. Incremental snapshots rely on the Debezium mechanism for sending signals to a Debezium connector. Incremental snapshots are based on the DDD-3 design document. (为了在管理快照时提供灵活性，Debezium 提供了一个补充快照机制，称为增量快照。增量快照依赖于 Debezium 向 Debezium 连接器发送信号的机制。增量快照基于DDD-3 设计文档。)

在增量快照中，Debezium 不是一次性捕获数据库的全部状态（如初始快照），而是分阶段、以一系列可配置的块来捕获每个表。您可以指定快照要捕获的表以及每个块的大小。块大小决定了快照在每次从数据库提取操作中收集的行数。增量快照的默认块大小为 1024 行。

As an incremental snapshot proceeds, Debezium uses watermarks to track its progress, maintaining a record of each table row that it captures. This phased approach to capturing data provides the following advantages over the standard initial snapshot process (随着增量快照的进行，Debezium 使用水位标记来跟踪其进度，并维护捕获的每个表行的记录。与标准的初始快照过程相比，这种分阶段的数据捕获方法提供了以下优势：)

运行增量快照时，Debezium 会按主键对每个表进行排序，然后根据配置的块大小将表分成块。通过逐块工作，它捕获块中的每个表行。对于它捕获的每一行，快照都会发出一个 READ 事件。该事件表示快照开始时行的值。

As a snapshot proceeds, it’s likely that other processes continue to access the database, potentially modifying table records. To reflect such changes, INSERT, UPDATE, or DELETE operations are committed to the transaction log as per usual. Similarly, the ongoing Debezium streaming process continues to detect these change events and emits corresponding change event records to Kafka. (随着快照的进行，其他进程很可能会继续访问数据库，可能修改表记录。为了反映这些更改，INSERT、UPDATE 或 DELETE 操作照常提交到事务日志。同样，正在进行的 Debezium 流式传输过程会继续检测这些变更事件，并将相应的变更事件记录发送到 Kafka。)

In some cases, the UPDATE or DELETE events that the streaming process emits are received out of sequence. That is, the streaming process might emit an event that modifies a table row before the snapshot captures the chunk that contains the READ event for that row. When the snapshot eventually emits the corresponding READ event for the row, its value is already superseded. To ensure that incremental snapshot events that arrive out of sequence are processed in the correct logical order, Debezium employs a buffering scheme for resolving collisions. Only after collisions between the snapshot events and the streamed events are resolved does Debezium emit an event record to Kafka. (在某些情况下，流式传输过程发出的 UPDATE 或 DELETE 事件可能会乱序接收。也就是说，流式传输过程可能会在快照捕获包含该行 READ 事件的块之前发出修改表行的事件。当快照最终发出行的相应 READ 事件时，其值已过时。为了确保乱序到达的增量快照事件按正确的逻辑顺序处理，Debezium 采用缓冲方案来解决冲突。仅当快照事件与流式事件之间的冲突得到解决后，Debezium 才会向 Kafka 发送事件记录。)

To assist in resolving collisions between late-arriving READ events and streamed events that modify the same table row, Debezium employs a so-called snapshot window. The snapshot window demarcates the interval during which an incremental snapshot captures data for a specified table chunk. Before the snapshot window for a chunk opens, Debezium follows its usual behavior and emits events from the transaction log directly downstream to the target Kafka topic. But from the moment that the snapshot for a particular chunk opens, until it closes, Debezium performs a de-duplication step to resolve collisions between events that have the same primary key. (为了帮助解决延迟到达的 READ 事件与修改同一表行的流式事件之间的冲突，Debezium 采用所谓的快照窗口。快照窗口划定了增量快照捕获指定表块数据的间隔。在某个块的快照窗口打开之前，Debezium 会遵循其常规行为，将事务日志中的事件直接向下游发送到目标 Kafka 主题。但在某个块的快照打开到关闭的整个过程中，Debezium 会执行去重步骤以解决具有相同主键的事件之间的冲突。)

For each data collection, the Debezium emits two types of events, and stores the records for them both in a single destination Kafka topic. The snapshot records that it captures directly from a table are emitted as READ operations. Meanwhile, as users continue to update records in the data collection, and the transaction log is updated to reflect each commit, Debezium emits UPDATE or DELETE operations for each change. (对于每个数据集合，Debezium 会发出两种类型的事件，并将两者的记录存储在单个目标 Kafka 主题中。它直接从表中捕获的快照记录作为 READ 操作发出。同时，随着用户继续更新数据集合中的记录，并且事务日志更新以反映每次提交，Debezium 会为每个更改发出 UPDATE 或 DELETE 操作。)

As the snapshot window opens, and Debezium begins processing a snapshot chunk, it delivers snapshot records to a memory buffer. During the snapshot windows, the primary keys of the READ events in the buffer are compared to the primary keys of the incoming streamed events. If no match is found, the streamed event record is sent directly to Kafka. If Debezium detects a match, it discards the buffered READ event, and writes the streamed record to the destination topic, because the streamed event logically supersede the static snapshot event. After the snapshot window for the chunk closes, the buffer contains only READ events for which no related transaction log events exist. Debezium emits these remaining READ events to the table’s Kafka topic. (随着快照窗口的打开，Debezium 开始处理快照块，它会将快照记录传递到内存缓冲区。在快照窗口期间，缓冲区中 READ 事件的主键与传入的流式事件的主键进行比较。如果未找到匹配项，则将流式事件记录直接发送到 Kafka。如果 Debezium 检测到匹配，它将丢弃已缓冲的 READ 事件，并将流式记录写入目标主题，因为流式事件在逻辑上取代了静态快照事件。当块的快照窗口关闭后，缓冲区将仅包含没有相关事务日志事件的 READ 事件。Debezium 将这些剩余的 READ 事件发送到表的 Kafka 主题。)

The connector repeats the process for each snapshot chunk. (连接器对每个快照块重复此过程。)

Currently, you can use either of the following methods to initiate an incremental snapshot (当前，您可以使用以下任一方法启动增量快照：)

For more advanced uses, you can fine-tune control of the snapshot by implementing one of the following interfaces (对于更高级的用途，您可以实现以下接口之一来微调快照的控制：)

To provide more flexibility in managing snapshots, Debezium includes a supplementary ad hoc snapshot mechanism, known as a blocking snapshot. Blocking snapshots rely on the Debezium mechanism for sending signals to a Debezium connector. (为了在管理快照时提供更大的灵活性，Debezium 提供了一个补充的即席快照机制，称为阻塞快照。阻塞快照依赖于 Debezium 向 Debezium 连接器发送信号的机制。)

A blocking snapshot behaves just like an initial snapshot, except that you can trigger it at run time. (阻塞快照的行为与初始快照完全相同，只是您可以随时在运行时触发它。)

You might want to run a blocking snapshot rather than use the standard initial snapshot process in the following situations (您可能希望在以下情况下运行阻塞快照，而不是使用标准的初始快照过程：)

When you run a blocking snapshot, Debezium stops streaming, and then initiates a snapshot of the specified table, following the same process that it uses during an initial snapshot. After the snapshot completes, the streaming is resumed. (运行阻塞快照时，Debezium 会停止流式传输，然后启动指定表的快照，遵循其在初始快照期间使用的相同过程。快照完成后，流式传输将恢复。)

You can set the following properties in the data component of a signal (您可以在信号的 data 组件中设置以下属性：)

For example (例如：)

A delay might exist between the time that you send the signal to trigger the snapshot, and the time when streaming stops and the snapshot starts. As a result of this delay, after the snapshot completes, the connector might emit some event records that duplicate records captured by the snapshot. (从您发送触发快照的信号到流式传输停止并开始快照之间可能存在延迟。由于此延迟，快照完成后，连接器可能会发出一些重复快照捕获记录的事件记录。)

在完成快照后，当 Debezium Db2 连接器首次运行时，连接器会为处于捕获模式的每个源表标识变更数据表。连接器对每个变更数据表执行以下操作：

重启后，连接器将从上次中断的偏移量（提交和更改 LSN）处继续发出更改事件。当连接器正在运行并发出更改事件时，如果您将一个表从捕获模式中移除或将一个表添加到捕获模式中，连接器将检测到该更改，并相应地修改其行为。

默认情况下，Db2 连接器会将表中所有 INSERT、UPDATE 和 DELETE 操作的更改事件写入一个特定于该表的 Apache Kafka 主题。连接器使用以下约定来命名更改事件主题：

topicPrefix.schemaName.tableName

以下列表提供了默认名称组件的定义：

例如，考虑一个具有 mydatabase 数据库的 Db2 安装，该数据库包含 PRODUCTS、PRODUCTS_ON_HAND、CUSTOMERS 和 ORDERS 四个表，它们位于 MYSCHEMA 模式下。连接器会将事件发出到以下四个 Kafka 主题：

连接器应用类似的命名约定来标记其内部数据库模式历史主题、模式更改主题和事务元数据主题。

如果默认主题名称不符合您的要求，您可以配置自定义主题名称。要配置自定义主题名称，请在逻辑主题路由 SMT 中指定正则表达式。有关使用逻辑主题路由 SMT 自定义主题命名的更多信息，请参阅 主题路由。

当数据库客户端查询数据库时，客户端使用数据库的当前模式。但是，数据库模式可以随时更改，这意味着连接器必须能够识别在记录每次插入、更新或删除操作时模式是什么。此外，连接器不一定能将当前模式应用于每个事件。如果事件相对较旧，它可能是在应用当前模式之前记录的。

为确保正确处理模式更改后发生的事件，Debezium Db2 连接器会基于 Db2 变更数据表（镜像其关联数据表结构的结构）存储新模式的快照。连接器会将表模式信息与导致模式更改的操作的 LSN 一起存储在数据库模式历史 Kafka 主题中。连接器使用存储的模式表示来生成更改事件，这些事件正确地镜像了在每次插入、更新或删除操作时表的结构。

当连接器在崩溃或正常停止后重新启动时，它将从上次读取的位置恢复读取 Db2 变更数据表中的条目。基于连接器从数据库模式历史主题读取的模式信息，连接器将应用连接器重新启动时存在的表结构。

如果您更新了处于捕获模式的 Db2 表的模式，您还必须更新相应变更表的模式。您必须是具有高级权限的 Db2 数据库管理员才能更新数据库模式。有关如何在 Debezium 环境中更新 Db2 数据库模式的更多信息，请参阅 模式历史演进。

数据库模式历史主题仅供连接器内部使用。可选地，连接器还可以将模式更改事件发出到为使用者应用程序设计的不同主题。

您可以配置 Debezium Db2 连接器以生成描述数据库中应用于表的模式更改的模式更改事件。

当发生以下情况时，Debezium 会将消息发出到模式更改主题：

连接器将模式更改事件写入一个名为 <topicPrefix> 的 Kafka 模式更改主题，其中 <topicPrefix> 是在 topic.prefix 连接器配置属性中指定的 «主题前缀»。

模式变更事件的模式具有以下元素：

以下示例以 JSON 格式显示了典型的模式。

连接器发送到模式更改主题的消息包含一个载荷，其中包括以下元素：

以下示例显示了模式更改主题中的一条消息。该消息包含表的逻辑表示。

在连接器发送到模式更改主题的消息中，消息键是包含模式更改的数据库的名称。在以下示例中，payload 字段包含键：

Debezium 可以生成表示事务边界的事件，并丰富更改数据事件消息。

Debezium 为每个事务中的 BEGIN 和 END 分隔符生成事务边界事件。事务边界事件包含以下字段：

除非通过 topic.transaction 选项覆盖，否则连接器会将事务事件发出到 <topic.prefix>.transaction 主题。

启用事务元数据后，连接器会在更改事件 Envelope 中添加一个新的 transaction 字段。此字段以字段的复合形式提供有关每个事件的信息：

以下是消息示例

更改事件的键包含已更改表的键的模式和已更改行的实际键。模式和相应的有效负载都包含已更改表的

PRIMARY KEY（或唯一约束）在连接器创建事件时的每个列的字段。

考虑以下 customers 表，后面是该表更改事件键的示例。

捕获对 customers 表所做的更改的每个更改事件都具有相同的事件键模式。只要 customers 表具有之前的定义，捕获对 customers 表所做的更改的每个更改事件都具有以下键结构。在 JSON 中，它看起来像这样：

更改事件中的值比键要复杂一些。与键一样，值也包含 schema 部分和 payload 部分。schema 部分包含描述 payload 部分的 Envelope 结构的模式，包括其嵌套字段。对于创建、更新或删除数据的操作的更改事件，其值有效负载都具有信封结构。

考虑用于显示更改事件键示例的相同样本表。

customers 表的每个更改事件的值部分指定相同的模式。事件值的有效负载根据事件类型而变化：

以下示例显示了连接器为在 customers 表中创建数据的操作生成的更改事件的值部分：

样本 customers 表更新的更改事件的值具有与该表的create 事件相同的模式。同样，事件值有效负载具有相同的结构。但是，在update 事件中，事件值有效负载包含不同的值。以下是连接器为 customers 表中的更新生成的事件中的更改事件值示例：

delete 更改事件中的值与同一表的create 和update 事件具有相同的 schema 部分。样本 customers 表的delete 事件中的事件值 payload 如下所示：

删除更改事件记录为使用者提供了处理此行删除所需的信息。旧值包含在内，因为某些使用者可能需要它们来正确处理删除。

Db2 连接器事件旨在与 Kafka 日志压缩配合使用。日志压缩允许删除一些旧消息，只要保留每个键的最新消息。这使 Kafka 能够回收存储空间，同时确保主题包含完整的数据集并可用于重新加载基于键的状态。

当一行被删除时，delete 事件值仍然可以与日志压缩配合使用，因为 Kafka 可以删除具有相同键的所有先前消息。但是，为了让 Kafka 删除所有具有相同键的消息，消息值必须为 null。为了实现这一点，在 Debezium 的 Db2 连接器发出delete 事件后，连接器会发出一个特殊的墓碑事件，该事件具有相同的键但值为 null。

下表描述了连接器如何将每个 Db2 数据类型映射到事件字段中的*文字类型*和*语义类型*。

如果存在，列的默认值将传播到相应字段的 Kafka Connect 模式。更改事件包含字段的默认值，除非已给出显式列值。因此，很少需要从模式中获取默认值。传递默认值有助于在使用 Avro 作为序列化格式并与 Confluent 模式注册表一起使用时，满足兼容性规则。

除 DATETIMEOFFSET 数据类型（包含时区信息）外，Db2 根据 time.precision.mode 连接器配置属性的值映射时间类型。以下各节将描述这些映射：

当 time.precision.mode 配置属性设置为 adaptive（默认值）时，连接器会根据列的数据类型定义来确定文字类型和语义类型。这可确保事件*精确*地表示数据库中的值。

当 time.precision.mode 配置属性设置为 connect 时，连接器会使用 Kafka Connect 逻辑类型。当消费者只能处理内置的 Kafka Connect 逻辑类型而无法处理可变精度时间值时，这可能很有用。但是，由于 Db2 支持十分之一微秒的精度，当数据库列的*小数秒精度*值大于 3 时，具有 connect 时间精度的连接器生成的事件将*导致精度损失*。

DATETIME 类型表示不带时区信息的时间戳。这些列根据 UTC 转换为等效的 Kafka Connect 值。例如，DATETIME 值 "2018-06-20 15:13:16.945104" 由 «时间戳» io.debezium.time.Timestamp 表示，其值为 "1529507596000"。

运行 Kafka Connect 和 Debezium 的 JVM 的时区不影响此转换。

为了将表置于捕获模式，Debezium 提供了一组用户定义函数 (UDF) 以方便使用。此处的过程显示了如何安装和运行这些管理 UDF。或者，您可以使用 Db2 控制命令将表置于捕获模式。然后，管理员必须为 Debezium 要捕获的每个表启用 CDC。

Debezium Db2 管理 UDF 参考表

当数据库管理员为源表启用更改数据捕获时，捕获代理开始运行。代理从事务日志中读取新的更改事件记录，并将事件记录复制到捕获表中。在更改提交到源表的时间与更改出现在相应捕获表的时间之间，总会有一个很小的延迟间隔。此延迟间隔代表源表中发生的更改与 Debezium 可以将其流式传输到 Apache Kafka 之间的时间间隔。

理想情况下，对于必须快速响应数据更改的应用程序，您希望在源表和捕获表之间保持紧密的同步。您可能会认为，让捕获代理尽可能快地连续处理更改事件可能有助于提高吞吐量并降低延迟—在事件发生后尽快将新事件记录填充到捕获表中，近乎实时。然而，这不一定如此。为了追求更即时的同步，需要付出性能代价。每次更改代理查询数据库以获取新事件记录时，都会增加数据库主机的 CPU 负载。服务器上的额外负载可能对整体数据库性能产生负面影响，并可能降低事务效率，尤其是在数据库使用高峰期。

重要的是要监视数据库指标，以便您了解数据库是否达到了服务器无法再支持捕获代理活动水平的点。如果您在运行捕获代理时遇到性能问题，请调整捕获代理设置以降低 CPU 负载。

在 Db2 中，IBMSNAP_CAPPARMS 表包含控制捕获代理行为的参数。您可以调整这些参数的值，以平衡捕获过程的配置，从而降低 CPU 负载，同时仍保持可接受的延迟水平。

在 IBMSNAP_CAPPARMS 表中，以下参数对降低 CPU 负载影响最大：

以下是一个连接器实例的配置示例，该实例捕获端口 50000 上 192.168.99.100 的 Db2 服务器的数据，该服务器被逻辑命名为 fullfillment。通常，您会在 JSON 文件中配置 Debezium Db2 连接器，方法是设置连接器可用的配置属性。

您可以选择为数据库中的模式和表的子集生成事件。可选地，您可以忽略、掩盖或截断包含敏感数据、大于指定大小或您不需要的列。

有关您可以为 Debezium Db2 连接器设置的配置属性的完整列表，请参阅 Db2 连接器属性。

您可以使用 POST 命令将此配置发送到正在运行的 Kafka Connect 服务。该服务会记录配置并启动一个连接器任务，该任务执行以下操作：

要开始运行 Db2 连接器，请创建连接器配置，并将该配置添加到您的 Kafka Connect 集群。

连接器启动后，它将执行一致快照，以捕获连接器配置为捕获更改的 Db2 数据库表的 «一致快照»。然后，连接器开始为行级别操作生成数据更改事件，并将更改事件记录流式传输到 Kafka 主题。

Debezium Db2 连接器拥有许多配置属性，您可以使用它们来实现适合您应用程序的正确连接器行为。许多属性都有默认值。有关属性的信息组织如下：

Debezium 连接器通过连接器的 MBean 名称公开指标。这些指标特定于每个连接器实例，提供有关连接器快照、流式传输和模式历史记录进程行为的数据。

默认情况下，当您部署正确配置的连接器时，Debezium 会为不同的连接器指标生成唯一的 MBean 名称。要查看连接器进程的指标，请将您的可观察性堆栈配置为监视其 MBean。但这些默认 MBean 名称取决于连接器配置；配置更改可能导致 MBean 名称发生更改。在这种情况下，更改 MBean 名称会破坏连接器实例和 MBean 之间的链接，从而中断监控活动。您必须重新配置可观察性堆栈以使用新的 MBean 名称才能恢复监控。

为了防止因 MBean 名称更改而导致的监控中断，您可以配置自定义指标标签。通过将 custom.metric.tags 属性添加到连接器配置中来配置自定义指标。该属性接受键值对，其中每个键代表 MBean 对象名称的标签，相应的值代表该标签的值。例如：k1=v1,k2=v2。Debezium 将指定的标签附加到连接器的 MBean 名称。

配置连接器的 custom.metric.tags 属性后，您可以配置可观察性堆栈以检索与指定标签关联的指标。然后，可观察性堆栈使用指定的标签而不是可变的 MBean 名称来唯一标识连接器。之后，如果 Debezium 重新定义了其如何构造 MBean 名称，或者连接器配置中的 topic.prefix 发生更改，指标收集将不会中断，因为指标抓取任务使用指定的标签模式来标识连接器。

使用自定义标签的另一个好处是，您可以使用反映数据管道架构的标签，以便以适合您运营需求的方式组织指标。例如，您可以指定带有值的标签来声明连接器活动的类型、应用程序上下文或数据源，例如 db1-streaming-for-application-abc。如果您指定多个键值对，所有指定的对都将附加到连接器的 MBean 名称。

以下示例说明了标签如何修改默认 MBean 名称。

MBean 是 debezium.db2:type=connector-metrics,context=snapshot,server=<topic.prefix>。

除非快照操作正在活动中，或者自上次连接器启动以来发生过快照，否则快照指标不会暴露。

下表列出了可用的快照指标。

当执行增量快照时，连接器还提供以下附加快照指标：

MBean 是 debezium.db2:type=connector-metrics,context=streaming,server=<topic.prefix>。

下表列出了可用的流式传输指标。

MBean 是 debezium.db2:type=connector-metrics,context=schema-history,server=<topic.prefix>。

下表列出了可用的模式历史记录指标。

在执行离线模式更新之前，您需要停止 Debezium Db2 连接器。虽然这是更安全的模式更新过程，但对于具有高可用性要求的应用程序可能不可行。

在线模式更新不需要应用程序和数据处理停机时间。也就是说，在执行在线模式更新之前，您不需要停止 Debezium Db2 连接器。此外，在线模式更新过程比离线模式更新过程更简单。

但是，当表处于捕获模式时，在更改列名后，Db2 复制功能将继续使用旧的列名。新的列名不会出现在 Debezium 更改事件中。您必须重新启动连接器才能在更改事件中看到新的列名。