Debezium 2.0.0.Final Released

今天，我非常高兴地宣布Debezium 2.0.0.Final正式发布!

自2019年12月发布1.0版本以来，社区一直在积极构建一个全面的开源低延迟变更数据捕获(CDC)平台。在过去的三年里，我们扩展了Debezium的产品组合，包括用于Oracle的稳定连接器、社区主导的Vitess连接器、增量快照的引入、多分区支持等等。在社区活跃贡献者和提交者的帮助下，Debezium成为CDC领域事实上的领导者，部署在多个行业的许多组织的生产环境中，使用数百个连接器将数据更改从数千个数据库平台输出到实时流。

2.0版本标志着Debezium的一个新的里程碑，我们很自豪地与你们每一个人分享。

在这篇文章中，我们将深入探讨Debezium 2.0的所有变化，讨论新特性并解释大的变更在升级过程中可能产生影响。一如既往，我们强烈建议你看一看发布说明，了解更多关于所有已修复的bug，更新过程等[发布说明]，特别是从旧版本升级时。

• Debezium核心模块变更

• Cassandra连接器变更

• MongoDB连接器变更

• MySQL连接器变更

• Oracle连接器变更

• PostgresSQL连接器变更

• Vitess连接器变更

• Debezium容器镜像变更

• Debezium社区空间

Debezium核心模块变更

