debezium常见问题官网翻译版

原文链接 https://debezium.io/documentation/faq/
欢迎关注留言，我是收集整理小能手，笔芯笔芯.

什么是Debezium？

Debezium 是一组分布式服务，可捕获数据库中的行级更改，以便您的应用程序可以查看并响应这些更
改。Debezium 在事务日志中记录提交给每个数据库表的所有行级更改。每个应用程序只需读取它们感兴
趣的事务日志，并且它们按照事件发生的顺序查看所有事件。

“Debezium”这个名字从何而来？

该名称是“ DBs ”（多个数据库的缩写）和“ -ium ”后缀的组合，后缀用于元素周期表的许多元素的名称。快
说：“ DBs-ium ”。如果有帮助，我们会说“ dee-BEE-zee-uhm ”。

什么是变更数据捕获？

更改数据捕获（CDC）是一个较旧的术语，指的是监视和捕获数据更改的系统，以便其他软件可以响应这
些更改。数据仓库通常具有内置的 CDC 支持，因为数据仓库需要随着上游 OLTP 数据库中的数据更改而
保持最新状态。
Debezium 本质上是一个现代的分布式开源变更数据捕获平台，最终将支持监控各种数据库系统。

Debezium 可以监控哪些数据库？

Debezium 的最新版本包括支持监控MySQL 数据库服务器
(/documentation/reference/stable/connectors/mysql)、MongoDB 副本集或分片集群
(/documentation/reference/stable/connectors/mongodb)、PostgreSQL 服务器
(/documentation/reference/stable/connectors/postgresql)、Oracle 服务器
(/documentation/reference/stable/connectors/oracle)（基于 LogMiner 和 XStream）、Db2 服务器
(/documentation/reference/stable/connectors/db2)、Cassandra 数据库
(/documentation/reference/stable/connectors/cassandra)（3.x 和 4.x）和SQL Server数据库
(/documentation/reference/stable/connectors/sqlserver)。此外，还有用于Vitess 服务器
(/documentation/reference/stable/connectors/vitess)和Google Spanner
(/documentation/reference/stable/connectors/spanner)的正在进行中的 Debezium 连接器，它们从
Debezium 2.2 开始作为预览（孵化）版本发布。
请注意，监视 PostgreSQL 需要在 PostgreSQL 服务器中安装扩展（“逻辑解码插件”）。Debezium 与
Decoderbufs (https://github.com/debezium/postgres-decoderbufs/)（由 Debezium 社区维护）和 pgoutput
（由 Postgres 社区维护）配合使用。
如果您的数据库托管在（托管）云服务上，则必须安装这些插件之一（或者您必须能够自行安装）。否
则，您将无法使用 Debezium 监控数据库。pgoutput 是 Postgres 10 及更高版本的一部分；是否可以启用
取决于特定数据库的配置。
在CloudSQL (https://cloud.google.com/sql)上，pgoutput 是受支持的扩展，可以安装，如配置
PostgreSQL 扩展 (https://cloud.google.com/sql/docs/postgres/extensions)中所述。
在Amazon RDS (https://aws.amazon.com/rds/)以及Azure Database for PostgreSQL
(https://docs.microsoft.com/en-us/azure/postgresql/)上，可以使用 pgoutput。两者都可以与 Debezium 一
起使用。
未来版本中将添加对其他 DBMS 的支持。请参阅我们的路线图 (/roadmap/)。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 3/12

Debezium 有哪些用途？

Debezium 的主要用途是使应用程序能够在数据库中的数据发生变化时几乎立即响应。应用程序可以对插
入、更新和删除事件执行任何操作。他们可能会使用这些事件来了解何时从缓存中删除条目。他们可能会
用数据更新搜索索引。他们可能会使用相同的信息或根据变化的数据计算出的信息来更新派生数据存储，
例如使用命令查询职责分离 (CQRS) (https://en.wikipedia.org/wiki/Command-query_separation)。他们可
能会向一台或多台移动设备发送推送通知。他们可能会聚合更改并为实体生成补丁流。它们可能被存储以
形成审核日志。他们可能会使用 Apache Flink 或 Kafka Streams 来驱动流查询。它们可用于在微服务之间
传播数据，例如采用发件箱模式 (/documentation/reference/configuration/outbox-event-router.html)。
您可以在 QCon San Francisco 2019 的演示文稿 (https://speakerdeck.com/gunnarmorling/practicalchange-data-streaming-use-cases-with-apache-kafka-and-debezium-qcon-san-francisco-2019)中了解有
关 CDC 用例的更多信息。

为什么 Debezium 是一个分布式系统？

Debezium 的架构旨在容忍错误和故障，而实现这一点的唯一有效方法是使用分布式系统。Debezium 将监
控进程或连接器分布在多台机器上，这样，如果出现任何问题，连接器可以重新启动。这些事件被记录并
在多台机器上复制，以最大限度地减少信息丢失的风险。
我的应用程序可以直接监控单个数据库吗？
是的。尽管我们建议大多数人使用完整的 Debezium 平台，但单个应用程序可以嵌入
(/docs/embedded/)Debezium 连接器，以便它可以监视数据库并响应事件。这种方法确实要简单得多，移
动部件很少，但它的局限性更大，对故障的容忍度也更差。如果您的应用程序需要所有消息的至少一次传
递保证，请考虑使用完整的分布式系统。

Debezium 平台是什么样的？

正在运行的 Debezium 系统由几个部分组成。Apache Kafka (http://kafka.apache.org)代理集群提供持久、
复制和分区的事务日志，Debezium 记录所有事件，应用程序从中使用所有事件。Kafka 代理的数量很大
程度上取决于事件量、正在监控的数据库表的数量以及正在使用事件的应用程序的数量。Kafka 确实依赖
一小群Zookeeper (http://zookeeper.apache.org)节点来管理每个代理的职责。
每个 Debezium 连接器监控一个数据库集群/服务器，并且连接器被配置并部署到 Kafka Connect 服务集
群，以确保每个连接器始终运行，即使 Kafka Connect 服务实例离开并加入集群也是如此。每个 Kafka
Connect 服务集群（也称为组）都是独立的，因此组织内的每个组都可以管理自己的集群。
所有连接器都将其事件（和其他信息）记录到 Apache Kafka，Apache Kafka 会在单独的主题中保留、复
制和分区每个表的事件。多个 Kafka Connect 服务集群可以共享一个 Kafka Broker 集群，但 Kafka Broker
的数量很大程度上取决于事件量、监控的数据库表数量以及消费事件的应用程序数量。
应用程序直接连接到 Kafka 并使用适当主题内的事件。

可以监控多少个数据库？

Debezium 可以监控任意数量的数据库。可以部署到单个 Kafka Connect 服务集群的连接器数量取决于事
件的数量和速率。但是，Debezium 支持多个 Kafka Connect 服务集群，如果需要，还支持多个 Kafka 集
群。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 4/12

Debezium 如何影响源数据库？

大多数数据库必须先进行配置，然后 Debezium 才能监控它们。例如，MySQL服务器必须配置为使用行级
binlog，并具有读取binlog的权限的用户；Debezium 连接器必须配置正确的信息，包括特权用户。有关详
细信息，请参阅特定连接器文档。
Debezium 连接器不会在上游数据库内存储任何信息。但是，运行连接器可能会给源数据库带来额外的负
载。

数据库的事件是如何组织的？

大多数连接器会将单个数据库表的所有事件记录到单个主题。此外，主题内的所有事件都是完全有序的，
这意味着所有这些事件的顺序将保持不变。（即使在失败期间事件重复，应用所有事件后的最终结果也将
保持不变。）
例如，监控 MySQL 服务器/集群（逻辑上名为“dbserverA”）的 MySQL 连接器记录了主题名为的
“Customers”数据库中“Addresses”表的所有更改 dbserverA.Customers.Addresses 。同样，同一数据库中
“PaymentMethods”表的所有更改都将记录在名为的主题中 dbserverA.customers.PaymentMethods 。

活动为何规模如此之大？

Debezium 旨在监视上游数据库，并为每个行级更改生成一个或多个完整描述这些更改的相应事件。但
Debezium 连接器持续工作，即使上游数据库中的表结构随时间变化，其事件也必须有意义。如果消费者
一次只需处理一个事件，而不是跟踪事件流的整个历史记录的状态，那么它的编写也会容易得多。
这意味着每个事件都需要完全自描述：事件的键和值各自包含带有实际信息的有效负载和完全描述信息结
构的模式。消费应用程序可以处理每个事件，使用架构来理解该事件中信息的结构，然后正确处理事件的
有效负载。消费应用程序可以利用以下事实：架构对于连续的许多事件将保持不变，并且仅当架构更改
时，消费应用程序可能需要做更多的工作来准备更改的结构。
同时，Kafka Connect 服务序列化连接器的事件并将其记录在 Kafka 中。JSON转换器非常通用，也非常
简单，但它别无选择，只能序列化整个事件信息。因此，用 JSON 表示的事件确实冗长且庞大。
但是，还有另一种选择：使用架构注册表。这样，实际的模式信息由注册表管理，而实际的更改事件仅包
含注册表中相应模式的 id。这样可以更有效地表示发送到 Kafka 的事件。模式注册表可以使用不同的格
式，例如 JSON 或 Avro。利用 Avro 作为消息格式还有一个额外的优点，即有效负载被序列化为非常紧凑
的二进制形式 (https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffersthrift.html)。
使用这种方法，Kafka Connect 转换器和模式注册表一起工作来跟踪每个模式随时间的历史记录。同时，
在消费者中，相同的转换器解码事件的紧凑二进制形式，读取该消息使用的模式版本的标识符，如果它还
没有看到该模式版本，则从模式注册表下载模式，最后使用该架构来解码事件的有效负载。同样，许多按
顺序的事件将共享相同的模式（和模式版本），因此大多数时候转换器可以简单地将原始紧凑事件解码为
消费者期望的相同模式和有效负载。

如何使用架构注册表？

模式注册表选项包括Apicurio API 和模式注册表 (https://github.com/Apicurio/apicurio-registry)以及
Confluence 模式注册表 (http://docs.confluent.io/{confluent-platform-version}/schemaregistry/docs/index.html)。两者都带有转换器，用于在注册表中存储/获取 JSON 和 Avro 模式。
如果您要将 Debezium 连接器部署到 Kafka Connect 工作线程服务，只需确保注册表中的转换器 JAR 可
用，并将工作线程服务配置为使用正确的转换器即可。例如，您需要将转换器指向您的 Apicurio 架构注册
表。然后，只需将 Debezium 连接器（或者实际上是任何其他 Kafka Connect 连接器）部署到您的工作服
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 5/12
务即可。有关如何将 Avro 转换器与 Apicurio 和 Confluence 注册表结合使用的详细说明，请参阅Avro 序
列化。 (/docs/configuration/avro/)
GitHub 上的教程示例 (https://github.com/debezium/debezium-examples/tree/main/tutorial#using-mysqland-the-avro-message-format)详细展示了如何将模式注册表和随附的转换器与 Debezium 结合使用。
我们的 Kafka Connect Docker 镜像包含 Avro 转换器作为一个选项。

当应用程序停止或崩溃时会发生什么？

为了使用数据库的更改事件，应用程序创建一个 Kafka 使用者，它将连接到 Kafka 代理并使用与该数据库
关联的主题的所有事件。消费者被配置为定期记录其在每个主题中的位置（也称为偏移量）。当应用程序
正常停止并关闭消费者时，消费者将记录每个主题中最后一个事件的偏移量。当应用程序在以后任何时间
重新启动时，使用者都会查找这些偏移量并开始读取每个主题中的下一个事件。因此，在正常操作场景
下，应用程序只会看到每个事件一次。
如果应用程序意外崩溃，则在重新启动时，应用程序的使用者将查找每个主题的最后记录的偏移量，并从
每个主题的最后一个偏移量开始消费事件。在大多数情况下，应用程序将看到一些与崩溃之前（但在记录
偏移之后）看到的相同事件，然后是尚未看到的事件。因此，应用程序至少会看到每个事件一次。应用程
序可以通过更频繁地记录偏移量来减少多次看到的事件数量，尽管这样做会对客户端的性能和吞吐量产生
负面影响。
请注意，Kafka 消费者可以配置为连接并开始读取每个主题中的最新偏移量。这可能会导致错过事件，尽
管这对于某些用例来说是完全可以接受的。

当 Debezium 停止或崩溃时会发生什么？

Debezium 的行为因停止或崩溃的组件而异。如果足够多的 Kafka 代理停止或崩溃，使得每个主题分区所
容纳的同步副本数量少于最小数量，则写入这些主题的连接器以及从这些主题读取的消费应用程序将简单
地阻塞，直到可以重新启动 Kafka 代理或让新代理上线。因此，同步副本的最小数量对可用性有非常大的
影响，并且出于一致性原因应始终至少为 1（如果不是 3）。
Kafka Connect 服务配置为定期记录每个连接器的位置和偏移量。如果集群中的一个 Kafka Connect 服务
实例正常停止，则该进程中运行的所有连接器都将正常停止（意味着所有位置和偏移量都将被记录），并
且这些相同的连接器将在集群中的其他 Kafka Connect 服务实例上重新启动。同一个簇。当这些连接器重
新启动时，它们将继续准确地从中断处记录事件，不会记录重复的事件。
当 Kafka Connect 服务集群中运行的连接器之一正常停止时，它将完成当前工作并记录 Kafka 中的最新位
置和偏移量。从主题消费的下游应用程序将简单地等待，直到添加新事件。
如果集群中的任何 Kafka Connect 服务实例意外崩溃，则在崩溃进程中运行的所有连接器都将在同一集群
中的其他 Kafka Connect 服务实例上重新启动。但是，当这些连接器重新启动时，它们将开始记录数据库
中的事件，从连接器崩溃之前最后记录的位置/偏移量开始。这意味着新重新启动的连接器可能会记录一些
先前在崩溃之前记录的相同事件，并且这些重复事件对于下游消费应用程序始终是可见的。

当受监控的数据库停止或崩溃时会发生什么？

当 Debezium 监控的数据库服务器停止或崩溃时，Debezium 连接器可能会尝试重新建立通信。Debezium
定期记录连接器在 Kafka 中的位置和偏移量，因此一旦连接器建立通信，连接器应该继续从最后记录的位
置和偏移量读取。

为什么消费应用程序必须期待重复事件？

当所有系统都正常运行或部分或全部系统正常关闭时，使用应用程序可以期望一次准确地看到每个事件。
然而，当出现问题时，消费应用程序总是有可能至少看到一次事件。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 6/12
当 Debezium 的系统崩溃时，它们并不总是能够记录其最后的位置/偏移量。当它们重新启动时，它们通过
从上次已知的位置开始进行恢复，因此消费应用程序将始终看到每个事件，但可能会在恢复期间至少看到
一些重复的消息。
此外，网络故障可能会导致 Debezium 连接器无法接收写入确认，从而导致同一事件被记录一次或多次
（直到收到确认）。

是什么导致 EventDataDeserializationExceptionMySQL 连接器出现间歇性的问题？

当您在启动连接器后大约 1 分钟遇到间歇性反序列化异常时，根本原因为 EOFException 或
java.net.SocketException: Connection reset ：
Caused by: com.github.shyiko.mysql.binlog.event.deserialization.EventDataDeserialization
Exception: Failed to deserialize data of EventHeaderV4{timestamp=1542193955000, eventTyp
e=GTID, serverId=91111, headerLength=19, dataLength=46, nextPosition=1058898202, flags=
0}
Caused by: java.lang.RuntimeException: com.github.shyiko.mysql.binlog.event.deserializat
ion.EventDataDeserializationException: Failed to deserialize data of EventHeaderV4{times
tamp=1542193955000, eventType=GTID, serverId=91111, headerLength=19, dataLength=46, next
Position=1058898202, flags=0}
Caused by: java.io.EOFException
or
Caused by: java.net.SocketException: Connection reset
然后像这样更新这些 MySQL 服务器全局属性将修复它：
set global slave_net_timeout = 120; (default was 30sec)
set global thread_pool_idle_timeout = 120;

卡夫卡是什么？

Apache Kafka (http://kafka.apache.org)是一种快速、可扩展、持久的分布式消息传递系统，它将所有消息
记录在复制、分区和全序事务日志中。消费者在日志中跟踪他们的位置，并且可以独立于所有其他消费者
来控制该位置。这意味着一些消费者可以从日志的最开头开始，而其他消费者则可以跟上最近记录的消
息。Kafka 作为一个动态的代理集群运行。每个日志分区都会复制到多个代理，因此，如果任何代理发生
故障，集群仍然拥有该分区的多个副本。
Debezium 连接器将所有事件记录到 Kafka 集群，应用程序通过 Kafka 消费这些事件。

什么是卡夫卡连接？

Kafka Connect 是一个在 Apache Kafka 和其他系统之间可扩展且可靠地传输数据的框架。它是 Kafka 社
区的最新成员，它使得定义将大量数据移入和移出 Kafka 的连接器变得简单，而该框架则完成了正确记录
连接器偏移量的大部分艰苦工作。Kafka Connect 服务具有用于管理和部署连接器的 RESTful API；该服
务可以集群化，并会自动在集群中分配连接器，确保连接器始终运行。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 7/12
Debezium 使用 Kafka Connect 框架。Debezium 的所有连接器都是 Kafka Connector源连接器，因此可以
使用 Kafka Connect 服务来部署和管理它们。

使用 Debezium Docker 镜像时如何连接到 Kafka？

使用 Docker for Mac 或 Docker for Windows 时，Docker 容器在轻量级虚拟机中运行。为了从主机系统连
接到 Kafka，例如在 IDE 中的测试中启动 Kafka Consumer，您需要为 ADVERTISED_HOST_NAME Kafka 容器
指定主机系统的 IP 地址或主机名： docker run -it --rm --name kafka -p 9092:9092 -e
ADVERTISED_HOST_NAME=<%YOUR_HOST_NAME%> --link zookeeper:zookeeper debezium/kafka:{debeziumdocker-label} 。该名称将由 Zookeeper 发布给询问 Kafka 代理名称的客户。

Connect 映像的默认内存设置可以处理多大的数据库大小？

启动和运行时的内存消耗取决于 Debezium 监控的数据库中表的总数、每个表中的列数以及来自数据库的
事件量。根据经验，默认内存设置（最大堆设置为 256 MB）将能够处理所有表的列总数小于 10000 的数
据库。

如何从二进制表示中检索 DECIMAL 字段？

如果 Debezium 配置为精确处理 DECIMAL 值，则它将其编码为
org.apache.kafka.connect.data.Decimal . 该类型被转换为 a BigInteger 并序列化为字节数组。为了将
其解码回来，我们需要提前知道价值的规模，或者必须从模式中获得。然后，用于解包的代码可能类似于
以下片段之一，具体取决于编码值是否可用作字节数组或字符串。
byte[] encoded = …;
int scale = …;
final BigDecimal decoded = new BigDecimal(new BigInteger(encoded), scale);
String encoded = …;
int scale = …;
final BigDecimal decoded = new BigDecimal(new BigInteger(Base64.getDecoder().decode(enco
ded)), scale);

如何修改源数据库的偏移量？

 这是操纵 Kafka Connect 内部结构的技术性很强的操作。请仅将此作为最后的解决方
案。
有时，数据库日志包含需要跳过的无效数据（例如无效日期），或者有必要重新处理过去的部分日志。通
常没有直接的方法（除了 event.deserialization.failure.handling.mode MySQL 连接器）如何实现此操
作，但有一种解决方法可以操纵 Kafka Connect 的内部数据。
第一步是找出包含插件偏移量的主题名称。这是在 offset.storage.topic 选项中配置的。
下一步是找出给定连接器的最后一个偏移量、存储该连接器的键并识别用于存储偏移量的分区。一个例子
是：
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 8/12
$ kafkacat -b localhost -C -t my_connect_offsets -f ‘Partition(%p) %k %s\n’
Partition(11) [“inventory-connector”,{“server”:“dbserver1”}] {“ts_sec”:1530088501,“fil
e”:“mysql-bin.000003”,“pos”:817,“row”:1,“server_id”:223344,“event”:2}
Partition(11) [“inventory-connector”,{“server”:“dbserver1”}] {“ts_sec”:1530168941,“fil
e”:“mysql-bin.000004”,“pos”:3261,“row”:1,“server_id”:223344,“event”:2}
关键 inventory-connector 是 [“inventory-connector”,{“server”:“dbserver1”}] ，分区号是 11 ，最后
一个偏移量是 {“ts_sec”:1530168941,“file”:“mysqlbin.000004”,“pos”:3261,“row”:1,“server_id”:223344,“event”:2} 。
要移回先前的偏移量，应停止连接器并发出以下命令：
$ echo ‘[“inventory-connector”,{“server”:“dbserver1”}]|{“ts_sec”:1530168950,“file”:“mysq
l-bin.000003”,“pos”:817,“row”:1,“server_id”:223344,“event”:2}’ |
kafkacat -P -b localhost -t my_connect_offsets -K | -p 11

如何删除连接器的已提交偏移？

 这是操纵 Kafka Connect 内部结构的技术性很强的操作。请仅将此作为最后的解决方
案。
有时在进行实验时（或者当连接器在开始时配置错误时），有必要删除连接器偏移以从干净的状态开始。
第一步是找出包含插件偏移量的主题名称。这是在 offset.storage.topic 选项中配置的。
下一步是找出给定连接器的最后一个偏移量、存储它的键并识别用于存储偏移量的分区。一个例子是：
$ kafkacat -b localhost -C -t my_connect_offsets -f ‘Partition(%p) %k %s\n’
Partition(11) [“inventory-connector”,{“server”:“dbserver1”}] {“ts_sec”:1530088501,“fil
e”:“mysql-bin.000003”,“pos”:817,“row”:1,“server_id”:223344,“event”:2}
Partition(11) [“inventory-connector”,{“server”:“dbserver1”}] {“ts_sec”:1530168941,“fil
e”:“mysql-bin.000004”,“pos”:3261,“row”:1,“server_id”:223344,“event”:2}
关键 inventory-connector 是 [“inventory-connector”,{“server”:“dbserver1”}] ，分区号是 11 ，最后
一个偏移量是 {“ts_sec”:1530168941,“file”:“mysqlbin.000004”,“pos”:3261,“row”:1,“server_id”:223344,“event”:2} 。
要删除连接器偏移，应停止连接器并发出以下命令：
$ echo ‘[“inventory-connector”,{“server”:“dbserver1”}]|’ |
kafkacat -P -Z -b localhost -t my_connect_offsets -K | -p 11
此命令 NULL 为给定键写入一条消息，该消息在逻辑上被转换为删除给定连接器存储的偏移量。

为什么无法使用 KSQL 打印逻辑删除事件？

使用 KSQL 流查询引擎时，不支持逻辑删除事件（在删除捕获表中的记录时默认由 Debezium 连接器创
建）：
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 9/12
PRINT ‘dbserver.inventory.orders’ FROM BEGINNING;
com.fasterxml.jackson.databind.node.NullNode cannot be cast to com.fasterxml.jackson.dat
abind.node.ObjectNode
考虑使用状态提取后 SMT (/docs/configuration/event-flattening/)及其删除逻辑删除选项来删除逻辑删除事
件。

为什么 Debezium MySQL 连接器使用架构更改工具会崩溃？

当 MySQL 连接器监视应用了Gh-ost或pt-online-schema-change等架构更改工具的表时，MySQL 连接
器可能会崩溃，并从值转换器抛出异常。这些工具在迁移过程中创建辅助表，并且这些辅助表需要包含在
白名单表中。
如何减少每个租户数据库模式中的内存消耗？
如果您的多租户基于单租户数据库，则 Debezium 连接器将必须多次存储列和表的元数据。您可以使用
JVM -XX:+UseStringDeduplication 标志来减少内存消耗。 KAFKA_OPTS 所有 JVM 参数都可以使用环境变
量传递。Dockerfile 中的一个示例是：
ENV KAFKA_OPTS=“-XX:+UseStringDeduplication”

如何解决偏移刷新超时问题？

当日志包含这样的错误时， Failed to flush, timed out while waiting for producer to flush
outstanding 218630 messages 这意味着 Kafka Connect 无法足够快地将偏移量记录到偏移主题中。
问题可能有多种解决方案和根本原因
Kafka 选项 acks 设置为 all，其中一个副本代理处理写入的速度很慢
连接记录生成得非常快，Kafka Connect 选项 offset.flush.interval.ms 应该
offset.flush.timeout.ms 进行调整。应缩短间隔并增加超时时间。
Debezium 正在生成非常大批量的记录，减少参数 max.batch.size 并 max.queue.size

为什么在某些情况下我看不到 DELETE 事件？

这可能是由于使用 CASCADE DELETE 语句造成的。在这种情况下，数据库生成的删除事件不是 binlog 的一
部分 (https://dev.mysql.com/doc/refman/5.7/en/innodb-and-mysql-replication.html)，因此无法被
Debezium 捕获。

为什么 Debezium MySQL 连接器无法使用 RDS MySQL 只读副本中的数据？

Debezium MySQL 需要启用服务器 binlog。对于 RDS MySQL，该属性由 AWS 直接管理，并且默认
log_bin 设置为。 OFF Debezium MySQL 在快照期间执行 SHOW MASTER STATUS 命令时，结果集为空并抛
出异常：
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 10/12
Caused by: java.lang.IllegalStateException: Cannot read the binlog filename and position
via ‘SHOW MASTER STATUS’. Make sure your server is correctly configured
at io.debezium.connector.mysql.SnapshotReader.lambda$readBinlogPosition$16(SnapshotR
eader.java:761)
at io.debezium.jdbc.JdbcConnection.query(JdbcConnection.java:444)
at io.debezium.jdbc.JdbcConnection.query(JdbcConnection.java:385)
at io.debezium.connector.mysql.SnapshotReader.readBinlogPosition(SnapshotReader.jav
a:745)
at io.debezium.connector.mysql.SnapshotReader.execute(SnapshotReader.java:370)
解决方案是间接启用该 log_bin 属性，激活 RDS MySQL 中的某些产品功能：只读副本和/或自动备份。激
活其中任何一个后， bin_log 属性值将更改为 ON 自动，并且连接器将能够成功完成快照。

为什么 Debezium PostgreSQL 连接器会导致 WAL 数据库磁盘空间异常消耗？

请参阅PostgreSQL 连接器文档中的WAL 磁盘空间消耗。
(/documentation/reference/1.0/connectors/postgresql.html#wal-disk-space)

为什么交换表中两列的内容时没有创建新的架构版本？

如果表中的两列以这种方式交换，即更改后表架构与之前相同，则不会在架构注册表中创建新版本的架
构。此类操作的一个示例可以是：
原始表 - id , , c1 , c2 其中 c1 和 c2 属于同一类型
列交换 - id , c2 , c1
列重命名 - id , c1 , c2
仅当架构发生逻辑更改时，架构注册表才会创建新版本的架构，但在这种情况下，对于外部观察者来说，
更改后的架构是相同的。

如何扩大传递到Kafka的消息的最大大小？

对于大型事务，Kafka Connect 发出的消息可能大于预设的最大值。日志通常包含类似于以下内容的异
常：
org.apache.kafka.common.errors.RecordTooLargeException: The message is 1740572 bytes whe
n serialized which is larger than 1048576, which is the value of the max.request.size co
nfiguration.
要解决此问题， producer.max.request.size 必须在 Kafka Connect 工作配置文件中设置配置选项
connect-distributed.properties 。如果不需要全局更改，则连接器可以使用设置
producer.override.max.request.size 为较大值的配置选项来覆盖默认设置。
在后一种情况下，还需要 connector.client.config.override.policy=ALL 在 Kafka Connect 工作配置文
件中配置选项 connect-distributed.properties 。对于 Debezium connect Docker 镜像，环境变量
CONNECT_CONNECTOR_CLIENT_CONFIG_OVERRIDE_POLICY 可用于配置选项。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 11/12

为什么 JSON 消息不包含架构？

如果您用于 JsonConverter 转换和序列化 Debezium 发出的消息，则默认情况下该模式不包含在消息中。
使用 schemas.enable 转换器配置参数启用模式，在工作线程级别设置（例如 connectdistibuted.properties ）：
key.converter.schemas.enable=true
value.converter.schemas.enable=true
或在连接器级别，具体取决于转换器的配置位置。

如何启用不区分大小写的名称过滤？

诸如定义一组正则表达式之类的几个配置选项 table.include.list 在应用于标识符时不区分大小写。
如果您的环境需要区分大小写的匹配（例如，两个标识符仅在字母大小写方面不同），那么您可以使用给
定表达式的正则表达式标志 (?-i) 来强制区分大小写的匹配。

为什么TIMESTAMP快照和流式传输之间 MySQL 列的更改事件值不同？

如果 Debezium（或者更确切地说 MySQL JDBC 驱动程序）由于某种原因无法检索数据库的时区，则可能
会出现这种情况。在这种情况下， TIMESTAMP 值可能无法标准化为 UTC。 database.connectionTimeZone
在这种情况下，必须使用直通连接器选项显式指定数据库时区（ database.serverTimezone 必须用于早于
1.7 的 Debezium 版本）。

MongoDB 连接器因最大 BSON 大小错误而失败

当 Debezium（或者更确切地说，MongoDB 更改流游标）遇到总大小超过BSON 文档大小限制 16 MB 的
(https://www.mongodb.com/docs/manual/reference/limits/#mongodb-limit-BSON-Document-Size)更改事
件文档时，可能会出现这种情况。请注意，根据所使用的情况，即使存储 capture.mode 文档的实际价值明
显较低，此问题仍然可能出现。
从 Debezium 版本 2.3.4 开始，您可以使用 cursor.pipeline 和 cursor.pipeline.order 属性来规避此错
误
首先将设为 cursor.pipeline.order ， user_first 然后设置 cursor.pipeline 添加以下聚合阶段。
[{ “ $KaTeX parse error: Expected '}', got 'EOF' at end of input: match": { "$ and”: [{“ $KaTeX parse error: Expected '}', got 'EOF' at end of input: expr": { "$ lte”: [{“ $b so n S i ze " : "$ fullDocument”}, 8000]}},
{“ $KaTeX parse error: Expected '}', got 'EOF' at end of input: expr": { "$ lte”: [{“ $b so n S i ze " : "$ fullDocumentBeforeChange”}, 8000]}}]} }]
在上面的示例中，原始或更新大小超过 8000 字节的文档的所有事件都将被安全地过滤掉。

与Bootstrap (https://getbootstrap.com/)混合，由Jekyll (https://jekyllrb.com/)烘焙。
网站和文档已获得CC BY 3.0 (http://creativecommons.org/licenses/by/3.0/)许可。
2023/12/13 15:47 经常问的问题
https://debezium.io/documentation/faq/ 12/12
原文
(https://www.redhat.com/)
提供更好的翻译建议
根据Apache 许可证 v2.0 (https://www.apache.org/licenses/LICENSE-2.0.html)发布的代码。
 条款 (https://www.redhat.com/legal/legal_statement.html)| 隐私
(https://www.redhat.com/legal/privacy_statement.html)
版本：9634bc9
(https://github.com/debezium/debezium.github.io/commit/9634bc987b41dbd7a3e7a78687f68fbb8ebd0fe6)
文档
特征 (/documentation/reference/stable/features.html)
安装 (/documentation/reference/stable/install.html)
建筑学 (/documentation/reference/stable/architecture.html)
常问问题 (/documentation/faq/)
贡献 (/community/contribute/)
连接
博客 (/blog)
推特 (https://twitter.com/debezium)
GitHub (https://github.com/debezium)
聊天 (https://debezium.zulipchat.com/#narrow/stream/302529-users)
谷歌网上论坛 (https://groups.google.com/forum/#!forum/debezium)
堆栈溢出 (https://stackoverflow.com/questions/tagged/debezium)