Debezium CoreConnector

启动时出现难以理解的错误

我们解决了一个问题，即连接器会因误导性的错误消息而无法启动，恢复了平滑的启动过程，同时保留了改进的偏移验证
用户在连接器启动过程中遇到了这种令人困惑的异常情况。

org.apache.kafka.connect.errors.DataException: Invalid value: null used for required field: "schema", schema type: STRING

这个不明确的错误信息没有提供任何有用的线索来确定实际问题所在，使故障排除变得几乎不可能。

这个问题是由于我们最近对偏移验证所做的改进引起的。我们改进了逻辑，在源数据库中不再有可用的偏移位置时提供更详细的错误消息，这有助于诊断常见的操作问题。

但是，新的验证逻辑假设在连接器启动时某些偏移属性已经存在。实际上，这些属性是在连接器生命周期的后期才被填充的，导致验证提前失败，并显示了一个无用的错误消息

我们更新了异常处理逻辑，旨在：

• 避免在启动阶段对偏移量属性的可用性做出预设；
• 在偏移量确实无效的情况下，保留强化的验证机制；
• 当偏移位置确实存在问题时，提供有意义的错误信息；
• 允许正常启动流程继续进行，避免误报干扰；

此项修复确保您能在不中断启动过程的前提下，获得增强的错误报告功能。

临时阻塞快照失败可能导致数据丢失的问题修复

我们已解决一个关键缺陷：当临时阻塞快照（ad-hoc blocking snapshots）执行异常时可能造成数据丢失。此次修复确保即使快照失败，流式数据仍能保持完整。

原问题分析：执行临时阻塞快照时，若表中存在无效数据会导致快照失败。该故障会引发严重副作用：快照期间产生的流式事件将永久丢失。这意味着，若快照运行数小时后遭遇异常数据，连接器恢复流式传输时将完全跳过这数小时内发生的所有实时数据变更。

解决方案：新版阻塞快照通过以下机制实现故障安全处理：

• 精准保存快照起始位点：持久化记录快照开始前的精确流式处理位置
• 自动断点续传：快照失败时自动从正确位置恢复处理
• 数据零丢失保障：无论快照何时因何故中断，均确保数据完整性

价值说明：此项改进显著提升阻塞快照在生产环境的可靠性。

Debezium for Oracle

最后批次处理吞吐量指标优化我们提升了Oracle LogMiner适配器中LastBatchProcessingThroughput JMX指标的准确性，使您能更精准监控连接器性能。

原计算逻辑缺陷：此前该指标基于每批次实际处理的表事件数量计算吞吐量。该方式在以下场景会导致数据失真：

• 库级过滤干扰：即使连接器仍需读取评估被过滤记录，事件计数减少导致吞吐量虚低
• 事务标记干扰：事件流中的事务控制标记显著扭曲统计值，实际处理负载被低估
• 配置项干扰：各类配置变更引发指标波动，无法真实反映连接器性能

新计算方案：现改为基于从LogMiner数据集读取的JDBC物理行数计算吞吐量，包含：

• 被JVM配置过滤的行
• 事务控制记录
• 不符合表/模式过滤条件的行

核心价值：新版指标精准反映Debezium连接器在每批次处理窗口中的原始处理能力。