Kafka-backup: 소비자 오프셋

안녕하세요 임란입니다.

기본 영구 컨테이너 연결 스토리지를 제공하는 다른 오픈 소스 프로젝트 OpenEBS를 사용하여 Kubernetes 환경에서 Kafka 주제의 백업 및 복원에 대한 블로그 게시물을 작성 중입니다.

파일 시스템 스냅샷을 사용하여 Kafka를 백업하는 것은 그리 쉬운 일이 아닙니다. 이에 대한 자세한 내용은 https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md 를 참조하세요.

지금은 Spredfast의 S3 커넥터를 사용하기로 결정했지만 내 친구 Arash Kaffamanesh가 당신의 작업을 알려줬습니다. 몇 가지 질문이 있었습니다.

소비자 오프셋을 복원할 필요가 없다면 S3 커넥터가 완벽해 보입니다. 나는 S3 커넥터의 소스 코드에 대해 깊이 파고들었다. S3 커넥터는 중요한 기능을 제공하지 않고 그 경우를 처리하기 위해 확장하기 어렵기 때문에 우리 문제에 대한 솔루션으로 이를 일축했다.

복원할 때 소비자에게 어디서부터 소비를 시작해야 하는지 어떻게 알릴 수 있습니까?

현재 유일한 방법은 복원해서는 안 되는 세그먼트를 삭제하고 인덱스를 다시 만드는 것입니다. 이를 달성하는 방법에 대한 자세한 정보가 곧 제공될 것입니다. 매우 특정한 오프셋에서 복원을 시작해야 하는 경우 문제를 여십시오. 구현하기가 어렵지 않아야 합니다.

spredfast의 커넥터와 추가 차이점을 공유할 수 있습니까?

다시 말하지만, S3 커넥터는 복원 중에 소비자 오프셋을 동기화할 수 없습니다. 사실, 현재 Kafka 버전에서는 안정적으로 그렇게 할 수 있는 방법이 없습니다. Mirror Maker 2 에 대한 @ryannedolan 작업 덕분에 곧 그렇게 할 수 있는 방법이 생겨 kafka-backup 에서 해당 API를 사용합니다. 운 좋게도 이 변경 사항은 이전 버전과도 호환되며 곧 kafka-backup 을 사용하는 방법에 대한 문서가 제공될 것입니다.

또한 S3 커넥터는 S3만 지원합니다. 현재 kafka-backup 는 파일 시스템으로의 백업만 지원하며 원하는 도구를 사용하여 최종 대상으로 이동할 수 있습니다. 필요한 경우 더 많은 스토리지 백엔드에 대한 지원을 추가할 계획입니다.

그 외에도 두 프로젝트는 구조적으로 매우 유사합니다(실제로 S3 커넥터와 Mirror Maker 2는 kafka-backup 에 영감을 주었습니다)

내 Kafka 환경은 Kubernetes에서 실행됩니다. 이상적으로는 장애 발생 시 복구할 수 있도록 클러스터 외부의 백업/복원 스토리지 위치를 원합니다.

당신이 Strimzi도 사용하고 있다는 것을 아는 한, 우리는 동일한 백업을 가지고 있습니다. Kubernetes 및 Strimzi에서 Kafka와 Zookeeper의 전체 백업을 수행하는 방법에 대해 곧 블로그 게시물을 작성할 것입니다.

백업 위치는 target.dir에 의해 결정되며, 환경이 Kubernetes인 경우 노드에서 경로를 관리하기 어려워집니다.

항상 그렇듯이 영구 볼륨을 마운트하십시오. 사이드카 컨테이너를 사용하여 최종 목적지로 이동합니다. 오래된 세그먼트와 해당 인덱스가 완료되는 즉시 삭제할 수 있으므로 영구 볼륨을 비교적 작게 유지할 수도 있습니다. (문서가 온다)

며칠 더 기다리면 귀하의 주제 중 일부를 다루는 소개 블로그 게시물을 게시하겠습니다. 저에게 이메일을 쓰거나 @arashkaffamanesh 에게 초안을 요청하세요.wink:

@azapps ' 기여는 독특하고 굉장합니다. 저는 전체 커뮤니티가 @azapps 가 제안하고 구현한 Kafka Backup이 Kafka 생태계의 표준화된 부분이 되도록 도와야 한다고 생각합니다!

완벽한 것은 없지만 @azapps 의 이 구현은 훌륭합니다!

기록을 위해: 여기로 이동합니다: https://medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee