Debezium 引擎

Debezium 连接器通常是通过将其部署到 Kafka Connect 服务中来运行的,然后配置一个或多个连接器来监控上游数据库,并为它们在这些上游数据库中看到的所有更改生成数据更改事件。这些数据更改事件被写入 Kafka,然后可以被许多不同的应用程序独立消费。Kafka Connect 提供了出色的容错性和可扩展性,因为它作为一个分布式服务运行,并确保所有已注册和配置的连接器始终在运行。例如,即使 Kafka Connect 集群中的一个端点发生故障,其余的 Kafka Connect 端点也会重新启动之前在已终止端点上运行的任何连接器,从而最大程度地减少停机时间并消除管理活动。

并非每个应用程序都需要这种级别的容错性和可靠性,并且它们可能不想依赖于外部的 Kafka Broker 和 Kafka Connect 服务集群。相反,一些应用程序更愿意将 Debezium 连接器 **嵌入** 到应用程序空间中。它们仍然需要相同的数据更改事件,但更希望连接器直接将它们发送给应用程序,而不是将它们持久化在 Kafka 中。

这个 debezium-api 模块定义了一个小型的 API,允许应用程序使用 Debezium Engine 轻松配置和运行 Debezium 连接器。

从 2.6.0 版本开始,Debezium 提供了 DebeziumEngine 接口的两个实现。较旧的 EmbeddedEngine 实现运行一个只使用一个任务的连接器。该连接器按顺序发出所有记录。

EmbeddedEngine 是 Debezium 3.1.0.Final 及更早版本的默认实现。从 Debezium 3.2.0.Alpha1 版本开始,默认实现是 AsyncEmbeddedEngine,并且 EmbeddedEngine 实现不再可用。

从 2.6.0 版本开始,提供了一个新的 AsyncEmbeddedEngine 实现。此实现也只运行一个连接器,但它可以多线程处理记录,并运行多个任务,如果连接器支持的话(目前只有 SQL Server 和 MongoDB 的连接器支持在单个连接器内运行多个任务)。由于这两个引擎都实现了相同的接口并共享相同的 API,因此接下来的代码示例对两个引擎都有效。两个实现都支持相同的配置选项。

然而,新的 AsyncEmbeddedEngine 提供了一些新的配置选项来设置和微调并行处理。有关这些新配置选项的信息,请参阅 异步 Engine 属性。要了解有关开发 AsyncEmbeddedEngine 的动机及其实现细节的更多信息,请参阅 异步嵌入式 Engine 设计文档

依赖项

要使用 Debezium Engine 模块,请将 debezium-api 模块添加到您的应用程序的依赖项中。debezium-embedded 模块中有一个现成的 API 实现,也应该添加到依赖项中。对于 Maven,这意味着将以下内容添加到您的应用程序的 POM 中

<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-api</artifactId>
    <version>${version.debezium}</version>
</dependency>
<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-embedded</artifactId>
    <version>${version.debezium}</version>
</dependency>

其中 ${version.debezium} 是您正在使用的 Debezium 版本,或者是一个值为 Debezium 版本字符串的 Maven 属性。

同样,为您的应用程序将使用的每个 Debezium 连接器添加依赖项。例如,可以在您的应用程序的 Maven POM 文件中添加以下内容,以便您的应用程序可以使用 MySQL 连接器

<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-connector-mysql</artifactId>
    <version>${version.debezium}</version>
</dependency>

或者对于 MongoDB 连接器

<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-connector-mongodb</artifactId>
    <version>${version.debezium}</version>
</dependency>

本文档的其余部分将描述在应用程序中嵌入 MySQL 连接器。其他连接器也以类似的方式使用,只是连接器特定的配置、主题和事件有所不同。

打包您的项目

Debezium 使用 SPI 和 ServiceLoader 来加载实现。实现可以基于连接器类型,也可以是自定义实现。

某些接口有多个实现。例如,io.debezium.snapshot.spi.SnapshotLock 在核心中有一个默认实现,以及每个连接器的特定实现。为确保 Debezium 能够找到所需的实现,您必须显式配置构建工具以合并 META-INF/services 文件。

例如,如果您使用的是 Maven shade 插件,请添加 ServicesResourceTransformer 转换器,如下例所示

...
<configuration>
 <transformers>
    ...
    <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
    ...
 </transformers>
...
</configuration>

或者,如果您使用 Maven Assembly 插件,您可以使用 metaInf-services 容器描述符处理器

在代码中

您的应用程序需要为要运行的每个连接器实例设置一个嵌入式引擎。io.debezium.engine.DebeziumEngine<R> 类作为任何 Debezium 连接器的易于使用的包装器,并完全管理连接器的生命周期。您可以使用其 builder API 创建 DebeziumEngine 实例,提供以下内容

  • 您希望接收消息的格式,例如 JSON、Avro 或 Kafka Connect 的 SourceRecord(请参阅 输出消息格式

  • 配置属性(可能从属性文件中加载),这些属性为引擎和连接器定义了环境

  • 一个将为连接器生成的每个数据更改事件调用的方法

下面是一个配置和运行嵌入式 MySQL 连接器 的代码示例

// Define the configuration for the Debezium Engine with MySQL connector...
final Properties props = new Properties();
props.setProperty("name", "engine");
props.setProperty("connector.class", "io.debezium.connector.mysql.MySqlConnector");
props.setProperty("offset.storage", "org.apache.kafka.connect.storage.FileOffsetBackingStore");
props.setProperty("offset.storage.file.filename", "/path/to/storage/offsets.dat");
props.setProperty("offset.flush.interval.ms", "60000");
/* begin connector properties */
props.setProperty("database.hostname", "localhost");
props.setProperty("database.port", "3306");
props.setProperty("database.user", "mysqluser");
props.setProperty("database.password", "mysqlpw");
props.setProperty("database.server.id", "85744");
props.setProperty("topic.prefix", "my-app-connector");
props.setProperty("schema.history.internal", "io.debezium.storage.file.history.FileSchemaHistory");
props.setProperty("schema.history.internal.file.filename", "/path/to/storage/schemahistory.dat");

// Create the engine with this configuration ...
try (DebeziumEngine<ChangeEvent<String, String>> engine = DebeziumEngine.create(Json.class)
        .using(props)
        .notifying(record -> {
            System.out.println(record);
        }).build()
    ) {
    // Run the engine asynchronously ...
    ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(engine);

    // Do something else or wait for a signal or an event
}
// Engine is stopped when the main code is finished

让我们更详细地看看这段代码,从重复的代码的开头几行开始

// Define the configuration for the Debezium Engine with MySQL connector...
final Properties props = new Properties();
props.setProperty("name", "engine");
props.setProperty("connector.class", "io.debezium.connector.mysql.MySqlConnector");
props.setProperty("offset.storage", "org.apache.kafka.connect.storage.FileOffsetBackingStore");
props.setProperty("offset.storage.file.filename", "/path/to/storage/offsets.dat");
props.setProperty("offset.flush.interval.ms", "60000");

这将创建一个新的标准 Properties 对象,用于设置引擎所需的几个字段,无论使用哪个连接器。第一个是引擎的名称,将在连接器生成的源记录及其内部状态中使用,因此请在您的应用程序中使用有意义的名称。connector.class 字段定义了扩展 Kafka Connect 的 org.apache.kafka.connect.source.SourceConnector 抽象类的类的名称;在此示例中,我们指定了 Debezium 的 MySqlConnector 类。

当 Kafka Connect 连接器运行时,它会从源读取信息,并定期记录“偏移量”,这些偏移量定义了它已处理的信息的多少。如果连接器重新启动,它将使用最后记录的偏移量来知道从源信息的哪个位置恢复读取。由于连接器不知道也不关心 **如何** 存储偏移量,因此引擎需要提供一种存储和恢复这些偏移量的方法。我们配置的接下来的几个字段指定了我们的引擎应该使用 FileOffsetBackingStore 类将偏移量存储在本地文件系统上的 /path/to/storage/offset.dat 文件中(文件名可以任意,文件可以存储在任何地方)。此外,尽管连接器在其生成的每个源记录中都记录了偏移量,但引擎会定期将偏移量刷新到后备存储(在本例中,每分钟一次)。这些字段可以根据您的应用程序需求进行定制。

接下来的几行定义了特定于连接器的字段(在每个连接器的文档中有详细说明),在我们的示例中是 MySqlConnector 连接器

    /* begin connector properties */
    props.setProperty("database.hostname", "localhost");
    props.setProperty("database.port", "3306");
    props.setProperty("database.user", "mysqluser");
    props.setProperty("database.password", "mysqlpw");
    props.setProperty("database.server.id", "85744");
    props.setProperty("topic.prefix", "my-app-connector");
    props.setProperty("schema.history.internal", "io.debezium.storage.file.history.FileSchemaHistory");
    props.setProperty("schema.history.internal.file.filename", "/path/to/storage/schemahistory.dat");

在这里,我们设置了运行 MySQL 数据库服务器的主机名和端口号,并定义了用于连接 MySQL 数据库的用户名和密码。请注意,对于 MySQL,用户名和密码应对应于已授予以下 MySQL 权限的 MySQL 数据库用户

  • SELECT

  • RELOAD

  • SHOW DATABASES

  • REPLICATION SLAVE

  • REPLICATION CLIENT

前三个权限是在读取数据库的稳定快照时必需的。最后两个权限允许数据库读取通常用于 MySQL 复制的服务器的 binlog。

配置还包括 server.id 的数字标识符。由于 MySQL 的 binlog 是 MySQL 复制机制的一部分,为了读取 binlog,MySqlConnector 实例必须加入 MySQL 服务器组,这意味着此服务器 ID 必须 在构成 MySQL 服务器组的所有进程中是唯一的,并且是介于 1 和 232-1 之间的任何整数。在我们的代码中,我们将其设置为一个相当大但略微随机的值,我们只将其用于我们的应用程序。

配置还为 MySQL 服务器指定了一个逻辑名称。连接器会将此逻辑名称包含在它生成的每个源记录的主题字段中,从而使您的应用程序能够区分这些记录的来源。我们的示例使用服务器名称“products”,大概是因为数据库包含产品信息。当然,您可以将其命名为对您的应用程序有意义的任何名称。

MySqlConnector 类运行时,它会读取 MySQL 服务器的 binlog,其中包括服务器托管的数据库的所有数据更改和 Schema 更改。由于所有数据更改都以更改记录时所属表的 Schema 来构建,因此连接器需要跟踪所有 Schema 更改,以便能够正确解码更改事件。连接器会记录 Schema 信息,以便在连接器重新启动并从最后记录的偏移量恢复读取时,它确切地知道数据库 Schema 在该偏移量时的样子。连接器如何记录数据库 Schema 历史是在我们配置的最后两个字段中定义的,即我们的连接器应该使用 FileSchemaHistory 类将数据库 Schema 历史更改存储在本地文件系统上的 /path/to/storage/schemahistory.dat 文件中(同样,此文件可以命名为任意名称并存储在任何位置)。

最后,使用 build() 方法构建不可变的配置。(顺便说一句,而不是以编程方式构建,我们可以使用 Configuration.read(…​) 方法之一 **读取** 配置)。

现在我们有了配置,可以创建我们的引擎。这里再次是相关的代码行

// Create the engine with this configuration ...
try (DebeziumEngine<ChangeEvent<String, String>> engine = DebeziumEngine.create(Json.class)
        .using(props)
        .notifying(record -> {
            System.out.println(record);
        })
        .build()) {
}

所有更改事件都将传递给给定的处理程序方法,该方法必须匹配 java.util.function.Consumer<R> 函数式接口的签名,其中 <R> 必须与调用 create() 时指定的格式类型相匹配。请注意,您的应用程序的处理程序函数不应抛出任何异常;如果它抛出了异常,引擎将记录该方法抛出的任何异常,并继续处理下一个源记录,但您的应用程序将没有机会处理导致异常的特定源记录,这意味着您的应用程序可能与数据库不一致。

此时,我们已经有了一个已配置并准备好运行的 DebeziumEngine 对象,但它什么也没做。DebeziumEngine 被设计为由 ExecutorExecutorService 异步执行

// Run the engine asynchronously ...
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(engine);

// Do something else or wait for a signal or an event

您的应用程序可以通过调用其 close() 方法来安全而优雅地停止引擎

// At some later time ...
engine.close();

或者,由于引擎支持 Closeable 接口,当 try 块退出时,它将自动被调用。

引擎的连接器将停止从源系统读取信息,将所有剩余的更改事件转发给您的处理程序函数,并将最新的偏移量刷新到偏移量存储。只有在所有这些完成后,引擎的 run() 方法才会返回。如果您的应用程序需要等待引擎完全停止后再退出,您可以使用 ExcecutorServiceshutdownawaitTermination 方法来完成

try {
    executor.shutdown();
    while (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
        logger.info("Waiting another 5 seconds for the embedded engine to shut down");
    }
}
catch ( InterruptedException e ) {
    Thread.currentThread().interrupt();
}

或者,您可以在创建 DebeziumEngine 时注册 CompletionCallback 作为回调,以便在引擎终止时收到通知。

请记住,当 JVM 关闭时,它只等待非守护线程。因此,当您在守护线程上运行引擎时,如果您的应用程序退出,请确保等待引擎进程完成。

您的应用程序应始终正确停止引擎,以确保优雅且完整的关闭,并且每个源记录只发送给应用程序一次。例如,不要依赖于关闭 ExecutorService,因为这会中断正在运行的线程。尽管 DebeziumEngine 在其线程被中断时确实会终止,但引擎可能不会干净地终止,当您的应用程序重新启动时,可能会看到一些在关闭前刚刚处理过的相同源记录。

如前所述,DebeziumEngine 接口有两个实现。这两个实现使用相同的 API,前面的代码示例对两个版本都有效。唯一的例外是创建 DebeziumEngine 实例。如引言中所述,默认情况下使用 AsyncEmbeddedEngine 实现。因此,方法 DebeziumEngine.create(Json.class) 在内部会导致使用 AsyncEmbeddedEngine 实例。

输出消息格式

DebeziumEngine#create() 可以接受多个不同的参数,这些参数会影响消费者接收消息的格式。允许的值为

  • Connect.class - 输出值为包装 Kafka Connect 的 SourceRecord 的更改事件

  • Json.class - 输出值为一对作为 JSON 字符串编码的键和值

  • JsonByteArray.class - 输出值为一对作为 JSON 格式化并编码为 UTF-8 字节数组的键和值

  • Avro.class - 输出值为一对作为 Avro 序列化记录编码的键和值(有关更多详细信息,请参阅 Avro 序列化

  • CloudEvents.class - 输出值为一对作为 Cloud Events 消息编码的键和值

在调用 DebeziumEngine#create() 时也可以指定头部格式。允许的值为

  • Json.class - 头部值编码为 JSON 字符串

  • JsonByteArray.class - 头部值格式化为 JSON 并编码为 UTF-8 字节数组

内部,引擎会将数据转换委托给最适合执行转换的 Kafka Connect 或 Apicurio 转换器实现。转换器可以使用引擎属性进行参数化以修改其行为。

JSON 输出格式的示例

final Properties props = new Properties();
...
props.setProperty("converter.schemas.enable", "false"); // don't include schema in message
...
final DebeziumEngine<ChangeEvent<String, String>> engine = DebeziumEngine.create(Json.class)
    .using(props)
    .notifying((records, committer) -> {

        for (ChangeEvent<String, String> r : records) {
            System.out.println("Key = '" + r.key() + "' value = '" + r.value() + "'");
            committer.markProcessed(r);
        }
...

其中 ChangeEvent 数据类型是键/值对。

消息转换

在消息传递给处理程序之前,可以对它们进行 Kafka Connect 单条消息转换 (SMT) 的管道处理。每个 SMT 可以不改变消息,修改它,或者过滤掉它。链式处理通过属性 transforms 进行配置。该属性包含要应用的转换的逻辑名称的逗号分隔列表。属性 transforms.<logical_name>.type 然后定义每个转换的实现类名称,transforms.<logical_name>.* 是传递给转换的配置选项。

配置示例

final Properties props = new Properties();
...
props.setProperty("transforms", "filter, router");                                               // (1)
props.setProperty("transforms.router.type", "org.apache.kafka.connect.transforms.RegexRouter");  // (2)
props.setProperty("transforms.router.regex", "(.*)");                                            // (3)
props.setProperty("transforms.router.replacement", "trf$1");                                     // (3)
props.setProperty("transforms.filter.type", "io.debezium.embedded.ExampleFilterTransform");      // (4)
  1. 定义了两个转换 - filterrouter

  2. router 转换的实现是 org.apache.kafka.connect.transforms.RegexRouter

  3. router 转换有两个配置选项 -regexreplacement

  4. filter 转换的实现是 io.debezium.embedded.ExampleFilterTransform

消息转换谓词

可以对转换应用谓词,使转换成为可选的。

配置示例

final Properties props = new Properties();
...
props.setProperty("transforms", "filter");                                                 // (1)
props.setProperty("predicates", "headerExists");                                           // (2)
props.setProperty("predicates.headerExists.type", "org.apache.kafka.connect.transforms.predicates.HasHeaderKey"); //(3)
props.setProperty("predicates.headerExists.name", "header.name");                          // (4)
props.setProperty("transforms.filter.type", "io.debezium.embedded.ExampleFilterTransform");// (5)
props.setProperty("transforms.filter.predicate", "headerExists");                          // (6)
props.setProperty("transforms.filter.negate", "true");                                     // (7)
  1. 定义了一个转换 - filter

  2. 定义了一个谓词 - headerExists

  3. headerExists 谓词的实现是 org.apache.kafka.connect.transforms.predicates.HasHeaderKey

  4. headerExists 谓词有一个配置选项 - name

  5. filter 转换的实现是 io.debezium.embedded.ExampleFilterTransform

  6. filter 转换需要谓词 headerExists

  7. filter 转换期望谓词的值被否定,从而使谓词确定头部是否存在

高级记录消费

对于某些用例,例如尝试批量写入记录或写入异步 API,上面描述的函数式接口可能会很困难。在这些情况下,使用 io.debezium.engine.DebeziumEngine.ChangeConsumer<R>. 接口可能会更容易。

此接口有一个签名如下的函数

/**
  * Handles a batch of records, calling the {@link RecordCommitter#markProcessed(Object)}
  * for each record and {@link RecordCommitter#markBatchFinished()} when this batch is finished.
  * @param records the records to be processed
  * @param committer the committer that indicates to the system that we are finished
  */
 void handleBatch(List<R> records, RecordCommitter<R> committer) throws InterruptedException;

如 Javadoc 中所述,RecordCommitter 对象应为每个记录调用,并在每个批次完成后调用一次。RecordCommitter 接口是线程安全的,允许灵活地处理记录。

您可以选择覆盖已处理记录的偏移量。这是通过首先调用 RecordCommitter#buildOffsets() 来构建一个新的 Offsets 对象,使用 Offsets#set(String key, Object value) 更新偏移量,然后调用 RecordCommitter#markProcessed(SourceRecord record, Offsets sourceOffsets)(带有更新的 Offsets)来完成的。

要使用 ChangeConsumer API,您必须将该接口的实现传递给 notifying API,如下所示

class MyChangeConsumer implements DebeziumEngine.ChangeConsumer<RecordChangeEvent<SourceRecord>> {
  public void handleBatch(List<RecordChangeEvent<SourceRecord>> records, RecordCommitter<RecordChangeEvent<SourceRecord>> committer) throws InterruptedException {
    ...
  }
}
// Create the engine with this configuration ...
DebeziumEngine<RecordChangeEvent<SourceRecord>> engine = DebeziumEngine.create(ChangeEventFormat.of(Connect.class))
        .using(props)
        .notifying(new MyChangeConsumer())
        .build();

如果使用 JSON 格式(对于其他格式,等效代码也适用),则代码如下

class JsonChangeConsumer implements DebeziumEngine.ChangeConsumer<ChangeEvent<String, String>> {
  public void handleBatch(List<ChangeEvent<String, String>> records,
    RecordCommitter<ChangeEvent<String, String>> committer) throws InterruptedException {
    ...
  }
}
// Create the engine with this configuration ...
DebeziumEngine<ChangeEvent<String, String>> engine = DebeziumEngine.create(Json.class)
        .using(props)
        .notifying(new JsonChangeConsumer())
        .build();

Engine 属性

以下配置属性是 **必需** 的,除非有默认值可用(为了文本格式化,Java 类的包名被替换为 <…​>)。

属性

Default (默认值)

描述

name (名称)

连接器实例的唯一名称。

connector.class

连接器 Java 类的名称,例如 MySQL 连接器的 <…​>.MySqlConnector

offset.storage

<…​>.FileOffsetBackingStore

负责持久化连接器偏移量的 Java 类的名称。它必须实现 <…​>.OffsetBackingStore 接口。

offset.storage.file.filename

""

存储偏移量的文件路径。当 offset.storage 设置为 <…​>.FileOffsetBackingStore 时需要。

offset.storage.topic

""

存储偏移量的 Kafka 主题的名称。当 offset.storage 设置为 <…​>.KafkaOffsetBackingStore 时需要。

offset.storage.partitions

""

创建偏移量存储主题时使用的分区数。当 offset.storage 设置为 <…​>.KafkaOffsetBackingStore 时需要。

offset.storage.replication.factor

""

创建偏移量存储主题时使用的副本数。当 offset.storage 设置为 <…​>.KafkaOffsetBackingStore 时需要。

offset.commit.policy

<…​>.PeriodicCommitOffsetPolicy

提交策略的 Java 类的名称。它定义了基于处理的事件数和自上次提交以来的时间间隔来触发偏移量提交。此类必须实现接口 <…​>.OffsetCommitPolicy。默认是基于时间间隔的定期提交策略。

offset.flush.interval.ms

60000

尝试提交偏移量的间隔。默认值为 1 分钟。

offset.flush.timeout.ms

5000

在取消进程并将偏移量数据恢复到下次尝试提交之前,等待记录刷新并将分区偏移量数据提交到偏移量存储的最长毫秒数。默认值为 5 秒。

errors.max.retries

-1

在连接错误之前重试连接错误的最大次数(-1 = 无限制,0 = 禁用,> 0 = 重试次数)。

errors.retry.delay.initial.ms

300

遇到连接错误时重试的初始延迟(以毫秒为单位)。此值将在每次重试时加倍,但不会超过 errors.retry.delay.max.ms

errors.retry.delay.max.ms

10000

遇到连接错误时重试之间的最大延迟(以毫秒为单位)。

异步 Engine 属性

属性

Default (默认值)

描述

record.processing.threads

按需分配线程,基于工作负载和可用 CPU 核心数。

可用于处理更改事件记录的线程数。如果未指定值(默认值),则引擎使用 Java 的 ThreadPoolExecutor 根据当前工作负载动态调整线程数。最大线程数是给定机器上的 CPU 核心数。如果指定了值,则引擎使用 Java 的 固定线程池 方法创建一个具有指定线程数的线程池。要使用给定机器上的所有可用核心,请将占位符值设置为 AVAILABLE_CORES

record.processing.shutdown.timeout.ms

1000

在调用任务关闭后,等待已提交记录处理的最长毫秒数。

record.processing.order

ORDERED

确定记录的生成方式。

ORDERED

记录按顺序处理;也就是说,它们按照从数据库获取的顺序生成。

UNORDERED

记录按非顺序处理;也就是说,它们可能以与源数据库不同的顺序生成。

UNORDERED 选项的非顺序处理可提高吞吐量,因为记录在任何 SMT 处理和消息序列化完成后会立即生成,而无需等待其他记录。当向引擎提供了 ChangeConsumer 方法时,此选项无效。

record.processing.with.serial.consumer

false

指定是否应从提供的 Consumer 创建默认的 ChangeConsumer,从而实现串行 Consumer 处理。如果您在使用 API 创建引擎时指定了 ChangeConsumer 接口,则此选项无效。

task.management.timeout.ms

180,000 (3 分钟)

引擎等待任务的生命周期管理操作(启动和停止)完成的毫秒数。

数据库 Schema 历史属性

一些连接器还需要一组额外的属性来配置数据库 Schema 历史。

  • MySQL

  • SQL Server

  • Oracle

  • Db2

如果没有正确配置数据库 Schema 历史,连接器将拒绝启动。默认配置期望 Kafka 集群可用。对于其他部署,提供了基于文件的数据库 Schema 历史存储实现。

属性 Default (默认值) 描述

schema.history.internal

<…​>.KafkaSchemaHistory

负责持久化数据库 Schema 历史的 Java 类的名称。
它必须实现 <…​>.SchemaHistory 接口。

schema.history.internal.file.filename

""

存储数据库 Schema 历史的文件路径。
schema.history.internal 设置为 <…​>.FileSchemaHistory 时需要。

schema.history.internal.kafka.topic

""

存储数据库 Schema 历史的 Kafka 主题。
schema.history.internal 设置为 <…​>.KafkaSchemaHistory 时需要。

schema.history.internal.kafka.bootstrap.servers

""

要连接的 Kafka 集群服务器的初始列表。该集群提供用于存储数据库 Schema 历史的主题。
schema.history.internal 设置为 <…​>.KafkaSchemaHistory 时需要。

处理故障

当引擎执行时,它的连接器会在每个源记录中积极记录源偏移量,并且引擎会定期将这些偏移量刷新到持久存储中。当应用程序和引擎正常关闭或崩溃时,当它们重新启动时,引擎及其连接器将 **从最后记录的偏移量** 处恢复读取源信息。

那么,当您的应用程序在嵌入式引擎运行时发生故障时会发生什么?其净效应是,应用程序在重启后可能会收到一些在崩溃前已经处理过的源记录。数量取决于引擎将偏移量刷新到其存储的频率(通过 offset.flush.interval.ms 属性)以及特定连接器在一次批次中返回多少源记录。最佳情况是偏移量每次都刷新(例如,offset.flush.interval.ms 设置为 0),但即使那样,嵌入式引擎也只会在从连接器接收到一批源记录后刷新偏移量。

例如,MySQL 连接器使用 max.batch.size 来指定批次中可以出现的源记录的最大数量。即使 offset.flush.interval.ms 设置为 0,当应用程序在崩溃后重启时,它可能会看到最多 **n** 个重复项,其中 **n** 是批次的大小。如果 offset.flush.interval.ms 属性设置得更高,那么应用程序可能会看到最多 n * m 个重复项,其中 **n** 是批次的最大大小,**m** 是在单个偏移量刷新间隔内可能累积的批次数。(显然,可以配置嵌入式连接器以不使用批处理并且始终刷新偏移量,从而导致应用程序永远不会收到任何重复的源记录。但是,这会大大增加连接器的开销并降低其吞吐量。)

底线是,在使用嵌入式连接器时,应用程序在正常操作期间(包括正常关闭后的重启)会收到每个源记录一次,但需要容忍在崩溃或不正确关闭后的重启后立即收到重复事件。如果应用程序需要更严格的恰好一次行为,那么它们应该使用完整的 Debezium 平台,该平台可以提供恰好一次保证(即使在崩溃和重启之后)。