あなたは復元手順に関して正しいです。 復元は1回限りのアクティビティです。
バックアップは継続的に実行されるアクティビティです。 Kafkaデータはストリームであり、終わりがないため、Kafkaには「バックアップの実行が終了しました」というものはありません。 確かに、x秒間新しいデータを取得しなかった場合は「完了」したと見なすことができますが、それを一般化することはできません。
詳細については、＃46と＃54をご覧ください。

56：その後：

@itadventurer

バックアップは継続的に実行されるアクティビティです。

これは、24時間365日のデータの連続ストリームを想定していますが、すべての場合に当てはまるわけではありません。 この場合、ストリームは1日あたりX時間のみ実行され、バックアップはその後にのみ実行され、実際にはデータの毎日のバックアップ/スナップショットとして意図されています。

バックアッププロセスが正常に終了してプロセスを終了するまでのX時間（場合によっては構成可能な間隔）の間、新しいメッセージがないことを（内部的に）検出する方法があるはずです。

これに対する別の（おそらくより単純な）代替手段は、バックアップが開始されたときのタイムスタンプまでのメッセージのみをバックアップすることです。 これがオフセットのバックアップとどのように連携するかはわかりません。 たぶん、最初にオフセットをバックアップし、次にオフセットをバックアップしたタイムスタンプを知っており、そのタイムスタンプまでメッセージをバックアップできます。

あなたの言ってる事がわかります。 ええ、おそらく、ポイントインタイムバックアップを実行する方法があるといいでしょう：thinking：
ただし、ストリームが「終了」したかどうかを判断する簡単な方法がないため、これは簡単なことではありません。

あなたの場合にできること：

• KafkaBackupをバックグラウンドで実行します
• Kafka Backupは、バックグラウンドでファイルシステムにデータを継続的に書き込みます
• kill -9 Kafka Backupは「終了」するとすぐに、つまりデータの書き込みが終了します。 これは、データの作成が終了した後すぐに行う必要があります
• KafkaBackupのデータを新しい宛先に移動します。

これは非常に一般的なユースケースであることを理解しており、そのためのドキュメントを＃2で提供します。 v0.1の場合、ドキュメントは最後の大きな問題なので、うまくいけば、これはすぐに発生するはずです;）

私は次のアプローチを見ます

• ＃54は、新しいスタンドアロンCLIツールを紹介します。 CLIツールはこれをサポートする必要があります。
• CLIツールに新しいフラグ--snapshotを追加します（またはbackup-snapshot.shという新しいツールを追加します）

バックアップが「終了」したことを検出する方法（ --snapshotフラグが設定されている場合にのみ適用可能）：

• バックアップが開始された時刻を覚えています。 新しいタイムスタンプを持つすべてのレコードは、バックアップ中に無視されます
• パーティションがしばらくの間（たとえば20秒間）新しいデータを生成しない場合、新しいデータはないと想定します。

どう思いますか？

KafkaBackupをバックグラウンドで実行します

問題はまさにこのステップにあります。 バックグラウンドで実行し続けることはできません。 スナップショットを実行できる場合にのみ、特定のウィンドウがあります。 いつバックアップを実行できるかを決定するのは私たちの責任ではありません。それは外部の規制要件です。

バックアップが開始された時刻を覚えています。 新しいタイムスタンプを持つすべてのレコードは、バックアップ中に無視されます

はい、それはまさに私が意味したことであり、これにより、バックグラウンドで実行する必要がなくなると思います（そして、すべてのプロデューサーが完了した瞬間を捉えようとします）。

パーティションがしばらくの間（たとえば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. ラッパースクリプトを使用してこのメ​​ッセージを検出し、kafkaconnectを正常に強制終了します。 復元中に解決される方法と同様： https ：

これはそれほど些細なことではないことがわかります。

私の現在の焦点は、テストスイートを改善し、最初のリリースのために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」を用意しました。
https://gist.github.com/FloMko/7adf2e00cd80fe7cc88bb587cde999ce
ポイントインタイムバックアップの組み込みサポートに関する更新を確認すると便利です。

おい、
お疲れ様でした！ 一時的な回避策として、これを追加のスクリプトとしてこのリポジトリに追加し、後で組み込みソリューションに置き換えることを想像できます。 これをプルリクエストとして自由に追加してください：）（ ./bin/kafka-backup-point-in-time.pyまたは他の何かに;））

接続APIに依存しないGoで記述された完全に別個の実装を公開しようとしています。 参考までに。 すでに実稼働環境で使用しています。

@akamenskyソリューションを共有できますか？ ソリューションをテストしている限り、問題はありません。

@FloMko公開しました。 あなたはそれ（そして再構築されたバイナリ）をここで見つけることができます

PR＃99をありがとう@WesselVS ！ マスターにマージしました。 この機能拡張と他のいくつかの修正を含むリリースを間もなく行います。

@akamenskyかっこいい！ Kafkaバックアップに関するいくつかの作業を見るのは素晴らしいです;）