著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにTech Education Fundを選択しました。
前書き
Apache Kafkaデータのバックアップは、ユーザーエラーが原因でクラスターに追加された意図しないデータ損失や不良データから回復するのに役立つ重要な方法です。 クラスタおよびトピックデータのデータダンプは、バックアップおよび復元を実行する効率的な方法です。
バックアップされたデータを別のサーバーにインポートして移行すると、サーバーのハードウェアまたはネットワークの障害によりKafkaインスタンスが使用できなくなり、古いデータで新しいKafkaインスタンスを作成する必要がある場合に役立ちます。 バックアップされたデータのインポートと移行は、リソース使用量の変更によりKafkaインスタンスをアップグレードまたはダウングレードされたサーバーに移動する場合にも役立ちます。
このチュートリアルでは、単一のUbuntu 18.04インストールおよび別のサーバー上の複数のUbuntu 18.04インストールで、Kafkaデータをバックアップ、インポート、および移行します。 ZooKeeperは、Kafkaの運営の重要なコンポーネントです。 コンシューマーデータ、パーティションデータ、クラスター内の他のブローカーの状態など、クラスターの状態に関する情報を保存します。 そのため、このチュートリアルではZooKeeperのデータもバックアップします。
前提条件
従うには、次のものが必要です。
-
少なくとも4GBのRAMと非rootsudoユーザーがthe tutorialに従ってセットアップされたUbuntu18.04サーバー。
-
バックアップのソースとして機能する、Apache KafkaがインストールされたUbuntu 18.04サーバー。 Kafkaがソースサーバーにまだインストールされていない場合は、How To Install Apache Kafka on Ubuntu 18.04ガイドに従ってKafkaのインストールをセットアップします。
-
OpenJDK8がサーバーにインストールされています。 このバージョンをインストールするには、OpenJDKの特定のバージョンをインストールする際にこれらのinstructionsに従ってください。
-
ステップ7のオプション—バックアップの宛先として機能する、Apache Kafkaがインストールされた別のUbuntu 18.04サーバー。 以前の前提条件の記事リンクに従って、Kafkaを移行先サーバーにインストールします。 この前提条件は、Kafkaデータをあるサーバーから別のサーバーに移動する場合にのみ必要です。 Kafkaデータをバックアップして単一のサーバーにインポートする場合は、この前提条件をスキップできます。
[[step-1 -—- creating-a-test-topic-and-adding-messages]] ==ステップ1—テストトピックの作成とメッセージの追加
Kafkamessageは、Kafkaのデータストレージの最も基本的な単位であり、Kafkaに公開およびKafkaからサブスクライブするエンティティです。 Kafkatopicは、関連するメッセージのグループのコンテナーのようなものです。 特定のトピックをサブスクライブすると、その特定のトピックに発行されたメッセージのみを受け取ります。 このセクションでは、バックアップするサーバー（ソースサーバー）にログインし、Kafkaトピックとメッセージを追加して、バックアップ用にデータを入力します。
このチュートリアルでは、kafkaユーザー（/home/kafka/kafka）のホームディレクトリにKafkaがインストールされていることを前提としています。 インストールが別のディレクトリにある場合は、次のコマンドの~/kafka部分を、Kafkaインストールのパスを使用して変更し、このチュートリアルの残りの部分全体でコマンドを変更します。
以下を実行して、ソースサーバーにSSH接続します。
ssh sammy@source_server_ip次のコマンドを実行して、kafkaユーザーとしてログインします。
sudo -iu kafka次のように入力して、Kafkaインストールのbinディレクトリにあるkafka-topics.shシェルユーティリティファイルを使用して、BackupTopicという名前のトピックを作成します。
~/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic BackupTopic~/kafka/bin/kafka-console-producer.shシェルユーティリティスクリプトを使用して、文字列"Test Message 1"をBackupTopicトピックに公開します。
ここにメッセージを追加したい場合は、今すぐ追加できます。
echo "Test Message 1" | ~/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic BackupTopic > /dev/null~/kafka/bin/kafka-console-producer.shファイルを使用すると、コマンドラインから直接メッセージを公開できます。 通常、プログラム内からKafkaクライアントライブラリを使用してメッセージを公開しますが、プログラミング言語ごとに異なるセットアップが必要なため、テスト中または管理タスクの実行中にメッセージを公開する言語に依存しない方法としてシェルスクリプトを使用できます。 --topicフラグは、メッセージの公開先のトピックを指定します。
次に、次のコマンドを実行して、kafka-console-producer.shスクリプトがメッセージを公開したことを確認します。
~/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic BackupTopic --from-beginning~/kafka/bin/kafka-console-consumer.shシェルスクリプトがコンシューマーを起動します。 開始すると、前のコマンドの"Test Message 1"メッセージで公開したトピックからのメッセージをサブスクライブします。 コマンドの--from-beginningフラグを使用すると、コンシューマーが開始される前に公開されたメッセージを消費できます。 フラグを有効にしないと、コンシューマが開始された後に公開されたメッセージのみが表示されます。 コマンドを実行すると、ターミナルに次の出力が表示されます。
OutputTest Message 1CTRL+Cを押して、コンシューマーを停止します。
いくつかのテストデータを作成し、それが保持されていることを確認しました。 これで、次のセクションで状態データをバックアップできます。
[[step-2 -—- backup-up-the-zookeeper-state-data]] ==ステップ2—ZooKeeper状態データのバックアップ
実際のKafkaデータをバックアップする前に、ZooKeeperに保存されているクラスター状態をバックアップする必要があります。
ZooKeeperは、そのデータを~/kafka/config/zookeeper.properties構成ファイルのdataDirフィールドで指定されたディレクトリに保存します。 バックアップするディレクトリを決定するには、このフィールドの値を読み取る必要があります。 デフォルトでは、dataDirは/tmp/zookeeperディレクトリを指します。 インストールで値が異なる場合は、次のコマンドで/tmp/zookeeperをその値に置き換えます。
~/kafka/config/zookeeper.propertiesファイルの出力例を次に示します。
~/kafka/config/zookeeper.properties
...
...
...
# the directory where the snapshot is stored.
dataDir=/tmp/zookeeper
# the port at which the clients will connect
clientPort=2181
# disable the per-ip limit on the number of connections since this is a non-production config
maxClientCnxns=0
...
...
...ディレクトリへのパスを取得したので、その内容の圧縮アーカイブファイルを作成できます。 圧縮アーカイブファイルは、ディスク容量を節約するために、通常のアーカイブファイルよりも優れたオプションです。 次のコマンドを実行してください。
tar -czf /home/kafka/zookeeper-backup.tar.gz /tmp/zookeeper/*コマンドの出力tar: Removing leading / from member namesは、無視しても問題ありません。
-cおよび-zフラグは、tarにアーカイブを作成し、アーカイブにgzip圧縮を適用するように指示します。 -fフラグは、出力圧縮アーカイブファイルの名前を指定します。この場合はzookeeper-backup.tar.gzです。
現在のディレクトリでlsを実行して、出力の一部としてzookeeper-backup.tar.gzを表示できます。
これで、ZooKeeperデータのバックアップが正常に完了しました。 次のセクションでは、実際のKafkaデータをバックアップします。
[[step-3 -—- backing-up-the-kafka-topics-and-messages]] ==ステップ3—Kafkaトピックとメッセージのバックアップ
このセクションでは、前のステップでZooKeeperに対して行ったように、Kafkaのデータディレクトリを圧縮tarファイルにバックアップします。
Kafkaは、トピック、メッセージ、および内部ファイルを、log.dirsフィールドが~/kafka/config/server.properties構成ファイルで指定するディレクトリーに保管します。 バックアップするディレクトリを決定するには、このフィールドの値を読み取る必要があります。 デフォルトおよび現在のインストールでは、log.dirsは/tmp/kafka-logsディレクトリを指します。 インストールで値が異なる場合は、次のコマンドの/tmp/kafka-logsを正しい値に置き換えてください。
~/kafka/config/server.propertiesファイルの出力例を次に示します。
~/kafka/config/server.properties
...
...
...
############################# Log Basics #############################
# A comma separated list of directories under which to store log files
log.dirs=/tmp/kafka-logs
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=1
# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
# This value is recommended to be increased for installations with data dirs located in RAID array.
num.recovery.threads.per.data.dir=1
...
...
...まず、Kafkaサービスを停止して、tarでアーカイブを作成するときに、log.dirsディレクトリ内のデータが一貫した状態になるようにします。 これを行うには、exitと入力してサーバーの非ルートユーザーに戻り、次のコマンドを実行します。
sudo systemctl stop kafkaKafkaサービスを停止した後、次のコマンドでkafkaユーザーとして再度ログインします。
sudo -iu kafkaApache Kafkaのインストールの前提条件で、セキュリティ上の予防措置としてkafkaユーザーを制限したため、root以外のsudoユーザーとしてKafkaおよびZooKeeperサービスを停止/開始する必要があります。 前提条件のこの手順により、kafkaユーザーのsudoアクセスが無効になり、コマンドの実行に失敗します。
次に、次のコマンドを実行して、ディレクトリのコンテンツの圧縮アーカイブファイルを作成します。
tar -czf /home/kafka/kafka-backup.tar.gz /tmp/kafka-logs/*繰り返しになりますが、コマンドの出力（tar: Removing leading / from member names）は無視しても問題ありません。
現在のディレクトリでlsを実行して、出力の一部としてkafka-backup.tar.gzを表示できます。
すぐにデータを復元したくない場合は、exitと入力し、root以外のsudoユーザーに切り替えてから、次のコマンドを実行することで、Kafkaサービスを再開できます。
sudo systemctl start kafkakafkaユーザーとして再度ログインします。
sudo -iu kafkaKafkaデータを正常にバックアップしました。 次のセクションに進み、ZooKeeperに保存されているクラスター状態データを復元します。
[[ステップ-4 -—- zookeeper-dataの復元]] ==ステップ4—ZooKeeperデータの復元
このセクションでは、ユーザーがトピックの作成、追加ノードの追加/削除、メッセージの追加と消費などの操作を実行したときに、Kafkaが内部的に作成および管理するクラスター状態データを復元します。 ZooKeeperデータディレクトリを削除し、zookeeper-backup.tar.gzファイルの内容を復元することにより、データを既存のソースインストールに復元します。 別のサーバーにデータを復元する場合は、手順7を参照してください。
復元プロセス中にデータディレクトリが無効なデータを受信するのを防ぐため、KafkaおよびZooKeeperサービスを停止する必要があります。
まず、exitと入力してKafkaサービスを停止し、root以外のsudoユーザーに切り替えてから、次のコマンドを実行します。
sudo systemctl stop kafka次に、ZooKeeperサービスを停止します。
sudo systemctl stop zookeeperkafkaユーザーとして再度ログインします。
sudo -iu kafkaその後、次のコマンドを使用して、既存のクラスターデータディレクトリを安全に削除できます。
rm -r /tmp/zookeeper/*次に、ステップ2でバックアップしたデータを復元します。
tar -C /tmp/zookeeper -xzf /home/kafka/zookeeper-backup.tar.gz --strip-components 2-Cフラグは、データを抽出する前に、tarにディレクトリ/tmp/zookeeperに変更するように指示します。 --strip 2フラグを指定して、tarがアーカイブの内容を/tmp/zookeeper/自体に抽出し、その中の別のディレクトリ（/tmp/zookeeper/tmp/zookeeper/など）には抽出しないようにします。
クラスター状態データが正常に復元されました。 これで、次のセクションのKafkaデータ復元プロセスに進むことができます。
[[ステップ-5 --- kafka-dataの復元]] ==ステップ5—Kafkaデータの復元
このセクションでは、Kafkaデータディレクトリを削除し、圧縮されたアーカイブファイルを復元することにより、バックアップしたKafkaデータを既存のソースインストール（またはオプションの手順7に従っている場合は宛先サーバー）に復元します。 これにより、復元が正常に機能することを確認できます。
次のコマンドを使用して、既存のKafkaデータディレクトリを安全に削除できます。
rm -r /tmp/kafka-logs/*データを削除したので、Kafkaインストールは、新しいインストールに似ており、トピックやメッセージは含まれていません。 バックアップしたデータを復元するには、次を実行してファイルを抽出します。
tar -C /tmp/kafka-logs -xzf /home/kafka/kafka-backup.tar.gz --strip-components 2-Cフラグは、データを抽出する前に、tarにディレクトリ/tmp/kafka-logsに変更するように指示します。 --strip 2フラグを指定して、アーカイブの内容が、アーカイブ内の別のディレクトリ（/tmp/kafka-logs/kafka-logs/など）ではなく、/tmp/kafka-logs/自体に抽出されるようにします。
データが正常に抽出されたので、exitと入力して、root以外のsudoユーザーに切り替えてから、次のコマンドを実行して、KafkaサービスとZooKeeperサービスを再度開始できます。
sudo systemctl start kafkaZooKeeperサービスを開始するには：
sudo systemctl start zookeeperkafkaユーザーとして再度ログインします。
sudo -iu kafkakafkaデータを復元しました。次のセクションで、復元が成功したことの確認に進むことができます。
[[ステップ-6 ---復元の検証]] ==ステップ6—復元の検証
Kafkaデータの復元をテストするには、ステップ1で作成したトピックからのメッセージを消費します。
Kafkaが起動するまで数分待ってから、次のコマンドを実行してBackupTopicからメッセージを読み取ります。
~/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic BackupTopic --from-beginning次のような警告が表示された場合、Kafkaが完全に起動するまで待つ必要があります。
Output[2018-09-13 15:52:45,234] WARN [Consumer clientId=consumer-1, groupId=console-consumer-87747] Connection to node -1 could not be established. Broker may not be available. (org.apache.kafka.clients.NetworkClient)さらに数分後に前のコマンドを再試行するか、root以外のsudoユーザーとしてsudo systemctl restart kafkaを実行します。 復元に問題がない場合は、次の出力が表示されます。
OutputTest Message 1このメッセージが表示されない場合は、前のセクションのコマンドを逃したかどうかを確認して実行できます。
復元されたKafkaデータを検証したので、これは単一のKafkaインストールでデータを正常にバックアップおよび復元したことを意味します。 手順7に進み、クラスターとトピックのデータを別のサーバーのインストールに移行する方法を確認できます。
[[step-7 --- migrating-and-restoring-the-backup-to-another-kafka-server-optional]] ==ステップ7—バックアップを別のKafkaサーバーに移行および復元する（オプション）
このセクションでは、バックアップしたデータをソースKafkaサーバーからターゲットKafkaサーバーに移行します。 これを行うには、最初にscpコマンドを使用して、圧縮されたtar.gzファイルをローカルシステムにダウンロードします。 次に、scpを再度使用して、ファイルを宛先サーバーにプッシュします。 移行先サーバーにファイルが存在する場合、以前に使用した手順に従ってバックアップを復元し、移行が成功したことを確認できます。
バックアップファイルをローカルにダウンロードしてから、ソースサーバーから宛先サーバーに直接コピーするのではなく、宛先サーバーにアップロードします。これは、宛先サーバーの/home/sammy/.ssh/authorized_keysファイルにソースサーバーのSSHキーがなく、できないためです。ソースサーバーとの間で接続します。 ただし、ローカルマシンは両方のサーバーに接続できるため、ソースサーバーから宛先サーバーへのSSHアクセスを設定する追加の手順を省くことができます。
次のコマンドを実行して、zookeeper-backup.tar.gzファイルとkafka-backup.tar.gzファイルをローカルマシンにダウンロードします。
scp sammy@source_server_ip:/home/kafka/zookeeper-backup.tar.gz .次のような出力が表示されます。
Outputzookeeper-backup.tar.gz 100% 68KB 128.0KB/s 00:00次に、次のコマンドを実行して、kafka-backup.tar.gzファイルをローカルマシンにダウンロードします。
scp sammy@source_server_ip:/home/kafka/kafka-backup.tar.gz .次の出力が表示されます。
Outputkafka-backup.tar.gz 100% 1031KB 488.3KB/s 00:02ローカルマシンの現在のディレクトリでlsを実行すると、両方のファイルが表示されます。
Outputkafka-backup.tar.gz zookeeper.tar.gz次のコマンドを実行して、zookeeper-backup.tar.gzファイルを宛先サーバーの/home/kafka/に転送します。
scp zookeeper-backup.tar.gz sammy@destination_server_ip:/home/sammy/zookeeper-backup.tar.gz次に、次のコマンドを実行して、kafka-backup.tar.gzファイルを宛先サーバーの/home/kafka/に転送します。
scp kafka-backup.tar.gz sammy@destination_server_ip:/home/sammy/kafka-backup.tar.gzバックアップファイルが移行先サーバーに正常にアップロードされました。 ファイルは/home/sammy/ディレクトリにあり、kafkaユーザーがアクセスするための適切なアクセス許可を持っていないため、ファイルを/home/kafka/ディレクトリに移動してアクセス許可を変更できます。
次を実行して、宛先サーバーにSSHで接続します。
ssh sammy@destination_server_ip次に、以下を実行して、zookeeper-backup.tar.gzを/home/kafka/に移動します。
sudo mv zookeeper-backup.tar.gz /home/sammy/zookeeper-backup.tar.gz同様に、次のコマンドを実行して、kafka-backup.tar.gzを/home/kafka/にコピーします。
sudo mv kafka-backup.tar.gz /home/kafka/kafka-backup.tar.gz次のコマンドを実行して、バックアップファイルの所有者を変更します。
sudo chown kafka /home/kafka/zookeeper-backup.tar.gz /home/kafka/kafka-backup.tar.gz前のmvおよびchownコマンドは出力を表示しません。
バックアップファイルが正しいディレクトリの宛先サーバーに存在するようになったので、このチュートリアルのステップ4〜6にリストされているコマンドに従って、宛先サーバーのデータを復元および検証します。
結論
このチュートリアルでは、同じインストールと別のサーバーへのインストールの両方から、Kafkaのトピックとメッセージをバックアップ、インポート、および移行しました。 Kafkaの他の便利な管理タスクについて詳しく知りたい場合は、Kafkaの公式ドキュメントのoperationsセクションを参照してください。
zookeeper-backup.tar.gzやkafka-backup.tar.gzなどのバックアップファイルをリモートで保存するには、Digital Ocean Spacesを調べます。 サーバーで実行されているサービスがKafkaだけの場合は、フルインスタンスbackupsなどの他のバックアップ方法を調べることもできます。