核心模块在Debezium 2.0中发生了相当大的变化。在本节中，我们将深入研究相关的更改，并讨论这些更改如何影响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', '__`);

stop-snapshot信号的内容看起来和execute-snapshot很类似，一个例子：

{
  "data-collections": ["schema1.table1", "schema2.table2"],
  "type": "incremental"
}

这个示例停止了schema1.table1和schema2.table2增量快照，前提是表或集合还没有完成它的增量快照。如果在删除data-collections指定的表或集合后，其他表或集合仍然未完成，增量快照将继续处理未完成的表或集合。如果没有其他表或集合，增量快照将停止。

另一个stop-snapshot的示例相当简单：

{
  "type": "incremental"
}

此示例没有指定data-collections属性，它对于stop-snapshot信号是可选的。当未指定此属性时，该信号意味着当前正在进行的增量快照应该完全停止。这使得在不知道当前或尚未捕获的表或集合的情况下可以停止增量快照。

暂停和重新开始功能

增量快照已经成为Debezium中不可或缺的特性。增量快照特性允许用户基于各种原因在一个或多个表/集合上重新运行快照。增量快照最初引入时只有一个开始信号。我们最终添加了停止正在进行的增量快照的能力，或者能够从正在进行的增量快照中删除表/集合的子集。

在这个版本中，我们在现有的信号基础上进行了构建，并引入了两个新信号，一个用于暂停正在进行的增量快照，另一个用于在之前暂停的情况下恢复增量快照。如果需要暂停增量快照，则需要发送pause-snapshot信号;如果需要恢复增量快照，则可以使用resume-snapshot信号。

这两个新信号可以使用MySQL表或Kafka topic策略发送。有关信号及其工作原理的详细信息，请参阅信号支持文档。

使用正则表达式

增量快照信号要求在data-collections配置属性中使用显式表/集合名称。虽然这工作得很好，但在某些情况下，广泛捕获配置可以利用正则表达式。我们已经在连接器配置选项中支持正则表达式，例如包含/排除表，因此将其扩展到增量快照也很有意义。

从Debezium 2.0开始，所有增量快照信号都可以在data-collections配置属性中使用正则表达式。使用上面的停止信号示例之一，可以使用正则表达式重写负载:

{
  "data-collections": ["schema[1|2].table[1|2]"],
  "type": "incremental"
}

与显式用法一样，这个带有正则表达式的信号也会停止schema1.table1和schema2.table2。

支持SQL过滤条件

尽管不常见，但可能存在连接器配置错误等情况，需要将特定记录或子集重新发送到topic。不幸的是，增量快照传统上是一个全有或全无类型的过程，我们将从集合或表中重新发出所有记录，作为快照的一部分。

在这个版本中，新增一个的additional-condition属性，允许信号指定一个基于sql的谓词来控制增量快照中应该包含哪些记录子集，而不是默认所有行。

下面的例子演示了为products表发送一个增量快照信号，但不是将表中的所有行发送到topic，而是指定了additional-condition属性，以限制快照只发送与product 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将开始自动为您处理这个问题。

事务元数据变更

事务元数据事件描述数据库事务的开始和结束(提交)。这些事件在许多方面都很有用，包括审计。默认情况下，事务元数据事件不生成，要启用此功能，必须启用provider .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
    }
  ]
}

如果已经在使用事务元数据特性，则升级后的新事件将包含此字段。

如果您没有使用事务元数据特性，但发现这很有用，只需将provider .transaction.metadata选项设置为true添加到连接器配置中。默认情况下，元数据事件被发送到以下格式的topic: ${topic.prefix}.${transaction.topic}。这可以通过指定事务来覆盖。如下图所示:

topic.prefix=server1
provide.transaction.metadata=true
transaction.topic=my-transaction-events

多分区模式

许多数据库平台都支持开箱即用的多租户功能，这意味着可以只安装一个数据库引擎，而拥有许多唯一的数据库。例如SQL Server，通常需要为每个唯一的数据库部署单独的连接器。在过去的一年里，已经做出了大量努力来打破这一障碍，并引入了一种通用的方式，使任何单个连接器部署都可以连接和传输来自多个数据库的更改。

第一个值得注意的变化是SQL Server连接器的配置选项database.dbname。该选项已被一个名为database.names的新选项所取代。由于多分区模式现在是默认的，这个新的database.names选项可以使用逗号分隔的数据库名称列表来指定，如下所示:

database.names=TEST1,TEST2

在本例中，将连接器配置为从同一主机安装上的两个唯一数据库捕获更改。连接器将在Kafka Connect中启动两个独特的任务，每个任务将负责从其各自的数据库捕获变更。

第二个值得注意的变化是连接器指标命名。连接器通过使用唯一名称标识的beans公开JMX指标。如果多分区模式是默认的多任务模式，那么每个任务都需要自己的度量bean，因此需要更改命名策略。

在以SQL Server为例的旧版本的Debezium中，使用以下命名策略可以获得指标:

debezium.sql_server:type=connector-metrics,server=,context=

在这个版本中，命名策略在JMX MBean名称中包含了一个新的任务标签:

debezium.sql_server:type=connector-metrics,server=,task=,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

这种自定义策略不仅限于控制表映射的主题名称，还可以控制schema更改、事务元数据和心跳。您可以参考DefaultTopicNamingStrategy作为示例。这个功能还在酝酿中，我们会在收到反馈后继续改进和开发它。

改进唯一索引处理

一个表不需要有主键才能被Debezium连接器捕获。在没有定义主键的情况下，Debezium将检查表的唯一索引，以确定是否可以进行合理的键替换。在某些情况下，索引可能引用列，如PostgreSQL中的CTID或Oracle中的ROWID。这些列既不可见也不是用户定义，而是由数据库自动生成的隐藏合成列。此外，索引还可以使用数据库函数转换所存储的列值，例如UPPER或LOWER。

在这个版本中，依赖于隐藏的、自动生成的列或包装在数据库函数中的列的索引不再有资格作为主键的备选项。这保证了当依赖索引作为主键而不是定义的主键本身时，生成的消息key直接映射到数据库用来表示唯一性的值相同。

新的配置命名空间

Debezium 2.0最大的改进之一是引入了新的连接器属性命名空间。从Debezium 2.0 Beta2开始，许多连接器属性都用新的名称重新定位了。这是一个突破性的更改，会影响升级过程中的大部分连接器部署。

Debezium以前使用前缀“database.”，带有大量不同的连接器属性。其中一些属性将直接传递给JDBC驱动程序，在其他情况下则传递给数据库history实现，以此类推。不幸的是，我们发现了一些情况，即某些属性被传递到底层实现，而这些实现并不是我们想要的。虽然这不会产生任何类型的回归或问题，但如果存在属性名称冲突，它可能会在未来引起问题，例如，JDBC驱动程序属性匹配与前缀为“database.”的Debezium连接器属性。

下面描述对连接器属性的更改：

• 以前配置前缀是database.history，现在要使用schema.history.internal作为前缀代替。

• 先前所有JDBC直通选项使用database.，现在应该使用driver.为前缀代替。

• 将连接器属性database.server.name重命名为topic.prefix。

• MongoDB连接器属性mongodb.name使用与topic.prefix对齐。

同样，请在部署之前检查连接器配置并进行相应调整。

All schemas named and versioned

Debezium变更事件是通过Schema定义发出的，该Schema定义包含元数据，如类型、是否可选等等。在以前的Debezium迭代中，一些模式定义没有显式名称，也没有显式版本控制。在这个版本中，我们已经开始确保所有模式定义都有一个显式的名称和与其相关联的版本。此更改的目标是帮助将来的事件结构兼容性，特别是对那些正在使用Schema Registry。但是，如果您目前正在使用Schema Registry来注册表结果，请注意此更改可能会在升级过程中导致模式兼容性问题。

默认跳过Truncate事件

Debezium支持通过skipped.operations配置来跳过指定事件类型。如果您只对操作的子集感兴趣，比如只对插入和更新感兴趣，并排除删除事件，那么这个特性可能会很有用。

一种特定的事件类型truncates (t)，只被部分连接器支持，是否要跳过这些事件是不一致的。在这个版本中，我们已经对齐了skipped.operations行为，以便如果连接器支持truncate事件，则默认跳过这些事件。

请审阅以下规则集:

• 连接器支持truncate事件，不是Oracle连接器

• 连接器配置不指定skipped.operations

如果以上所有条件都成立，那么连接器的行为将在升级后发生改变。如果希望继续触发truncate事件，请配置skipped.operations=none。

修改schema.name.adjustment行为

schema.name.adjustment.mode配置属性控制如何调整schema名称与连接器使用的消息转换器兼容。该配置选项可以是以下值之一:

avro 使用下划线替换Connect中不支持的字符。

none 不调整名称，即使检测到非avro兼容的字符。

在以前的版本中，Debezium总是默认avro；但是，从Debezium 2.0.0.CR1开始默认值是none。我们相信，如果Avro序列化的使用是由用户根据他们的需要选择的，那么这个选项应该与相同的选择行为保持一致。

安全的升级路径是调整您的配置，显式地使用schema.name.adjustment.mode作为avro，并对新的连接器部署使用默认值。但是您也可以检查您的topic名称和配置，如果没有发生下划线替换，这个更改不会产生影响。

Cassandra连接器变更

Cassndra 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。

Before state support (MongoDB 6.0)

MongoDB 6支持在应用更改之前捕获文档的state。这一直以来都是一个只对基于关系型数据库的连接器可用的特性，但是现在Debezium可以将before字段作为MongoDB的事件有效内容的一部分。

为了启用这个新的MongoDB 6+行为，调整capture.mode配置，包括两个新值:

change_streams_with_pre_image 更改事件包含更改之前的完整文档，以及更改的文档字段的最终状态。

change_streams_update_full_with_pre_image 当发生更新时，不仅会显示完整的文档以表示更新后的当前状态，而且事件还会包含更改之前的完整文档。

注意：MongoDB before字段仅在MongoDB 6或更高版本上可用。如果您使用的是6.0之前的MongoDB版本，那么即使配置了，事件输出中也会省略before字段。

MySQL连接器变更

删除历史MySQL连接器实现

有些人可能知道，也可能不知道，我们在Debezium 1.5(2021年2月)中基于公共连接器框架实现了MySQL连接器。作为重写的一部分，我们引入了配置internal.implementation，来让MySQL用户配置”legacy”启用历史连接器。为了支持新的公共连接器框架，这个遗留实现已被弃用。在Debezium 2.0中，internal.implementation配置和遗留连接器实现已被删除。

如果您当前的连接器部署依赖于这个遗留实现，那么您应该意识到，通过升级到Debezium 2.0，连接器将不再使用旧的实现，而将只使用公共连接器实现。在特性方面，这两个实现彼此相当，但有一个例外：遗留连接器对更改过滤器配置具有实验性支持。如果您依赖于此遗留行为，请注意该特性已不再可用。

Binlog压缩支持

在这个版本中，Debezium现在支持读取压缩的binlog事件。在8.0.20版本中，MySQL增加了使用ZSTD算法压缩binlog事件的能力。要启用压缩，必须切换binlog.transaction_compression变量设置为on。当启用压缩时，binlog的行为与往常一样，只是binlog条目的内容被压缩以节省空间，并以压缩格式复制到副本，从而显著减少大型事务的网络开销。

如果您有兴趣阅读更多关于MySQL binlog压缩的内容，您可以参考MySQL文档中的二进制日志事务压缩部分以获得更多详细信息。

Oracle连接器变更

Oracle source info变更

source节点是变更事件内容的一个部分，它描述了生成变更事件的数据库属性。例如，该部分包括系统更改号、更改的数据库时间戳以及更改所属的事务。

在这个版本中，我们标识了一个回归，就是scn字段没有正确地反映变更事件发生的正确来源。虽然Oracle使用相同的系统更改号生成多个更改，这是符合预期的。但我们确实发现了一个回归，导致分配给作用域事务中的每个单独事件的系统更改号是错误的，这使得一些人很难将此信息用于审计目的。source.scn字段现在应该正确反映Oracle LogMiner或Oracle Xstream的系统更改编号。

此外，还向源信息块添加了几个新字段，以改进与LogMiner实现和Oracle RAC的集成。一个新的source例子:

{
    "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 指定管理变更生命周期的实际数据库redo thread。

无论使用Oracle Standalone还是RAC，在使用Oracle LogMiner时，都会提供这些值。这些值在Oracle RAC安装中更重要，因为有多个数据库服务器同时操作共享数据库。这些字段专门注释了变更起源于哪个节点以及该节点上的什么位置。

Oracle connector offset变更

在Oracle RAC (Real Application Clusters)环境中，多个节点同时访问和操作Oracle数据库。每个节点维护自己的redo日志缓冲区，并执行自己的redo写入线程。这意味着在任何给定的时刻，每个节点都有自己独特的“位置”，这些位置将完全不同于发生在每个节点上的活动。

在这个版本中，为了支持Oracle RAC，在DBZ-5245中进行一个小小的更改。以前，连接器偏移量维护一个名为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字段，仅包含跨所有redo线程的最新scn值字符串。

Oracle commit user in change events

变更事件的source包含关于变更事件起源于何处的各种上下文。在这个版本中，Oracle连接器现在包括在捕获的更改事件中进行数据库更改的用户。现在，可以在具有此新信息的源信息块中找到一个新字段user_name。该字段是可选的，只有在使用基于logminer的实现发出更改时才可用。如果在连接器捕获更改之前删除了与更改关联的用户，则此字段还可能包含UNKNOWN的值。

PostgresSQL连接器变更

对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多Task支持

Vitess连接器以前允许在两种不同的模式下操作，这完全取决于连接器配置是否指定了任何碎片细节。不幸的是，在这两种情况下，每一种都导致了负责执行VStream处理的单一任务。对于具有许多分片的大型Vitess安装，这种架构可能会开始出现延迟问题，因为它可能无法跟上所有分片的所有更改。更复杂的是，在指定碎片细节时，这需要手动跨集群解析碎片，并为每个碎片启动单个Debezium连接器，这既容易出错，更重要的是可能导致部署许多Debezium连接器。

Vitess社区认识到了这一点，并试图从维护和错误的角度寻找解决所有这些问题的解决方案。在Debezium 2.0 Beta2中，Vitess连接器现在通过一种发现机制自动解析碎片，这与MongoDB非常相似。然后，这个发现机制将把负载分散到多个任务中，允许对每个分片或分片列表运行一个任务的Debezium进行单一部署，具体取决于连接器允许的最大任务数量。

在升级期间，Vitess连接器将自动将offset存储迁移到多任务行为使用的新格式。但请注意，一旦升级，就不能降级到较早的版本，因为存储格式已经更改。

Debezium容器镜像变更

支持ARM64

近年来，ARM64的性能已经发生了变化，即使在AWS上，64位ARM处理器的性能预期也超过了最新的x86-64处理器。这有助于在整个行业中强调用容器支持这两种体系结构的成本效益。

由于Debezium传统上发布的是基于linux/amd64的容器镜像，这要求您要么在虚拟机中使用模拟运行镜像。这会导致不必要的开销和潜在的性能问题，而Debezium的目标是低延迟和超高速度！从Debezium 2.0开始，现在发布的Debezium也使用了基于ARM64的容器镜像，减少了所需的开销。

我们希望新的ARM64容器镜像能够改进Debezium的使用，并表明我们致力于在整个行业范围内提供最好的变更数据捕获体验。

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, 合龙 张, 崔世杰, and 민규 김!

未来规划

当我们进入假期季节时，我们已经开始了Debezium 2.1的工作，将在今年晚些时候发布。你可以期待的一些潜在特性包括:

MySQL的truncate事件支持

PostgreSQL 15支持

JDBC history和offset存储支持

与以往一样，此路线图深受社区(即您)的影响。因此，如果您想在这里看到任何特定的产品，请告诉我们。现在，让我们庆祝在Debezium 2.0发布中所付出的努力，并期待今年晚些时候和2023年即将到来的东西!

Onwards and Upwards!