团队很高兴地宣布 Debezium 2.2 系列的第一个 beta 版本 Debezium 2.2.0.Beta1。
此版本包含大量错误修复、改进以及一些新功能，包括但不限于：新的 JDBC sink 连接器实现、MongoDB 分片集群改进、Google Spanner PostgreSQL 方言支持，以及 Debezium Server 的 RabbitMQ sink 实现，仅举几例。
让我们花点时间深入了解一下有什么新内容！
JDBC Sink 连接器
Debezium 2.2 系列的发布开启了 Debezium 的新篇章，Debezium 长期以来一直专注于提供一套用于关系型和非关系型数据库的源连接器。此次发布改变了这一格局，引入了新的 JDBC Sink 连接器实现。
Debezium JDBC Sink 连接器与其他供应商的实现有很大不同，因为它能够直接摄取 Debezium 连接器发出的变更事件，而无需进行事件展平。这有可能减少管道的处理开销，简化管道的配置，并使 Debezium 的 JDBC Sink 连接器能够利用众多 Debezium 源连接器的特性，如列类型传播等等。
开始使用 Debezium JDBC Sink 连接器非常简单，让我们看一个例子。
假设我们有一个名为 orders 的 Kafka 主题，其中包含未启用 ExtractNewRecordState 转换从 MySQL 创建的 Debezium 变更事件。将这些变更事件摄取到 PostgreSQL 数据库的简单配置可能如下所示：
{
"name": "mysql-to-postgres-pipeline",
"config": {
"connector_class": "io.debezium.connector.jdbc.JdbcSinkConnector",
"topics": "orders",
"connection.url": "jdbc://postgresql://<host>:<port>/<database>",
"connection.user": "<username>",
"connection.password": "<password>",
"insert.mode": "upsert",
"delete.enabled": "true",
"primary.key.mode": "record_key",
"schema.evolution": "basic"
}
}在此示例中，我们指定了一系列 connection.* 属性，用于定义访问目标 PostgreSQL 数据库的连接字符串和凭据。此外，记录在写入目标数据库时将使用 *UPSERT* 语义，如果记录不存在则插入，如果记录存在则更新。我们还启用了 Schema 演进，并指定表的主键列应从事件的主键派生。
JDBC Sink 连接器目前支持以下关系型数据库：
-
Db2
-
MySQL
-
Oracle
-
PostgreSQL
-
SQL Server
我们确实打算在未来添加更多方言，如果您希望看到某种方言的支持，请通过我们的邮件列表、聊天室或提交 Jira 增强请求与我们联系。
MongoDB 分片集群改进
在分片集群部署中使用 Debezium for MongoDB 连接器时，连接器会直接连接到每个分片副本集。这不是推荐的做法，MongoDB 建议连接器应 连接到 mongos 实例（路由器）。
此次发布符合这一推荐策略，用户应准备好稍微调整其配置，并在这种部署中使用连接器时，将连接器指向 mongos 实例。不需要其他更改。
Spanner PostgreSQL 方言支持
Google 的 Cloud Spanner 平台支持 PostgreSQL 接口，该接口将 Google Spanner 平台的规模伸缩性和可靠性与 PostgreSQL 的熟悉性和可移植性相结合。在使用此 PostgreSQL 接口操作 Google Spanner 时，列和表的元数据与使用标准 GoogleSQL 方言时不同。
此发布扩展了 Debezium Spanner 连接器的支持，不仅支持 GoogleSQL 方言，还支持使用 Spanner PostgreSQL 方言功能的用户。这意味着无论您的 Spanner 环境依赖于哪种方言，您都将能够无缝地使用 Debezium Spanner 连接器捕获 Spanner 的变更事件。
因此，如果您正在使用 Spanner 的 PostgreSQL 方言，请升级到 Debezium 2.2.0.Beta1 或更高版本，并开始捕获更改！
RabbitMQ Debezium Server Sink
Debezium Server 是一个现成的、基于 Quarkus 的 Debezium 源和 Sink 连接器运行时。Debezium Server 能够将任何源连接器的 Debezium 变更事件发送到各种消息基础设施平台，特别是对于那些更喜欢 Apache Kafka 以外解决方案的用户。
在此版本中，Debezium Server 系列中增加了一个新的 Sink 适配器，允许 Debezium 用户将变更事件发送到 RabbitMQ。以下配置展示了如何轻松配置的简单示例：
debezium.sink.type=rabbitmq
# Connection details
debezium.sink.rabbitmq.connection.host=<hostname>
debezium.sink.rabbitmq.connection.port=<port>
# The routing key specifies an override of where events are published
debezium.sink.rabbitmq.routingKey=<routing-key>
# The default is 30 seconds, specified in milliseconds
debezium.sink.rabbitmq.ackTimeout=30000debezium.sink.rabbitmq.connection.* 属性是必需的，而后面的 routingKey 和 ackTimeout 属性是可选的，或者具有预设的默认值，应足以满足大多数用例。
其他修复
此版本中还有许多其他改进、错误修复和稳定性更改，其中一些值得注意的包括
-
创建端点来更新连接器 DBZ-5314
-
重构快照以使用变更流而不是 oplog DBZ-5987
-
更新 Debezium 连接器 Filter 步骤的设计 DBZ-6060
-
当设置 schema.history.internal.store.only.captured.tables.ddl=true 时出现 NPE DBZ-6072
-
当复制槽没有 confirmed_flush_lsn 时，Postgres 连接器卡住 DBZ-6092
-
MySQL 连接器在 max.queue.size.in.bytes 时出现 java.lang.NullPointerException DBZ-6104
-
debezium-connector-mysql 在解析几个 'CREATE TABLE' 的 DDL 时失败 DBZ-6124
-
通过 mongos 实例连接和流式传输分片集群 DBZ-6170
-
支持 Azure blob 存储作为 Debezium 历史记录存储 DBZ-6180
-
Zerofill 属性对不同的 int 类型不起作用 DBZ-6185
-
GRANT DELETE HISTORY 在 mariadb 中无法解析 DBZ-6186
-
key partition table 的 ddl 解析失败 DBZ-6188
-
配置选项 internal.schema.history.internal.ddl.filter 不起作用 DBZ-6190
-
在连接器配置中支持数据库角色。DBZ-6192
-
使用 CHARSET 进行 alterByConvertCharset 子句 DBZ-6194
-
从已历史化的连接器配置中删除重复的 createDdlFilter 方法 DBZ-6197
-
创建新的 SMT 将头信息复制/移动到记录值 DBZ-6201
-
连接器重新启动时数据丢失 DBZ-6204
-
ParsingException: DDL 语句无法解析 DBZ-6217
-
CHARACTER/CHARACTER(p)/CHARACTER VARYING(p) 数据类型未被识别为 JDBC 类型 CHAR DBZ-6221
-
MySQL 在快照和流处理阶段对 BOOLEAN 同义词的处理方式不同。DBZ-6225
-
MySQL 在快照和流处理阶段对 REAL 同义词的处理方式不同。DBZ-6226
-
Spanner 连接器 - BufferedPublisher 在 publish 抛出异常时死锁 DBZ-6227
-
当消息变得非常大时，同步事件的发布失败。DBZ-6228
-
MySQL 在快照和流处理阶段对 NCHAR/NVARCHAR 的处理方式不同。DBZ-6231
-
添加对“bytea[]”类型列的支持 - bytea 数组（字节数组）DBZ-6232
-
MySQL singleDeleteStatement 解析器不支持表别名 DBZ-6243
-
使用 Debezium 的 testcontainers 套件支持 ImageFromDockerfile DBZ-6244
-
Testcontainers MongoDbReplicaSetTest 在 MongoDB 4.2 下失败 DBZ-6247
-
公开 EmbeddedEngine 配置 DBZ-6248
-
当 snapshot.custom_class=custom 且没有 snapshot.custom.class 时抛出错误 DBZ-6249
-
缺少 GEOMETRY 关键字，该关键字可用作列名 DBZ-6250
-
Postgres 连接器在尝试回退到 restart_lsn 时卡住，因为复制槽 confirmed_flush_lsn 为 null。DBZ-6251
-
MariaDB 的 UUID 列类型在加载模式时无法解析 DBZ-6255
展望与下一步？
随着 Debezium 2.2 开发周期的临近，最终版本预计在未来两周内发布，我们将开始将注意力转向 Debezium 2.3。Debezium 2.3 版本将是一个更为精简和专注的版本，我们的目标是在六月下旬发布。
我们将在未来几天内完善我们的 路线图，因此请密切关注，以了解 Debezium 2.3 的近期前景。我们希望收到您的反馈或建议，如果您有任何想分享的内容，请务必通过 邮件列表 或我们的 聊天 与我们联系。
DevNexus 2023 也将于本周（4 月 4 日至 4 月 6 日）举行，我将就使用 Debezium 的分布式系统中的 CDC 模式进行演讲。如果您在亚特兰大地区并计划参加 4 月 6 日星期四的 DevNexus，请给我留个言。
下次见，让变化继续流动……
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
