Debezium日常分享系列之：Debezium 2.7.0.Final发布
- 一、重大改变
- 1.core
- 2.Oracle
- 3.PostgreSQL
- 4.SQL Server
- 二、新功能和改进
- 1.Core
- 交易元数据编码排序
- 阻止增量快照改进
- 快照和流之间的可选延迟
- 2.DB2
-
- 3.JDBC
-
- 4.MariaDB
-
- 5.MongoDB
- 支持MongoDB增量快照的谓词条件
- ExtractNewDocumentState包含 MongoDB 删除的文档 ID
- 集合范围的变更流
- 6.MySQL
-
- 7.Oracle
- 新的 Oracle“RawToString”自定义转换器
- 改进了对 Oracle 的 NLS 字符集支持
- Oracle ROW_ID 包含在更改事件中
- Oracle 使用自定义模式名称刷新表
- Oracle 大量表查询过滤器
- 8.PostgreSQL
- 带有 JDBC 接收器的 PostreSQL 数组
- 只读增量快照
- 9.SQL Server
-
- 10.Cassandra
-
- 11.Vitess
-
- 12.Debezium Server
- 使用 JWT/seed 进行 NATS 身份验证
- NATS JetStream 接收器身份验证改进
- 添加了 JMX 导出器
- 13.Kubernetes Operator
- 使用 Helm Chart 安装 Debezium Operator
- 使用 Debezium Operator 启用 JMX Exporter
- 当缩放为零时停止 Debezium 服务器
- 三、更多内容
一、重大改变
1.core
- Debezium 快照工件最初部署到 oss.sontatype.org，即现在的遗留 Sonatype 基础设施。这种情况已经改变，现在可以在 s01.oss.sonatype.org（新的 Sonatype 基础设施上找到工件快照。
- 在某些情况下，我们会观察到 JDBC 查询处于持续挂起状态，例如数据库通信错误。引入了名为 query.timeout.ms 的可配置超时属性，作为缓解遇到此问题的用户的问题的方法。此选项默认为 600000 毫秒（600 秒），但可以更改为值 0 以禁用超时处理。
2.Oracle
- 当设置为 double 或 string 时，decimal.handling.mode 将忽略使用零刻度的 NUMERIC 数据类型的表。此问题已得到修复，现在将根据配置的十进制处理模式正确发出此类列。这可能会导致使用严格架构注册表兼容性规则的部署升级出现问题。
3.PostgreSQL
- PostgreSQL 10 和 11 处于生命周期结束 (EoL) 模式已有一段时间了。现在认为对这些版本的支持是尽力而为的，这意味着我们不再针对这些数据库版本显式测试 Debezium。核心团队不会主动修复任何回归问题；但是，回归将继续接受社区贡献。
4.SQL Server
- 在 Debezium 的旧版本中，SQL Server 连接器将处理轮询迭代期间可用的所有事务。这可能会导致大流量的内存问题。 max.iteration.
