私は入力トピックでKTableを構築しています。私は2つのKafka StreamアプリケーションインスタンスでKStreamに参加しています。Kafka Streams KTable store with change logトピックとログ圧縮されたソーストピック
KTableの入力トピックは、すでにログ圧縮されたトピックです。したがって、アプリケーションインスタンスの1つがダウンすると、別のインスタンスの状態ストアが、入力ログの圧縮されたトピックから読み込むことによって、全体の状態でリフレッシュされているように見えます。
私のKTableストアのロギング（ログ変更）を有効にする必要はありませんか？
ソース入力ログの圧縮トピックには何百万ものレコードが含まれている可能性があります。そのKTable状態ストアにログオンすると、状態が発生した場合に状態ストアの更新時間が改善されます。すでにログは圧縮されていますか？ありがとう！
私のKTableストアのロギング（ログ変更）を有効にする必要はありませんか？
これは正しいです。 Kafka Streamsは、変更履歴トピックを追加作成することはありませんが、回復のために入力トピックを使用します（データを複製する必要はありません）。
私は
そのKTable状態ストアのログオンを有効にした場合ので、あなたはそれをどのように行うのでしょうか？
エラーが発生した場合の状態ストアのリフレッシュ時間が改善されるか、ソーストピックが既にログに圧縮されているため、効果はありませんか？
一般的には、何も得られません。あなたが正しく述べたように、入力トピックは圧縮されているので、両方のトピックにはほぼ同じデータが含まれています。
フェールオーバー時間を短縮する場合は、StreamsConfigパラメータnum.standby.replicas（デフォルトは0なので、1に設定できる）を使用してStandbyTasksを設定する必要があります。 Cf https://docs.confluent.io/current/streams/developer-guide.html#state-restoration-during-workload-rebalance
ありがとうございました！状態の復元では、changelogを使用してabtが記述されており、ソーストピック自体で十分であるかどうかはドキュメントでは分かりませんでした。 – Balmani
内部実装の詳細/最適化であり、ユーザはそれを心配する必要がないため、明示的には文書化されていません。 –