작성
·
50
답변 2
0
안녕하십니까,
먼저 아래 인프런 AI 답변 중 Dead Queue Letter는 Sink Connector 일 때 적용할 수 있습니다. Debezium Source Connector에서는 Dead Queue Letter 방식으로 오류를 처리할 수 없습니다.
질문을 잘 이해하지 못했습니다만,
질문하신 '재처리'라는게 어떤 처리를 의미하는 건지요? 오류가 발생한 상황에서의 재처리를 의미하신것 같은데, 어떤 오류 상황이고(예를 들어 binlog가 손상되었는데, 이게 복구가 완료되었다거나), 어떤 재처리 인지 좀 더 명확하게 말씀해 주시겠습니까?
그리고,
"재처리를 위해 SourceDB 또는 별도 로그성 테이블에 메시지발행에 대한 상태를 기록하고 싶을 경우, 커넥터로부터 메시지발행 성공에 대한 응답을 받을 수 있을까요?"
라는 의미가 Source Connector가 Source DB로 부터 update된 데이터 변경을 Kafka topic에 기록하는 것 외에 log sequence 레벨로 성공/실패 여부만 별도의 로그나 db에 기록하는 방법을 물어보시는 건지요?
만약에 그렇다면, debezium을 사용하시면 connector에서 로그 메시지 남기는 것 외에 말씀하신 방식으로 별도 저장하는 방법이 없습니다.
감사합니다.
재처리란 custom smt에서 에러가 발생하거나 connector transform config에서 없는 컬럼을 참조하거나 했을때 저장되는 offset은 해당 로우가 처리된것으로 판단되는것 같아, 다시 db의 해당 로우를 메세지로 발행하려면 수동 재처리가 필요하다고 생각했습니다.
=> Source DB 에서 Debezium Connector 가 bin log를 읽어 들인 뒤, offset을 저장하고, topic에 메시지를 저장하는 메카니즘으로 생각하셔서 수동 재처리를 말씀하셨군요.
하지만 debezium은 source db의 bin log를 읽은 뒤 topic에 메시지를 저장한 다음에 connect-offset 토픽에 해당 bin log sequence의 position을 기록하게 됩니다. 그러니까 binlog 읽어들임 -> topic에 해당 메시지 저장 -> connect-offset 토픽에 해당 binlog sequence 기록과 같은 방식으로 저장되므로 수동 재처리를 하실 필요가 없습니다.
대부분의 장애 처리는 binlog를 제대로 구성하는 방식으로 진행됩니다.
0
안녕하세요, 인프런 AI 인턴입니다. 지토리님.
Debezium과 같은 CDC(Change Data Capture) 도구를 활용할 때, DB의 binlog 변경 사항을 감지하여 메시지를 발행하면서 발생할 수 있는 문제에 대한 질문을 주셨습니다. 특히, 메시지 발행의 성공 여부를 확인하고 싶으신 것 같습니다.
Debezium은 Kafka Connect 프레임워크 위에서 동작하므로, Kafka 자체의 메시지 발행 성공 여부를 직접적으로 커넥터가 응답하지는 않습니다. 그러나 다음과 같은 방법으로 해결할 수 있습니다:
Dead Letter Queue (DLQ) 활용: Kafka Connect는 메시지 처리 실패 시 재검토가 필요한 메시지를 Dead Letter Queue에 저장할 수 있습니다. 이를 통해 실패한 메시지를 추적하고, 재처리를 할 수 있는 메커니즘을 구축할 수 있습니다.
커스텀 모니터링 구현: Kafka와 연동하여 모니터링 도구를 사용하거나, 별도의 로그성 테이블에 커넥터의 상태나 에러를 기록하는 커스텀 구현을 고려해 볼 수 있습니다.
Kafka Connect Worker 로그 확인: Worker 로그를 통해 메시지가 정상적으로 처리되었는지 여부를 확인할 수 있습니다. 이를 기반으로 실패 여부를 모니터링하고 대응할 수 있는 절차를 설정할 수 있습니다.
보다 구체적인 구현이나 사용 사례에 대해 알아 보고 싶으시면, 다음 유사한 질문들을 참고하시면 좋을 것 같습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사드립니다.
제가 말씀드린 재처리란 custom smt에서 에러가 발생하거나 connector transform config에서 없는 컬럼을 참조하거나 했을때 저장되는 offset은 해당 로우가 처리된것으로 판단되는것 같아, 다시 db의 해당 로우를 메세지로 발행하려면 수동 재처리가 필요하다고 생각했습니다. 그러려면 카프카 커넥트가 메세지 발행까지 완료되었는지를 알려줄 수 있는 방법이 있나했는데 로그 외에 다른 방식은 없는 것으로 이해하면 될까요?