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

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

例如，考虑一个包含 PRODUCTS、PRODUCTS_ON_HAND、CUSTOMERS 和 ORDERS 四个表的 mydatabase 数据库，它们位于 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 主题。

当事务元数据启用时，连接器会使用新的 transaction 字段来丰富变更事件 Envelope。此字段以字段组合的形式提供关于每个事件的信息：

以下是消息示例

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

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

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

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

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

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

customers 表的每次变更事件的值部分指定了相同的模式。事件值的载荷根据事件类型而变化：

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

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

delete 变更事件中的值具有与同一表的create 和update 事件相同的 schema 部分。delete 事件中 customers 表的示例的事件值载荷如下所示：

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

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 上、IP 地址为 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 更改事件中。您必须重新启动连接器才能在更改事件中看到新列名。