web-dev-qa-db-ja.com

バックアップ/復元kafkaおよびzookeeper

kafkaのシンプルな3ノードとzookeeperの5ノードを実行してkafkaを実行していますが、kafka、私のzookeeperでも同じです。

今のところ、データディレクトリをs3バケットにエクスポートするだけです...

ありがとう。

apache-kafkabackupapache-zookeeperrestore
8
starttter

Zalandoは最近かなり良い記事を公開しました how to backup Kafka and Zookeeper 。一般的にKafka=バックアップには2つのパスがあります：

  • 2番目のKafka=クラスターを維持します。すべてのトピックが複製されます。このセットアップは確認していませんが、オフセットトピックも複製される場合、別のクラスターに切り替えてもコンシューマーの処理状態が損なわれないはずです。
  • トピックをクラウドストレージにダンプします。 S3コネクタを使用します（Zalandoの説明どおり）。復元の場合、トピックを再作成し、クラウドストレージのデータをフィードします。これにより、ポイントインタイム復元を行うことができますが、消費者は最初からトピックから読み始める必要があります。

推奨されるバックアップソリューションは、ユースケースによって異なります。例えば。ストリーミングアプリケーションの場合、最初のソリューションで苦痛を軽減できますが、イベントソースにKafka=を使用する場合は、2番目のソリューションの方が望ましい場合があります。

Zookeeperについて、Kafka=は、トピック（永続ストア）の情報だけでなく、ブローカーの発見とリーダーの選出（一時）についても保持します。Zalandoは Burry 単純にZookeeperツリー構造を反復処理し、ファイル構造にダンプし、後でZip圧縮してクラウドストレージにプッシュします。 小さな問題 の影響を受けますが、ほとんどの場合、Kafkaの永続データのバックアップには影響しません（ Zalandoは、復元する場合、まずZookeeperクラスターを作成し、次に新しいKafkaクラスターを（一意の新しいブローカーIDを使用して）接続してから復元する方が良いと説明しています）バリーのバックアップ：バリーは、既存のノードを上書きせず、バックアップに保存されている古いブローカーに関する一時的な情報を入れません。

注：彼らは出展者の使用について言及していますが、Burryでバックアップするときのバックアップには実際には必要ありません。

10
krzychu

Apache Kafka=はすでにデータの分散を維持し、強力で一貫性のある replication 機能を提供します。

アーキテクチャ設計の観点から、まずバックアップが私たちにとって何を意味するのかを理解する必要がありますか？

  • データセンターの障害に耐えるためのものですか？

    コメントで述べたように、データセンター全体がダウンした場合を想像してください。それは、カフカだけでなく、そのデータセンターで実行されているすべてのものがなくなったことを意味します。このような種類の障害を処理するには、異なるデータセンターへのリアルタイムレプリケーション戦略を設計する必要があり、そのために kafka-mirror makerを使用できます。別のデータセンター（必ずしも同じハードウェアリソースではない）にkafkaクラスターを設定し、現在のデータセンターを設定する必要がありますKafka=この他のデータセンターで。

データセンター全体に障害が発生した場合、すべてのサービスはこのフォールバックデータセンターから実行され、ミラー化されたKafkaをプライマリkafkaとして使用します。

その後、もう一方のデータセンターが復旧したら、反対の方法でミラーをセットアップし、古い（破壊された）データセンターにアクセスできます。

  • kafka/Zookeeperデータのバックアップのみですか？

Kafka connectには、kafkaからのデータを一貫性を保証して転送するための、すぐに使用できるコネクターがいくつかあります。したがって、AWS S3をバックアップストアとして選択できます。

  • コンフルエントなAWS S3コネクタ

  • Pinterestにはsecorサービスがあります AWS S3、GoogleおよびMircosoft Cloudストレージにデータを転送します。また、すべてのビッグクラウドプロバイダー専用のコネクタを見つけることもできます。 Kafka=データを高可用性クラウドストレージにバックアップする場合に考慮する必要のあるものはほとんどありません。

  • kafkaにはトピックごとにデータ保持ポリシーがあるため、古いデータはKafkaサーバー自体からKafka自体によって削除されますが、AWSには残りますS3バケット。したがって、復元イベントの場合に直接コピーして戻すと、Kafkaブローカーでより多くのデータが表示されます。また、データ全体を既存に復元することはお勧めできません実行中Kafka clusterこれは古いデータの処理を開始するためです。したがって、このプロセスでは慎重に選択してください

  • Zookeeperの場合、データをAWS S3にコピーすることもできますが、一時ノードのため、復元には注意する必要があります。役立つリンクをいくつか見つけました。

https://jobs.zalando.com/tech/blog/backing-up-kafka-zookeeper/https://www.elastic.co/blog/zookeeper-backup-a -treatisehttps://medium.com/@Pinterest_Engineering/zookeeper-resilience-at-pinterest-adfd8acf2a6b

最後に、「予防は治療よりも優れています」。したがって、AWSのようなクラウドプロバイダーのセットアップで実行している場合、障害を事前に頭に入れておくことでクラスターのセットアップをデプロイできます。以下のリンクにはいくつかの情報があります。

https://aws.Amazon.com/blogs/big-data/best-practices-for-running-Apache-kafka-on-aws/

3
Peeyush