Debezium日常分享系列之：Debezium 3.0.8.Final发布
- 稀疏向量逻辑类型重命名
- 架构历史配置默认值的更改
- 潜在的 Vitess 数据丢失
- Oracle 的 Reselect 列后处理器行为更改
- MariaDB 的 SSL 连接
稀疏向量逻辑类型重命名
- PostgreSQL 扩展 vector（也称为 pgvector）提供了一种实现多种向量数据类型的方法，其中包括一种称为 sparsevec 的类型。稀疏向量仅存储向量内的已填充键/值条目，排除那些未设置的条目，以最小化表示数据集所使用的空间。
- Debezium 3.0 引入了名为 io.debezium.data.SparseVector 的稀疏向量逻辑类型。当我们开始评估其他关系数据库的实现时，我们发现逻辑名称在我们开始实现其他稀疏向量类型时是不充分的。
- 在 Debezium 3.1 和 3.0.8.Final 中，我们将 io.debezium.data.SparseVector 类从 PostgreSQL 连接器中重新打包到 Debezium 的核心包中，同时将类名更改为 SparseDoubleVector，并将逻辑名称更改为 io.debezium.data.SparseDoubleVector，以与类名的更改保持一致。
- 对于那些可能一直在使用 SparseVector 逻辑类型的用户，可能需要调整代码以识别新的逻辑类型名称。
架构历史配置默认值的更改
schema.history.internal.store.only.captured.databases.ddl的文档提供了一个错误的默认值。虽然这不是一个特定于代码的破坏性更改，但应该花点时间重新评估部署配置是否依赖于不同的默认值。
潜在的 Vitess 数据丢失
- Debezium for Vitess 连接器存在一个罕见但关键的数据丢失 bug，该 bug 自五年前首次引入以来一直存在。如果主键更新是事务中的最后一个操作，则记录可能会丢失。此 bug 影响所有之前的版本。强烈建议用户立即更新到 3.0.8.Final 或 3.1.0.Alpha2 或更高版本，以解决潜在的数据丢失问题。
Oracle 的 Reselect 列后处理器行为更改
- ReselectColumnsPostProcessor 的行为已更改，无论
lob.enabled配置属性的值如何，Oracle LOB 列都将被重新选择。这一更改使那些在流式传输时不想挖掘 LOB 列的用户可以通过列重新选择过程来填充 LOB 列，作为替代方案。
MariaDB 的 SSL 连接
- 用户可能发现在之前的 Debezium 版本中从 MariaDB 捕获变更时，SSL 连接无法正常工作。我们很高兴地报告，这个问题已经得到修复，用户现在应该能够使用 MariaDB 的 SSL 连接。
- 虽然可以使用相同的配置属性
database.ssl.mode，但 MariaDB 使用不同的值来表示驱动程序和数据库之间的协商步骤。以下表格列出了 MariaDB 的设置。
| SSL模式 | 描述 |
|---|---|
| disabled | 指定 JDBC 驱动程序不应尝试与数据库服务器协商 SSL 连接。如果数据库服务器要求安全连接，连接将被拒绝。 |
| trust | 指定 JDBC 驱动程序应使用 SSL/TLS 进行数据加密，且不会验证证书和主机名。 |
| verify-ca | 指定 JDBC 驱动程序应使用 SSL/TLS 进行数据加密，并且会验证证书，但不会验证主机名。 |
| verify-full | 指定 JDBC 驱动程序应使用 SSL/TLS 进行数据加密，并且会验证证书和主机名。这是 TLS 的标准行为。 |
MariaDB 11.4 或更高版本默认使用 SSL 连接，因此需要设置一个适当的 database.ssl.mode，或者禁用 MariaDB 的 SSL 连接。
