今天，我非常高兴地宣布 Debezium 2.0.0.Final 已发布！
自 2019 年 12 月我们发布 1.0 版本以来，社区一直在努力构建一个全面的开源低延迟变更数据捕获 (CDC) 平台。在过去的三年里，我们扩展了 Debezium 的产品组合，包括稳定的 Oracle 连接器、社区驱动的 Vitess 连接器、增量快照的引入、多分区支持等等。在活跃的贡献者和提交者社区的帮助下，Debezium 已成为 CDC 领域的事实上领导者，并在众多行业的众多组织中投入生产，使用数百个连接器从数千个数据库平台流式传输数据更改。
2.0 版本标志着 Debezium 的一个新里程碑，这是我们很自豪能与大家分享的。
在本文中，我们将深入探讨 Debezium 2.0 中的所有更改，讨论新功能并解释在升级过程中可能产生影响的所有潜在的破坏性更改。一如既往，我们强烈建议您查阅 发行说明，以详细了解所有已修复的错误、更新过程等内容，特别是从旧版本升级时。
Debezium 核心更改
Debezium 的核心在 Debezium 2.0 中发生了相当大的变化。在本节中，我们将深入探讨 Debezium 核心的更改，并讨论这些更改如何影响所有 Debezium 用户。
需要 Java 11
我们希望升级到 Java 11 已经有一段时间了，并且我们认为 Debezium 2.0 是合适的时机。借助 Java 11，我们可以利用新的语言特性，例如代码库中的新 String API 和 Predicate 支持更改，同时还能受益于 Java 的许多性能改进。
我们自己的 Vojtech Juranek 发表了 这篇博文，他在其中详细讨论了切换到 Java 11。使用 Debezium 需要 Java 11 运行时，因此在升级之前，请确保 Java 11 可用。
改进的增量快照
停止
自首次引入增量快照以来，用户一直要求一种停止正在进行的快照的方法。为此，我们添加了一个名为 stop-snapshot 的新信号，允许停止正在进行的增量快照。此信号的发送方式与其他信号相同，即向信号表/集合中插入一行，如下所示：
INSERT INTO schema.signal_table (id, type,data)
VALUES ('unique-id', 'stop-snapshot', '_<signal payload>_`);stop-snapshot 的 payload 与其 execute-snapshot 的 counterpart 非常相似。示例：
{
"data-collections": ["schema1.table1", "schema2.table2"],
"type": "incremental"
}此示例移除了 schema1.table1 和 schema2.table2，只要该表或集合尚未完成其增量快照。如果在移除 data-collections 指定的表或集合后仍有其他表或集合未处理，增量快照将继续处理未处理的表或集合。如果没有其他表或集合未处理，增量快照将停止。
stop-snapshot payload 的另一个示例也非常简单：
{
"type": "incremental"
}此示例未指定 data-collections 属性，对于 stop-snapshot 信号，它是可选的。当未指定此属性时，该信号暗示应完全停止当前正在进行的增量快照。这使得无需了解当前或尚未捕获的表或集合，即可停止增量快照。
暂停和恢复
增量快照已成为 Debezium 的一项重要功能。增量快照功能允许用户出于各种原因重新运行一个或多个集合/表的快照。增量快照最初仅通过一个 *start* 信号引入。我们最终增加了 *停止* 正在进行的增量快照或从正在进行的增量快照中移除部分集合/表的功能。
在此版本中，我们基于现有的信号基础进行了扩展，并引入了两个新信号：一个用于 *暂停* 正在进行的增量快照，另一个用于 *恢复* 之前已暂停的增量快照。要暂停增量快照，必须发送 pause-snapshot 信号，要恢复，可以使用 resume-snapshot 信号。
这两个新信号可以使用信号表策略或 MySQL 的 Kafka 信号主题策略发送。有关信号及其工作原理的更多详细信息，请参阅 信号支持文档。
使用正则表达式
增量快照信号要求在 data-collections payload 属性中使用显式表/集合名称。虽然这效果很好，但在某些情况下，广泛的捕获配置可以利用正则表达式。我们已经在连接器配置选项（例如包含/排除列表）中支持正则表达式，因此将其扩展到增量快照也是合乎逻辑的。
从 Debezium 2.0 开始，所有增量快照信号都可以在 data-collections payload 属性中使用正则表达式。使用上面的停止信号示例之一，payload 可以使用正则表达式重写：
{
"data-collections": ["schema[1|2].table[1|2]"],
"type": "incremental"
}就像显式用法一样，此带正则表达式的信号也将停止 schema1.table1 和 schema2.table2。
应用 SQL 条件过滤器
虽然不常见，但在某些情况下，例如连接器配置错误，可能需要将特定记录或记录子集重新发射到主题。不幸的是，增量快照传统上是一种全有或全无的过程，我们会将集合或表中的所有记录作为快照的一部分重新发射。
在此版本中，可以在信号 payload 中指定新的 additional-condition 属性，允许信号规定一个基于 SQL 的谓词，以控制哪些记录子集应包含在增量快照中，而不是默认的 *所有行* 行为。
以下示例说明了发送 products 表的增量快照信号，但不是发送表中的所有行，而是指定了 additional-condition 属性来将快照限制为仅发送与产品 ID 等于 12 相关的事件：
{
"type": "execute-snapshot",
"data": {
"data-collections": ["inventory.products"],
"type": "INCREMENTAL",
"additional-condition": "product_id=12"
}
}我们相信这项新的增量快照功能将在各种场景下提供极大的帮助，而无需在只需要一部分数据时重新快照所有行。
信号数据库集合自动添加到包含过滤器
在以前的 Debezium 版本中，用于增量快照的信号集合/表必须手动添加到 table.include.list 连接器属性中。此版本的一个主要主题是改进增量快照，因此我们也借此机会进行了简化。从本版本开始，Debezium 将自动将信号集合/表添加到表包含过滤器中，从而无需用户手动添加。
此更改不会引起任何兼容性问题。在 table.include.list 属性中已包含信号集合/表的连接器配置将继续工作，无需任何更改。但是，如果您希望使配置与当前行为保持一致，也可以安全地从 table.include.list 中删除信号集合/表，Debezium 将开始自动为您处理。
事务元数据更改
事务元数据事件描述数据库事务的 *开始* 和 *结束*（提交）。这些事件对于审计等各种原因都很有用。默认情况下，连接器不生成事务元数据事件，要启用此功能，必须启用 provide.transaction.metadata 选项。
在 Debezium 2.0 中，BEGIN 和 END 事件都包含一个新字段 ts_ms，该字段是事务开始或提交（取决于事件类型）的数据库时间戳。现在，此类事件的示例如下：
{
"status": "END",
"id": "12345",
"event_count": 2,
"ts_ms": "1657033173441",
"data_collections": [
{
"data_collection": "s1.a",
"event_count": 1
},
{
"data_collection": "s2.a",
"event_count": 1
}
]
}如果您已在使用事务元数据功能，升级后新事件将包含此字段。
如果您不使用事务元数据功能，但觉得它很有用，只需将 provide.transaction.metadata 选项设置为 *true* 添加到您的连接器配置中。默认情况下，元数据事件会发射到以您的 topic.prefix 选项命名的主题。这可以通过指定 transaction.topic 选项来覆盖，如下所示：
topic.prefix=server1
provide.transaction.metadata=true
transaction.topic=my-transaction-events在此示例中，所有事务元数据事件都将发射到 my-transaction-events。有关更多详细信息，请参阅特定连接器的配置。
多分区模式现在是默认设置
许多数据库平台都支持开箱即用的多租户，这意味着您可以拥有一个数据库引擎安装并拥有多个独立数据库。在 SQL Server 等情况下，这传统上需要为每个独立数据库部署单独的连接器。在过去一年中，已付出了巨大的努力来打破这一障碍，并引入一种通用方法，任何单个连接器部署都可以连接并从多个数据库流式传输更改。
第一个值得注意的变化是 SQL Server 连接器的配置选项 database.dbname。此选项已被一个名为 database.names 的新选项替换。由于多分区模式现在是默认设置，因此可以使用逗号分隔的数据库名称列表来指定此新 database.names 选项，如下所示：
database.names=TEST1,TEST2在此示例中，连接器被配置为捕获同一主机安装上的两个独立数据库的更改。连接器将在 Kafka Connect 中启动两个独立的任务，每个任务负责并发流式传输各自数据库的更改。
第二个值得注意的变化是连接器指标命名。连接器通过由唯一名称标识的 bean 公开 JMX 指标。对于多分区模式，作为多个任务的默认设置，每个任务都需要自己的指标 bean，因此有必要更改命名策略。
在旧版本的 Debezium 中，以 SQL Server 为例，可以使用以下命名策略访问指标：
debezium.sql_server:type=connector-metrics,server=<sqlserver.server.name>,context=<context>在此版本中，命名策略现在包含 JMX MBean 名称中的新 task 组件：
debezium.sql_server:type=connector-metrics,server=<sqlserver.server.name>,task=<task.id>,context=<context>请查看您的指标配置，因为命名更改可能会影响收集 Debezium 指标。
新的存储模块
在此版本中，我们引入了一套新的 debezium-storage 伪指令，用于基于文件和 Kafka 的数据库历史记录和偏移量存储。此更改是支持 Amazon S3、Redis 和可能还有 JDBC 等平台的未来实现的几个实现的第一个。
对于通过插件伪指令安装连接器的用户来说，这应该是一个无缝的更改，因为所有依赖项都打包在这些插件可下载的存档中。对于可能在应用程序中嵌入 Debezium 或可能正在构建自己的连接器的用户，请注意，您可能需要添加新的存储依赖项，具体取决于使用的存储实现。
可插拔主题选择器
Debezium 的默认主题命名策略将更改事件发射到名为 database.schema.table 的主题。如果您需要为主题命名不同，通常会向连接器配置添加一个 SMT 来调整此行为。但这在主题名称的组件之一（可能是数据库或表名称）包含点 (.) 而 SMT 可能没有足够上下文的情况下会带来挑战。
在此版本中，引入了一个新的 TopicNamingStrategy，允许直接在 Debezium 内部完全自定义此行为。默认命名策略实现应足以满足大多数情况，但如果您发现它不足，您可以提供 TopicNamingStrategy 合同的自定义实现来完全控制连接器使用的各种命名。要提供您自己的自定义策略，您可以使用 topic.naming.strategy 连接器选项指定策略的完全限定类名，如下所示：
topic.naming.strategy=org.myorganization.MyCustomTopicNamingStrategy此自定义策略不仅限于控制表映射的主题名称，还包括模式更改、事务元数据和心跳。您可以参考 此处 找到的 DefaultTopicNamingStrategy 作为示例。此功能仍处于孵化阶段，我们将根据收到的反馈继续改进和开发它。
改进的唯一索引处理
表不必具有主键即可被 Debezium 连接器捕获。在未定义主键的情况下，Debezium 将检查表的唯一索引，以确定是否可以进行合理的键替换。在某些情况下，索引可能引用 PostgreSQL 的 CTID 或 Oracle 的 ROWID 等列。这些列不可见，也不是用户定义的，而是数据库自动生成的隐藏合成列。此外，索引还可能使用数据库函数来转换存储的列值，例如 UPPER 或 LOWER。
在此版本中，依赖于隐藏的、自动生成的列或包装在数据库函数中的列的索引不再符合主键替代的资格。这确保了当依赖索引作为主键而不是主键本身时，生成的消息的主键值元组直接映射到数据库用于表示唯一性的相同值。
新的配置命名空间
Debezium 2.0 中最大的重构之一是引入了新的连接器属性命名空间。从 Debezium 2.0 Beta2 及更高版本开始，许多连接器属性已被重新定位并赋予新名称。这是一个破坏性更改，在升级过程中会影响大多数（如果不是全部）连接器部署。
Debezium 以前使用 "database." 前缀以及大量各种连接器属性。其中一些属性旨在直接传递给 JDBC 驱动程序，另一些则用于数据库历史记录实现等。不幸的是，我们发现有些属性被传递给的底层实现并非预期的。虽然这不会造成任何回归或问题，但如果存在属性名称冲突，例如 JDBC 驱动程序属性与带 "database." 前缀的 Debezium 连接器属性匹配，则可能导致未来出现问题。
以下描述了连接器属性的更改：
-
所有先前以
database.history.为前缀的配置现在都将以schema.history.internal.为前缀。 -
所有先前使用
database.前缀指定的 JDBC 直通选项现在都应使用driver.作为前缀。 -
database.server.name连接器属性已重命名为topic.prefix。 -
MongoDB 的
mongodb.name连接器属性已调整为使用topic.prefix。
再次，请在部署前查看您的连接器配置并进行相应调整。
所有模式都已命名和版本化
Debezium 更改事件以模式定义的形式发射，该定义包含有关字段的元数据，例如类型、是否必需等。在以前的 Debezium 版本中，一些模式定义没有显式名称，也没有被显式版本化。在此版本中，我们已转向确保所有模式定义都具有关联的显式名称和版本。此更改的目的是帮助实现未来的事件结构兼容性，特别是对于那些使用模式注册表的用户。但是，如果您当前正在使用模式注册表，请注意此更改可能导致升级过程中的模式兼容性问题。
默认跳过截断事件
Debezium 支持通过在连接器配置中包含 skipped.operations 连接器属性来跳过特定的事件类型。如果您只对一部分操作感兴趣，例如只关心插入和更新而不关心删除，那么此功能非常有用。
一种特定的事件类型，截断 (t)，仅被一部分关系型连接器支持，并且是否跳过这些事件并不一致。在此版本中，我们已调整 skipped.operations 的行为，以便如果连接器支持截断事件，这些事件将默认被跳过。
请参考以下规则集：
-
连接器支持截断事件，并且不是 Oracle 连接器
-
连接器配置未在配置中指定
skipped.operations
如果以上所有条件都为真，则升级后连接器的行为将发生变化。如果您希望继续发射截断事件，则需要配置 skipped.operations=none。
schema.name.adjustment 行为的更改
schema.name.adjustment.mode 配置属性控制模式名称应如何调整以兼容连接器使用的消息转换器。此配置选项可以有两个值之一：
avro-
将不能在 Avro 类型名称中使用的字符替换为下划线。
none-
即使检测到非 Avro 兼容字符，也不调整名称。
在以前的版本中，Debezium 始终默认使用安全值 avro；然而，从 Debezium 2.0.0.CR1 开始，默认值将变为 none。我们认为，考虑到 Avro 序列化的使用是用户根据自身需求选择的，此选项应与相同的选择性行为保持一致。
安全的升级路径是调整您的配置并显式使用 schema.name.adjustment.mode 为 avro，并为新连接器部署使用默认值。但您也可以审查您的主题名称和配置，检查是否没有发生下划线替换，因此此更改将不会产生任何影响。
Cassandra 连接器更改
Cassandra 4 增量提交日志支持
Cassandra 4 通过添加一项功能改进了与 CDC 的集成，当 fsync 操作发生时，Cassandra 会更新一个基于 CDC 的索引文件，其中包含最新的偏移量值。此索引文件允许 CDC 实现读取被视为在 Cassandra 中持久化的偏移量。
在此版本中，Debezium 现在使用此基于 CDC 的索引文件来消除以前存在的从 Cassandra 处理 CDC 事件的固有延迟。这应该为 Cassandra 用户提供 Debezium 处理 CDC 的显着改进，并鼓励用户考虑使用 Cassandra 4 而不是 Cassandra 3。
MongoDB 连接器更改
移除 oplog 实现
在 Debezium 1.8 中，我们引入了新的 MongoDB 更改流功能，同时弃用了 oplog 实现。迁移到更改流提供了各种好处，例如能够从非主节点流式传输更改，能够发出具有完整文档表示形式的更新事件供下游消费者使用，以及更多。总之，更改流是使用 MongoDB 进行更改数据捕获的一种更优越的方式。
移除 oplog 实现也意味着不再支持 MongoDB 3.x。如果您使用 MongoDB 3.x，您需要至少升级到 MongoDB 4.0 或更高版本才能使用 Debezium 2.0。
更改前状态支持（MongoDB 6.0）
MongoDB 6 支持捕获应用更改之前文档的状态。这长期以来一直是仅适用于关系型连接器的功能，但现在使 Debezium 也能将 before 字段作为 MongoDB 事件 payload 的一部分。
要启用此新的 MongoDB 6+ 行为，capture.mode 设置已调整为包含两个新值：
change_streams_with_pre_image-
更改事件还将包含更改发生 *之前* 的完整文档以及作为更改事件一部分的已更改字段的最终状态。
change_streams_update_full_with_pre_image-
当发生更新时，不仅会存在表示当前更新后状态的完整文档，事件还将包含更改 *之前* 的完整文档。
| MongoDB |
MySQL 连接器更改
已移除旧版 MySQL 实现
正如有些人可能知道也可能不知道，我们在 Debezium 1.5（2021 年 2 月）中基于通用连接器框架实现了 MySQL 连接器。作为重写的一部分，我们引入了 MySQL 用户通过将配置选项 internal.implementation 设置为 legacy 来启用旧版连接器行为的能力。此旧版实现已弃用，取而代之的是新的通用连接器框架行为。在 Debezium 2.0 中，此 internal.implementation 配置选项和旧版连接器实现已被移除。
如果您的当前连接器部署依赖于此旧版实现，您应该知道，通过升级到 Debezium 2.0，连接器将不再使用旧版实现，而仅使用通用连接器实现。功能方面，两种实现功能上是相当的，但有一点例外：旧版实现对更改过滤器配置具有实验性支持。如果您依赖于此旧版行为，请注意该功能不再可用。
Binlog 压缩支持
在此版本中，Debezium 现在支持读取已启用压缩写入的 binlog 条目。在 8.0.20 版本中，MySQL 增加了使用 ZSTD 算法压缩 binlog 事件的能力。要启用压缩，您必须在 MySQL 服务器上将 binlog.transaction_compression 变量切换到 ON。启用压缩后，binlog 的行为与往常一样，只是 binlog 条目的内容被压缩以节省空间，并以压缩格式复制到副本，从而显著减少大型事务的网络开销。
如果您有兴趣了解更多关于 MySQL binlog 压缩的信息，您可以参考 MySQL 文档的 二进制日志事务压缩 部分以获取更多详细信息。
Oracle 连接器更改
Oracle 源信息更改
source 信息块是更改事件 payload 中描述生成更改事件的数据库属性的部分。例如，此部分包括系统更改号、更改的数据库时间戳以及更改所属的事务。
在此版本中，我们发现了一个回归，其中 scn 字段未能正确反映更改事件发生的正确 source。虽然 Oracle 生成多个具有相同系统更改号的更改并不罕见，但我们确实发现了一个回归，导致错误的系统更改号被分配给作用域事务内的每个单独事件，这使得一些人难以使用此信息进行审计。现在，source.scn 字段应正确反映来自 Oracle LogMiner 或 Oracle Xstream 的系统更改号。
此外，在 source 信息块中添加了几个新字段，以改进与 LogMiner 实现和 Oracle RAC 的集成。新源信息块的示例：
{
"source": {
"version": "2.0.0.Alpha3",
"name": "server1",
"ts_ms": 1520085154000,
"txId": "6.28.807",
"scn": "2122184",
"commit_scn": "2122185",
"rs_id": "001234.00012345.0124",
"ssn": 0,
"redo_thread": 1
}
}新添加的字段是：
rs_id-
指定与更改关联的回滚段标识符。
ssn-
指定 SQL 序列号，此序列号与
rs_id结合构成更改的唯一元组。 redo_thread-
指定管理更改生命周期的实际数据库重做线程。
无论使用 Oracle Standalone 还是 RAC，当使用 Oracle LogMiner 时，这些值始终会提供。这些值在 Oracle RAC 安装中更为重要，因为您有多个数据库服务器并发地操作共享数据库。这些字段专门注释了更改源自哪个节点以及在该节点上的哪个位置。
Oracle 连接器偏移量更改
在 Oracle Real Application Clusters (RAC) 环境中，多个节点同时访问和操作 Oracle 数据库。每个节点维护自己的重做日志缓冲区并执行自己的重做写入器线程。这意味着在任何给定时刻，每个节点都有其独特的“位置”，并且这些位置将完全不同于每个相应节点上发生的活动。
在此版本中，DBZ-5245 中进行了一个小的更改以支持 Oracle RAC。以前，连接器偏移量维护一个名为 scn 的字段，该字段表示连接器应从中流式传输更改的“位置”。但由于每个节点在重做中的位置可能不同，单个 scn 值对于 Oracle RAC 来说是不够的。
旧版 Oracle 连接器偏移量如下所示：
{
"scn": "1234567890",
"commit_scn": "2345678901",
"lcr_position": null,
"txId": null
}从 Debezium 2.0 开始，新的偏移量结构现在具有此形式：
{
"scn": "1234567890:00124.234567890.1234:0:1,1234567891:42100.0987656432.4321:0:2",
"commit_scn": "2345678901",
"lcr_position": null,
"txId": null
}您会注意到 scn 字段现在由逗号分隔的值列表组成，其中每个条目代表一个值元组。此新元组的格式为 scn:rollback-segment-id:ssn:redo-thread。
此更改是向前兼容的，这意味着一旦您升级到 Debezium 2.0，旧版本的连接器将无法读取偏移量。如果您升级并决定回滚，请注意偏移量需要手动调整偏移量的 scn 字段，使其仅包含所有重做线程中最新 scn 值的字符串。
Oracle 提交用户在更改事件中
更改事件的源信息块承载了有关更改事件起源的各种上下文。在此版本中，Oracle 连接器现在将在捕获的更改事件中包含进行数据库更改的用户。source 信息块中现在可以找到一个新字段 user_name，其中包含此新信息。此字段是可选的，并且仅在使用基于 LogMiner 的实现发出更改时可用。如果与更改关联的用户在连接器捕获更改之前被删除，此字段也可能包含 UNKNOWN 值。
PostgreSQL 连接器更改
已移除对 wal2json 的支持
在 Debezium 的整个生命周期中，PostgreSQL 连接器支持多种解码器实现，包括 decoderbufs、wal2json 和 pgoutput。decoderbufs 和 wal2json 插件都需要在数据库服务器上安装特殊的库才能从 PostgreSQL 捕获更改。
随着 PostgreSQL 9.6 在 2021 年 11 月 生命周期结束，我们认为现在是简化支持的解码器数量的好时机。随着 PostgreSQL 10 及更高版本原生支持 pgoutput 解码器，我们认为在 Debezium 2.0 中移除对 wal2json 插件的支持是有意义的。
如果您仍在使用 PostgreSQL 9.6 或 wal2json 解码器，则必须升级到 PostgreSQL 10+ 或升级到 decoderbufs 或原生 pgoutput 插件才能继续使用 Debezium。
Vitess 连接器更改
Vitess 的多任务处理支持
Vitess 连接器以前允许在两种不同模式下运行，这完全取决于连接器配置是否指定了分片详细信息。不幸的是，在这两种情况下，都由单个任务负责执行 VStream 处理。对于拥有许多分片的大型 Vitess 安装，此架构可能会开始显示延迟问题，因为它可能无法跟上所有分片的所有更改。更复杂的是，在指定分片详细信息时，这需要手动解析整个集群的分片，并为每个分片启动一个单独的 Debezium 连接器，这既容易出错，更重要的是可能导致部署许多 Debezium 连接器。
Vitess 社区认识到了这一点，并寻求找到一种解决方案来解决所有这些问题，包括维护和错误方面。在 Debezium 2.0 Beta2 中，Vitess 连接器现在通过一种发现机制自动解析分片，这非常类似于 MongoDB 的机制。然后，此发现机制会将负载分配给多个任务，允许单个 Debezium 部署为每个分片或分片列表运行一个任务，具体取决于连接器允许的最大任务数。
在升级过程中，Vitess 连接器将自动将偏移量存储迁移到用于多任务处理的新格式。但请注意，一旦您升级，您将无法降级到早期版本，因为偏移量存储格式将已更改。
Debezium 容器镜像更改
支持 ARM64
近年来，ARM64 的性能发生了变化，即使在 AWS，其 64 位 ARM 处理器也显示出超过最新 x86-64 处理器的性能。这已促使整个行业关注支持容器的两种架构的成本效益。
由于 Debezium 传统上发布基于 linux/amd64 的容器镜像，因此您需要通过仿真或在虚拟机内部运行这些镜像。这会导致不必要的开销和潜在的性能问题，而 Debezium 的目标是低延迟和超高速！从 Debezium 2.0 开始，Debezium 现在还使用基于 ARM64 的容器镜像发布，从而减少了所需的开销。
我们希望新的 ARM64 容器镜像能促进 Debezium 的采用，并表明我们致力于在行业内普遍提供最佳的更改数据捕获体验。
社区空间
本周晚些时候，我们将在 Zulip 聊天平台上推出几个新的*社区驱动*的讨论空间。我们将发布一篇博文，讨论这些新频道的目的及其目标，但我们也想在此处提及此新功能。
与旨在提供社区驱动支持的 #users 频道不同，这些空间旨在为社区提供一个讨论特定数据库技术、Debezium 服务以及比支持更广泛的主题的经验的地方。这些空间将按技术划分，使用户社区能够轻松定位感兴趣的特定领域，并参与与特定数据库和服务相关的讨论。
这些空间并非旨在作为支持场所，我们将继续在 #users 频道中促进支持，因此请留意本周晚些时候推出的这些新社区空间以及后续的博文。
其他修复和改进
在 Debezium 2.0 的开发过程中，进行了许多错误修复、稳定性更改和改进。总共有 463 个问题 在此版本中得到修复。
非常感谢社区中所有为这个主要版本做出贡献的贡献者：Wang Min Chao、Rotem[Adhoh]、Ahmed ELJAMI、Alberto Martino、Alexander Schwartz、Alexey Loubyansky、Alexey Miroshnikov、Gabor[Andras]、Andrew Walker、Andrey Pustovetov、Anisha Mohanty、Avinash Vishwakarma、Bin Huang、Bob Roldan、Brad Morgan、Calin Laurentiu Ilie、Chad Marmon、Chai Stofkoper、Chris Cranford、Chris Lee、Claus Ibsen、Connor Szczepaniak、César Martínez、Debjeet Sarkar、Mikhail[Dubrovin]、Eliran Agranovich、Ethan Zou、Ezer Karavani、Gabor Andras、Giljae Joo、Gunnar Morling、Hang Ruan、Harvey Yue、Henry Cai、Himanshu Mishra、Hossein Torabi、Inki Hwang、Ismail Simsek、Jakub Cechacek、Jan Doms、Jannik Steinmann、Jaromir Hamala、Jeremy Ford、Jiabao Sun、Jiri Novotny、Jiri Pechanec、Jochen Schalanda、Jun Zhao、Kanha Gupta、Katerina Galieva、Lars Werkman、Marek Winkler、Mark Allanson、Mark Bereznitsky、Martin Medek、Mickael Maison、Mike Kamornikov、Mohammad Yousuf Minhaj Zia、Nathan Bradshaw、Nathan Smit、Naveen Kumar KR、Nils Hartmann、Nir Levy、Nitin Chhabra、Oren Elias、Paul Tzen、Paweł Malon、Pengwei Dou、Phạm Ngọc Thắng、Plugaru Tudor、Oskar[Polak]、Rahul Khanna、Rajendra Dangwal、René Kerner、Robert Roldan、Ruud H.G. van Tol、Sagar Rao、Sage Pierce、Seo Jae-kwon、Sergei Morozov、Shichao An、Stefan Miklosovic、Tim Patterson、Timo Roeseler、Vadzim Ramanenka、Vivek Wassan、Vojtech Juranek、Xinbin Huang、Yang、Yossi Shirizli、Zhongqiang Gong、moustapha mahfoud、yangrong688、合龙 张、崔世杰，以及 민규 김！
下一步是什么？
虽然我们即将迎来假期，但我们已经开始了 Debezium 2.1 的工作，该版本将于今年晚些时候发布。您可以期待的一些潜在功能包括：
-
MySQL 的截断支持
-
PostgreSQL 15 支持
-
JDBC 历史记录和偏移量存储支持
一如既往，此路线图深受社区（即您）的影响。因此，如果您希望在此看到任何特定项目，请告诉我们。现在，让我们庆祝 Debezium 2.0 发布所付出的辛勤工作，并期待今年晚些时候和 2023 年将要发生的事情！
继续前进，不断向上！
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
