第2章 トピック設定プロパティー


cleanup.policy

型: list
デフォルト: delete
有効な値: [compact, delete]
サーバーのデフォルトプロパティー: log.cleanup.policy
重要度:

この設定は、ログセグメントで使用する保持ポリシーを指定します。"削除" ポリシー (デフォルト) は、保存期間またはサイズ制限に達すると、古いセグメントを破棄します。"コンパクト" ポリシーは、各キーの最新の値を保持する ログ圧縮 を有効にします。コンマ区切りのリストで両方のポリシーを指定することもできます (例: "delete,compact")。この場合、古いセグメントは保持時間とサイズの設定に従って破棄され、保持されたセグメントは圧縮されます。

compression.gzip.level

型: int
デフォルト: -1
有効な値: [1,…​,9] または -1
サーバーのデフォルトプロパティー: compression.gzip.level
重要度:

compression.type が gzip に設定されている場合に使う圧縮レベル。

compression.lz4.level

型: int
デフォルト: 9
有効な値: [1,…​,17]
サーバーのデフォルトプロパティー: compression.lz4.level
重要度:

compression.type が lz4 に設定されている場合に使う圧縮レベル。

compression.type

型: string
デフォルト: producer
有効な値: [uncompressed, zstd, lz4, snappy, gzip, producer]
サーバーのデフォルトプロパティー: compression.type
重要度:

特定のトピックの最終的な圧縮タイプを指定します。この設定は、標準の圧縮コーデック ('gzip'、'snappy'、'lz4'、'zstd') を受け入れます。さらに、圧縮なしに相当する 'uncompressed' と、プロデューサーによって設定された元の圧縮コーデックを維持する 'producer' も使用できます。

compression.zstd.level

型: int
デフォルト: 3
有効な値: [-131072,…​,22]
サーバーのデフォルトプロパティー: compression.zstd.level
重要度:

compression.type が zstd に設定されている場合に使用する圧縮レベル。

delete.retention.ms

型: long
デフォルト: 86400000 (1 日)
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.cleaner.delete.retention.ms
重要度:

ログ圧縮 トピックの tombstone 削除マーカーを保持する期間。また、この設定は、最終ステージの有効なスナップショットを確実に取得するために、コンシューマーがオフセット 0 から開始する場合に読み取りを完了しなければならない時間にも制限を与えます (そうでない場合、スキャンを完了する前に、delete tombstone が収集される可能性があります)。

file.delete.delay.ms

型: long
デフォルト: 60000 (1 分)
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.segment.delete.lay.ms
重要度:

ファイルシステムからファイルを削除するまでの待機時間。

flush.messages

型: long
デフォルト: 9223372036854775807
有効な値: [1,…​]
サーバーのデフォルトプロパティー: log.flush.interval.messages
重要度:

この設定により、ログに書き込まれたデータの fsync を強制する間隔を指定できます。たとえば、これが 1 に設定されている場合、すべてのメッセージの後に fsync を実行します。5 に設定されている場合は、5 つのメッセージごとに fsync します。一般に、これを設定せずに永続性のためにレプリケーションを使用すること、そしてオペレーティングシステムのバックグラウンドフラッシュ機能がより効率的であることから、この機能を使用することが推奨されます。この設定は、トピックごとに上書きできます (トピックごとの設定セクション を参照)。

flush.ms

型: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.flush.interval.ms
重要度:

この設定により、ログに書き込まれるデータの fsync を強制する時間間隔を指定できます。たとえば、これが 1000 に設定されていた場合は、1000 ミリ秒が経過した後に fsync を実行します。一般に、これを設定せずに永続性のためにレプリケーションを使用すること、そしてオペレーティングシステムのバックグラウンドフラッシュ機能がより効率的であることから、この機能を使用することが推奨されます。

follower.replication.throttled.replicas

型: list
デフォルト: ""
有効な値: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
サーバーのデフォルトプロパティー: null
重要度:

