Kafka-backup: 消費者オフセット

こんにちはイムラン、

基盤となる永続コンテナ接続ストレージを提供する別のオープンソースプロジェクトOpenEBSを使用して、Kubernetes環境でのKafkaトピックのバックアップと復元に関するブログ投稿を書いています。

ファイルシステムのスナップショットを使用してKafkaをバックアップすることは、それほど簡単ではありません。 詳細については、 https：//github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.mdを参照してください。

今のところ、私はSpredfastのS3コネクタを使用することに決めましたが、友人のArashKaffamaneshがあなたの仕事を教えてくれました。 いくつか質問がありました。

コンシューマーオフセットを復元する必要がない場合、S3コネクタは完全に正常に見えます。 S3コネクタのソースコードを深く掘り下げてから、問題の解決策として却下しました。これは、その重要な機能を提供しておらず、その場合を処理するために拡張するのが難しいためです。

復元時に、どこから消費を開始するかを消費者に知らせるにはどうすればよいですか？

現在のところ、唯一の方法は、復元してはならないセグメントを削除して、インデックスを再作成することです。 それを達成する方法については、まもなくより多くの情報があります。 非常に特定のオフセットから復元を開始する必要がある場合は、問題を開いてください。 それを実装するのは難しいことではありません。

spredfastのコネクタとの追加の違いを教えてください。

この場合も、S3コネクタは復元中にコンシューマーオフセットを同期できません。 実際、現在のKafkaバージョンでは、これを確実に行う方法はありません。 Mirror Maker 2での@ryannedolanの作業のおかげで、すぐにそうする方法があり、 kafka-backupはそのAPIを使用します。 幸いなことに、この変更には下位互換性があり、すぐにkafka-backupをそのように使用する方法のドキュメントがあります。

さらに、S3コネクタはS3のみをサポートします。 現在、 kafka-backupはファイルシステムへのバックアップのみをサポートしており、最終的な宛先に移動するために必要なツールを使用できます。 必要に応じて、ストレージバックエンドのサポートを追加する予定です。

それを除けば、2つのプロジェクトはアーキテクチャ的に非常に似ています（実際、S3コネクタとMirror Maker 2はkafka-backupに触発されました）

私のKafka環境はKubernetesで実行されます。 理想的には、障害が発生した場合に復元できるように、クラスターの外部にバックアップ/復元の保存場所が必要です。

Strimziも使用していることがわかっている限り、同じバックアップがあります。 Kafkaと（忘れないでください！）KubernetesとStrimziのZookeeperの完全バックアップを作成する方法をすぐにブログに投稿します。

バックアップの場所はtarget.dirによって決定されます。環境がKubernetesの場合、ノード上のパスの管理が困難になります。

いつものように永続ボリュームをマウントするだけです。 サイドカーコンテナを使用して、最終目的地に移動します。 古いセグメントとそのインデックスが完成したらすぐに削除できるため、永続ボリュームを比較的小さく保つこともできます。 （ドキュメントが来ています）

さらに数日お待ちいただく場合は、いくつかのトピックを取り上げた紹介ブログ投稿を公開します。 私にメールを書くか、 @ arashkaffamaneshにドラフトを依頼してください：wink：

@azappsの貢献はユニークで素晴らしいものであり、コミュニティ全体が、@azappsによって提案および実装されたKafkaBackupを取得して、Kafkaエコシステムの標準化された部分にするのに役立つはずです。

完璧なものはありませんが、 @ azappsによるこの実装は素晴らしいです！

記録のために：ここに行きます： https ：//medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee