errors.deadletterqueue.topic.name对源连接器是否生效?Debezium MongoDB场景问询
Great question—let's unpack why your DLQ setup works for JDBC Sink but not Debezium MongoDB Source, and whether those error configs apply to source connectors at all.
Short Answer
Yes, the errors.* configuration properties are designed to work with both source and sink connectors, but there are version-specific limitations and Debezium-specific behaviors in Kafka Connect 2.4.0 that are likely preventing your serialization errors from hitting the DLQ.
1. Why Source Connectors Handle Errors Differently
Sink connectors usually hit serialization errors when converting existing Kafka records to the target system's format—this happens well within the Connect pipeline, so the DLQ mechanism catches it easily.
For source connectors like Debezium MongoDB, serialization errors often occur earlier: when parsing MongoDB change events into Kafka Connect's Struct format, before the record is even written to a Kafka topic. In Kafka Connect 2.4.0, these early-stage parsing failures sometimes don't trigger the DLQ because they're handled before the record enters the standard error-handling pipeline.
2. Debezium's Internal Error Handling
Debezium has its own error-handling properties that might be overriding Connect's DLQ setup. Check if your connector config includes mongodb.error.handling.mode:
- If set to
ignoreorlog, Debezium will handle the error internally instead of passing it to Connect's DLQ system. - The default value is
fail, which should let Connect take over, but it's worth confirming you haven't modified this.
3. Kafka Connect 2.4.0's DLQ Limitations
Kafka Connect 2.4.0 is a fairly old release (2019), and the DLQ implementation for source connectors was still maturing. Later versions (2.5 and above) fixed several gaps in error propagation, ensuring that more types of source-side errors (including serialization failures) are routed to the DLQ as expected.
Troubleshooting Steps to Try
- Temporarily enable error logging: Flip
"errors.log.enable": "true"to see if the serialization errors are being logged anywhere. This will confirm whether the errors are even reaching Connect's error-handling layer. - Test with a deliberate bad record: Create a MongoDB document with an unsupported data type (like a binary field Debezium can't serialize) to trigger a clear error—this will help you isolate if the issue is specific to certain error types.
- Check for conflicting Debezium configs: Ensure no other Debezium-specific error properties are overriding your DLQ setup.
- Upgrade if possible: If your environment allows it, upgrading to Kafka Connect 2.5+ (and matching Debezium version) is the most reliable fix for this DLQ propagation issue.
内容的提问来源于stack exchange,提问作者Holm