ログレプリケーションをフォロワー側でスロットリングする必要があるレプリカのリスト。リストには、レプリカのセットを [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…の形式で記述する必要があります。または、ワイルドカード '*' を使用して、このトピックのすべてのレプリカを調整できます。

index.interval.bytes

型: int
デフォルト: 4096 (4 キビバイト)
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.index.interval.bytes
重要度:

この設定は、Kafka がインデックスエントリーをオフセットインデックスに追加する頻度を制御します。デフォルト設定では、およそ 4096 バイトごとにメッセージを確実にインデックス化します。インデックス化を増やすことで、読み取りをログ内の正確な位置に近づけることができますが、インデックスは大きくなります。おそらくこれを変更する必要はありません。

leader.replication.throttled.replicas

型: list
デフォルト: ""
有効な値: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
サーバーのデフォルトプロパティー: null
重要度:

ログレプリケーションをリーダー側でスロットリングする必要があるレプリカのリスト。リストには、レプリカのセットを [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…の形式で記述する必要があります。または、ワイルドカード '*' を使用して、このトピックのすべてのレプリカを調整できます。

local.retention.bytes

型: long
デフォルト: -2
有効な値: [-2,…​]
サーバーのデフォルトのプロパティー: log.local.retention.bytes
重要度:

古いセグメントを削除する前にパーティションに対して拡張できるローカルログセグメントの最大サイズ。デフォルト値は -2 で、使用される retention.bytes の値を表します。有効な値は、常に retention.bytes 値以下である必要があります。

local.retention.ms

型: long
デフォルト: -2
有効な値: [-2,…​]
サーバーのデフォルトプロパティー: log.local.retention.ms
重要度:

削除前にローカルログセグメントを保持する時間 (ミリ秒単位)。デフォルト値は -2 です。これは retention.ms の値が使用されることを示します。有効な値は、常に retention.ms 値以下である必要があります。

max.compaction.lag.ms

型: long
デフォルト: 9223372036854775807
有効な値: [1,…​]
サーバーのデフォルトプロパティー: log.cleaner.max.compaction.lag.ms
重要度:

メッセージがログコンパクションの対象外のままになる最大時間。圧縮されるログにのみ適用されます。

max.message.bytes

型: int
デフォルト: 1048588
有効な値: [0,…​]
サーバーのデフォルトプロパティー: message.max.bytes
重要度:

Kafka によって許可される最大のレコードバッチサイズ (圧縮が有効な場合は圧縮後)。これが増加し、0.10.2 より古いコンシューマーが存在する場合、コンシューマーのフェッチサイズも大きくして、このような大きなレコードバッチをフェッチできるようにする必要があります。最新のメッセージ形式バージョンでは、効率化のためにレコードは常にバッチにグループ化されます。以前のメッセージ形式のバージョンでは、圧縮されていないレコードはバッチにグループ化されず、この制限はその場合の単一レコードにのみ適用されます。

message.format.version

型: string
デフォルト: 3.0-IV1
有効な値: [0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV1, 0.10.1-IV0, 0.10.1-IV1, 0.10.1-IV2, 0.10.2-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV2, 1.0-IV0, 1.1-IV0, 2.0-IV0, 2.0-IV1, 2.1-IV0, 2.1-IV1, 2.1-IV2, 2.2-IV0, 2.2-IV1, 2.3-IV0, 2.3-IV1, 2.4-IV0, 2.4-IV1, 2.5-IV0, 2.6-IV0, 2.7-IV0, 2.7-IV1, 2.7-IV2, 2.8-IV0, 2.8-IV1, 3.0-IV0, 3.0-IV1, 3.1-IV0, 3.2-IV0, 3.3-IV0, 3.3-IV1, 3.3-IV2, 3.3-IV3, 3.4-IV0, 3.5-IV0, 3.5-IV1, 3.5-IV2, 3.6-IV0, 3.6-IV1, 3.6-IV2, 3.7-IV0, 3.7-IV1, 3.7-IV2, 3.7-IV3, 3.7-IV4, 3.8-IV0, 3.9-IV0]
サーバーのデフォルトプロパティー: log.message.format.version
重要度:

[非推奨] ブローカーがログにメッセージを追加するために使用するメッセージ形式バージョンを指定します。inter.broker.protocol.version が 3.0 以上の場合、この設定の値は常に 3.0 であると想定されます (実際の設定値は無視されます)。それ以外の場合は、この値は有効な ApiVersion である必要があります。たとえば、0.10.0、1.1、2.8、3.0 です。特定のメッセージ形式のバージョンを設定することで、ユーザーは、ディスク上の既存のメッセージすべてが指定したバージョンよりも小さいか、等しいことを認定します。この値を誤って設定すると、以前のバージョンを持つコンシューマーが、認識されない形式でメッセージを受信するため、破損します。

message.timestamp.after.max.ms

型: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.message.timestamp.after.max.ms
重要度:

この設定では、メッセージのタイムスタンプとブローカーのタイムスタンプの間の許容可能なタイムスタンプの差を設定します。メッセージのタイムスタンプはブローカーのタイムスタンプ以降にすることができますが、許容可能な最大の差はこの設定の値によって決まります。message.timestamp.type=CreateTime の場合、タイムスタンプの差がこの指定されたしきい値を超えると、メッセージが拒否されます。この設定は、message.timestamp.type=LogAppendTime の場合は無視されます。

message.timestamp.before.max.ms

型: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.message.timestamp.before.max.ms
重要度:

この設定では、ブローカーのタイムスタンプとメッセージのタイムスタンプの間の許容可能なタイムスタンプの差を設定します。メッセージのタイムスタンプはブローカーのタイムスタンプ以前にすることができますが、許容可能な最大の差はこの設定の値によって決まります。message.timestamp.type=CreateTime の場合、タイムスタンプの差がこの指定されたしきい値を超えると、メッセージが拒否されます。この設定は、message.timestamp.type=LogAppendTime の場合は無視されます。

message.timestamp.difference.max.ms

型: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.message.timestamp.difference.max.ms
重要度:

[非推奨] ブローカーがメッセージを受信したときのタイムスタンプと、メッセージに指定されたタイムスタンプとの間の最大差。message.timestamp.type=CreateTime の場合、タイムスタンプの相違点がこのしきい値を超えるとメッセージが拒否されます。この設定は、message.timestamp.type=LogAppendTime の場合は無視されます。

message.timestamp.type

型: string
デフォルト: CreateTime
有効な値: [CreateTime, LogAppendTime]
サーバーのデフォルトプロパティー: log.message.timestamp.type
重要度:

メッセージのタイムスタンプが、メッセージ作成時間かログの追加時間であるかを定義します。値は CreateTime または LogAppendTime である必要があります。

min.cleanable.dirty.ratio

型: double
デフォルト: 0.5
有効な値: [0,…​,1]
サーバーのデフォルトプロパティー: log.cleaner.min.cleanable.ratio
重要度:

この設定は、ログコンパクターがログのクリーンアップを試行する頻度を制御します (ログコンパクション が有効になっている場合).。デフォルトでは、50% を超えるログが圧縮されているログのクリーニングは、回避されます。この比率は、重複によって無駄になるログの最大スペースを制限します (50% の場合、最大でログの 50% が重複している可能性があります)。比率が高いほど、より少ない、より効率的なクリーニングを意味しますが、ログ内の無駄なスペースが多くなることを意味します。max.compaction.lag.ms または min.compaction.lag.ms 設定も指定されている場合、ログコンパクターは、次のいずれかの場合にすぐにログをコンパクションの対象と見なします。(i) ダーティー比率のしきい値に達し、ログに少なくとも min.compaction.lag.ms duration 期間のダーティー (圧縮されていない) レコードがある場合、または (ii) ログに最大で max.compaction.lag.ms 期間のダーティー (圧縮されていない) レコードがある場合。

min.compaction.lag.ms

型: long
デフォルト: 0
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.cleaner.min.compaction.lag.ms
重要度:

メッセージがログで圧縮されないままになる最小時間。圧縮されるログにのみ適用されます。

min.insync.replicas

型: int
デフォルト: 1
有効な値: [1,…​]
サーバーのデフォルトプロパティー: min.insync.replicas
重要度:

プロデューサーが acks を "all" (または "-1") に設定すると、この設定は、書き込みが成功したとみなされるために書き込みを確認する必要のあるレプリカの最小数を指定します。この最小値が満たされない場合、プロデューサーは例外 (NotEnoughReplicas または NotEnoughReplicasAfterAppend のいずれか) を発生させます。min.insync.replicasacks を併用することで、より高い持続性が保証されます。一般的なシナリオでは、レプリケーション係数 3 のトピックを作成し、min.insync.replicas を 2 に設定し、acks を "all" にして生成します。これにより、レプリカの大部分が書き込みを受信しない場合に、プロデューサーは確実に例外を発生させます。

preallocate

型: boolean
デフォルト: false
サーバーのデフォルトプロパティー: log.preallocate
重要度:

新規ログセグメントの作成時にファイルをディスクに事前割り当てする場合は True。

remote.storage.enable

型: boolean
デフォルト: false
サーバーのデフォルトプロパティー: null
重要度:

トピックの階層型ストレージを有効にするには、この設定を true に設定します。この設定を一度有効にすると、無効にすることはできません。これは今後のバージョンで提供されます。

retention.bytes

型: long
デフォルト: -1
サーバーのデフォルトプロパティー: log.retention.bytes
重要度:

この設定は、"delete" 保持ポリシーを使用している場合に、領域を解放するために古いログセグメントを破棄する前に、(ログセグメントで構成される) パーティションを拡大できる最大サイズを制御します。デフォルトでは、サイズ制限はなく、時間制限のみがあります。この制限はパーティションレベルで適用されるため、これにパーティションの数を掛けて、トピックの保持をバイト単位で計算します。さらに、retention.bytes 設定は、"segment.ms" および "segment.bytes" 設定とは独立して動作します。さらに、retention.bytes がゼロに設定されている場合、新しいセグメントのローリングがトリガーされます。

retention.ms

型: long
デフォルト: 604800000 (7 日)
有効な値: [-1,…​]
サーバーのデフォルトプロパティー: log.retention.ms
重要度:

この設定は、"delete" 保持ポリシーを使用している場合に、古いログセグメントを破棄して領域を解放する前にログを保持する最大時間を制御します。これは、コンシューマーがどれだけ早くデータを読み込まなければならないかという SLA を意味します。-1 に設定すると、時間制限は適用されません。さらに、retention.ms 設定は、"segment.ms" および "segment.bytes" 設定とは独立して動作します。さらに、retention.ms 条件が満たされた場合、新しいセグメントのローリングがトリガーされます。

segment.bytes

型: int
デフォルト: 1073741824 (1 ギビバイト)
有効な値: [14,…​]
サーバーのデフォルトプロパティー: log.segment.bytes
重要度:

この設定は、ログのセグメントファイルサイズを制御します。保持とクリーニングは常に 1 ファイルずつ行われるため、セグメントサイズが大きくなると、ファイルは少なくなりますが、保持の制御が細かくできなくなります。

segment.index.bytes

型: int
デフォルト: 10485760 (10 メビバイト)
有効な値: [4,…​]
サーバーのデフォルトプロパティー: log.index.size.max.bytes
重要度:

この設定では、オフセットをファイルの位置にマップするインデックスのサイズを制御します。このインデックスファイルを事前割り当てし、ログロールの後にのみ縮小します。通常、この設定を変更する必要はありません。

segment.jitter.ms

型: long
デフォルト: 0
有効な値: [0,…​]
サーバーのデフォルトプロパティー: log.roll.jitter.ms
重要度:

セグメントローリングの大規模な集約を避けるために、スケジュールされたセグメントロール時間から差し引いたランダムなジッターの最大値。

segment.ms

型: long
デフォルト: 604800000 (7 日)
有効な値: [1,…​]
サーバーのデフォルトプロパティー: log.roll.ms
重要度:

この設定は、セグメントファイルがいっぱいでない場合でも、Kafka がログを強制的にロールして、古いデータを削除または圧縮できるようにする期間を制御します。

unclean.leader.election.enable

型: boolean
デフォルト: false
サーバーのデフォルトプロパティー: unclean.leader.election.enable
重要度:

データが失われる可能性がある場合でも、ISR セットにないレプリカを最後の手段として、リーダーとして選出できるようにするかどうかを示します。

message.downconversion.enable

型: boolean
デフォルト: true
サーバーのデフォルトプロパティー: log.message.downconversion.enable
重要度:

この設定は、消費リクエストを満たすためにメッセージ形式のダウンコンバートを有効にするかどうかを制御します。false に設定すると、ブローカーは古いメッセージ形式を想定しているコンシューマーに対してダウンコンバートを実行しません。ブローカーは、そのような古いクライアントからの消費リクエストに対して、UNSUPPORTED_VERSION エラーを返します。この設定は、フォロワーへのレプリケーションに必要なメッセージ形式の変換には適用されません。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat