복원 절차에 대한 귀하의 의견이 옳습니다. 복원은 일회성 활동입니다.
백업은 지속적으로 실행되는 활동입니다. Kafka 데이터는 스트림이고 끝이 없기 때문에 Kafka에는 "백업을 완료했습니다"가 없습니다. 물론 x 초 동안 새 데이터를 얻지 못했다면 "완료"되었다고 가정할 수 있지만 일반화할 수는 없습니다.
자세한 내용은 #46 및 #54를 참조하세요.

56: 그럼:

@itadventurer

백업은 지속적으로 실행되는 활동입니다.

이것은 모든 경우에 적용되지 않는 24x7x365 데이터의 연속 스트림을 가정합니다. 우리의 경우 스트림은 하루에 X시간 동안만 실행되며 백업은 그 이후에만 발생하며 실제로는 데이터의 일일 백업/스냅샷으로 사용됩니다.

백업 프로세스가 정상적으로 종료되어 프로세스를 종료한 후 X 시간(구성 가능한 간격) 동안 새 메시지가 없음을 (내부적으로) 감지하는 방법이 있어야 한다고 생각합니다.

이것에 대한 또 다른(더 간단할 수 있는) 대안은 백업이 시작된 타임스탬프까지만 메시지를 백업하는 것입니다. 이것이 오프셋 백업과 함께 어떻게 작동하는지 확실하지 않습니다. 오프셋을 먼저 백업한 다음 오프셋을 백업한 타임스탬프를 알고 해당 타임스탬프까지 메시지를 백업할 수 있습니다.

너의 의도를 알 겠어. 예, 아마도 특정 시점 백업을 수행하는 방법이 있으면 좋을 것입니다.
그러나 스트림이 "완료"되었는지 여부를 쉽게 결정할 수 있는 방법이 없기 때문에 이것은 사소한 일이 아닙니다.

귀하의 경우에 할 수 있는 일:

• Kafka Backup이 백그라운드에서 실행되도록 허용
• Kafka Backup은 백그라운드에서 파일 시스템에 지속적으로 데이터를 씁니다.
• kill -9 Kafka Backup은 "완료"되는 즉시, 즉 데이터 쓰기를 완료합니다. 데이터 생성을 완료한 후 즉시 수행해야 합니다.
• Kafka Backup의 데이터를 새 대상으로 이동합니다.

나는 이것이 매우 일반적인 사용 사례라는 것을 이해하며 #2를 통해 이에 대한 더 많은 문서를 제공할 것입니다. v0.1 문서의 경우 마지막 큰 문제이므로 이것이 곧 일어나기를 바랍니다. ;)

나는 다음과 같은 접근 방식을 본다

• #54는 새로운 독립형 CLI 도구를 소개합니다. CLI 도구는 이를 지원해야 합니다.
• CLI 도구에 새 플래그 --snapshot 를 추가합니다(또는 backup-snapshot.sh 라는 새 도구를 추가합니다).

백업이 "완료"되었을 때 감지하는 방법( --snapshot 플래그가 설정된 경우에만 적용 가능):

• 백업이 시작된 시간을 기억합니다. 최신 타임스탬프가 있는 모든 레코드는 백업 중에 무시됩니다.
• 파티션이 일정 시간(예: 20초) 동안 새 데이터를 생성하지 않으면 새 데이터가 없다고 가정합니다.

어떻게 생각하나요?

Kafka Backup이 백그라운드에서 실행되도록 허용

문제는 바로 이 단계에 있습니다. 백그라운드에서 계속 실행할 수 없습니다. 스냅샷을 수행할 수 있는 특정 창만 있습니다. 백업을 언제 수행할 수 있는지 결정하는 것은 우리에게 달려 있지 않으며 외부 규정 요구 사항입니다.

백업이 시작된 시간을 기억합니다. 최신 타임스탬프가 있는 모든 레코드는 백업 중에 무시됩니다.

네, 그게 정확히 제가 의미한 바이며 백그라운드에서 실행해야 하는 요구 사항을 제거할 것이라고 생각합니다(모든 생산자가 완료되는 순간을 잡으려고 노력함).

파티션이 일정 시간(예: 20초) 동안 새 데이터를 생성하지 않으면 새 데이터가 없다고 가정합니다.

이 옵션은 다른 옵션과 상호 배타적이라고 생각합니다. 그리고 첫 번째 것이 특정 기준점을 제공하고 메시지가 없을 때 창을 찾는 데 의존하지 않기 때문에 더 낫다고 생각합니다.

사실 나는 이것이 Kafka에서는 거의 불가능하다고 쓰고 싶었지만, 글을 쓰는 동안 해결책에 대한 아이디어를 얻었습니다.

kafka-consumer-groups 는 파티션에서 소비자의 현재 위치를 반환하지만 더 흥미롭게도 각 특정 파티션의 현재 끝 오프셋을 반환합니다. 이것은 특정 시점에서 파티션에 대한 최신 오프셋을 얻을 수 있는 방법이 있음을 의미합니다. 현재 이것이 어떻게 달성되는지 전혀 모릅니다(코드를 확인해야 함).

이제 (다소) 특정 시점 백업을 수행하는 방법이 명확해졌습니다.

1. 백업할 모든 파티션에 대한 파티션 끝 오프셋을 가져옵니다(여기 어딘가: https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink /BackupSinkTask.java#L81 )
2. 모든 파티션 사용
3. 소비된 레코드에 오프셋 >= 이 있는 즉시 해당 파티션에 대해 저장된 오프셋을 기억하십시오. 백업의 모든 레코드를 무시합니다. (https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink/BackupSinkTask.java#L63 참조)
4. 모든 파티션이 최신 상태가 되자마자 STDOUT에 메시지를 인쇄합니다.
5. 래퍼 스크립트를 사용하여 이 메시지를 감지하고 kafka 연결을 정상적으로 종료하십시오. 복원 중 해결 방법과 유사: https://github.com/itadventurer/kafka-backup/blob/master/bin/restore-standalone.sh#L232 -L252

당신은 이것이 정말 사소하지 않다는 것을 알 수 있습니다.

현재 초점은 테스트 스위트를 개선하고 첫 번째 릴리스를 위해 Kafka Backup을 안정화하는 것입니다(https://github.com/itadventurer/kafka-backup/milestone/1 참조). 해당 기능에 대한 ETA를 알려드릴 수 없습니다. 나는 그것에 대한 PR을 검토하는 것을 기쁘게 생각합니다 (또한 추가 관리자를 찾고 있습니다 ;) ) 질문이 있으면 기꺼이 도와 드리겠습니다.

당신은 이것이 정말 사소하지 않다는 것을 알 수 있습니다.

저는 운영 측면(예: Kafka 클러스터 설정, 모니터링 등)에 더 관심이 있습니다. 그래서 이 부분에서 당신을 믿습니다. 제 요점은 제 업무 측면에서 이것이 저와 다른 많은 사람들에게 필요한 것입니다.

이에 대한 PR을 검토하게 되어 기쁩니다(또한 추가 유지 관리자를 찾고 있습니다 ;))

저는 Java/Scala에 대해 그다지 도움이 되지 않습니다. 그것이 Python, C/C++ 또는 최소한 Go라면 내가 도울 수 있습니다 :P

여보세요!
처음에는 - kafka 주제 데이터를 백업해야 하기 때문에 귀하의 솔루션을 찾게 되어 기쁩니다.
두 번째로 - 불행히도 Java/Scala에서 아무 것도 쓸 수 없었으므로 전체 백업 솔루션을 위해 python으로 'backup-standalone.sh'를 위해 'wrapper'를 준비했습니다.
https://gist.github.com/FloMko/7adf2e00cd80fe7cc88bb587cde999ce
특정 시점 백업에 대한 기본 제공 지원에 대한 업데이트를 확인하는 것이 좋습니다.

이봐,
작업해주셔서 감사합니다! 임시 해결 방법으로 이것을 이 저장소에 추가 스크립트로 추가하고 나중에 기본 제공 솔루션으로 대체하는 것을 상상할 수 있습니다. 이것을 풀 요청으로 자유롭게 추가하십시오 :) ( ./bin/kafka-backup-point-in-time.py 또는 다른 것으로 ;) )

Connect API에 의존하지 않는 Go로 작성된 완전히 별도의 구현을 게시하려고 합니다. 참고로. 이미 프로덕션 환경에서 사용하고 있습니다.

@akamensky 솔루션을 공유할 수 있습니까? 솔루션을 테스트한 한 괜찮을 것입니다.

@FloMko 방금 게시했습니다. 여기에서 찾을 수 있습니다(재구축된 바이너리도 포함)

PR #99를 보내 주신 @WesselVS님 감사합니다! 방금 마스터로 병합했습니다. 이 개선 사항 및 기타 수정 사항이 포함된 릴리스를 곧 수행할 예정입니다.

@akamensky 멋지다! Kafka 백업에 관한 더 많은 작업을 볼 수 있어 좋습니다. ;)