検索

付録B トピック設定パラメーター

download PDF
cleanup.policy

type: list
Default: delete
Valid Values: [compact, delete]
Server Default Property: log.cleanup.policy
Importance: medium

「delete」または「compact」のいずれかまたは両方である文字列。この文字列は、古いログセグメントで使用する保持ポリシーを指定します。デフォルトのポリシー(「削除」)は、保持時間またはサイズの制限に達すると、古いセグメントを破棄します。「compact」設定は、トピックに関するログコンパクションを有効にします

compression.type

type: string
Default: producer
Valid Values: [uncompressed, zstd, lz4, snappy, gzip, producer]
Server Default Property: compression.type
Importance: medium

特定のトピックの最後の圧縮タイプを指定します。この設定では、標準の圧縮コーデック('gzip'、'snappy'、'lz4'、'zstd')を使用できます。また、圧縮なしと同等の「非圧縮」も受け入れます。「producer」は、プロデューサーによって設定された元の圧縮コードを保持しています。

delete.retention.ms

type: long
デフォルト: 86400000(1日)
有効値:
[0,…​]
Server Default Property: log.cleaner.delete.retention.ms
のインポート機能: medium

ログコンパクションされたトピック用に tombstone マーカーを削除する時間。この設定により、コンシューマーがオフセット 0 から始まる場合に読み取りを完了し、最終的なステージの有効なスナップショットを取得することができます(スキャンを完了する前に廃棄が収集される可能性があります)。

file.delete.delay.ms

type: long
デフォルト: 60000(1 分)
有効な値: [0,…​]
サーバーデフォルトプロパティー: log.segment.delete.delay.ms
インポートance: medium

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

flush.messages

type: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
Server Default Property: log.flush.interval.messages
Importance: medium

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

flush.ms

type: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
Server Default Property: log.flush.interval.ms
Importance: medium

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

follower.replication.throttled.replicas

type: list
デフォルト: ""
Valid Values: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
Server Default Property: follower.replication.throttled.replicas
Importance: medium

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

index.interval.bytes

type: int
Default: 4096(4 kibibytes)
Valid values: [0,…​]
Server Default Property: log.index.interval.bytes
Importance: medium

この設定は、Kafka がインデックスエントリーをオフセットインデックスに追加する頻度を制御します。デフォルト設定では、4096 バイトごとにメッセージがインデックス化されます。より多くのインデックスを使用すると、ログの正確な位置に読み取りをジャンプできますが、インデックスが大きくなる可能性があります。これを変更する必要はありません。

leader.replication.throttled.replicas

type: list
デフォルト: ""
Valid Values: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
Server Default Property: leader.replication.throttled.replicas
Importance: medium

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

max.compaction.lag.ms

type: long
Default: 9223372036854775807
Valid Values: [1,…​]
Server Default Property: log.cleaner.max.compaction.lag.ms
Importance: medium

メッセージがログのコンパクトな状態に保つ最大時間。圧縮されるログにのみ適用されます。

max.message.bytes

type: int
Default: 1048588
Valid Values: [0,…​]
Server Default Property: message.max.bytes
Importance: medium

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

message.format.version

type: string
デフォルト: 2.8-IV1
有効な値: [0.8.0, 0.8.1, 0.8.2, 0.9.0 0.10.0-IV0、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-IV1, 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]
Server Default Property: log.message.format.version
Importance:

ブローカーがログへのメッセージの追加に使用するメッセージ形式バージョンを指定します。値は有効な ApiVersion である必要があります。いくつかの例: 0.8.2、0.9.0.0、0.10.0、詳細は ApiVersion を確認してください。特定のメッセージ形式バージョンを設定すると、ディスク上のすべての既存メッセージがすべて、指定のバージョンより小さいか、または等しいことが認定されます。この値を不適切に設定すると、理解のない形式のメッセージを受信するため、以前のバージョンを持つコンシューマーが破損してしまう可能性があります。

message.timestamp.difference.max.ms

type: long
デフォルト: 9223372036854775807
有効な値: [0,…​]
Server Default Property: log.message.timestamp.difference.max.ms
Importance: medium

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

message.timestamp.type

type: string
デフォルト: CreateTime
Valid Values: [CreateTime, LogAppendTime]
Server Default Property: log.message.timestamp.type
Importance: medium

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

min.cleanable.dirty.ratio

type: double
Default: 0.5
Valid Values: [0,…​,1]
Server Default Property: log.cleaner.min.cleanable.ratio
Importance: medium

この設定は、ログコンパクターがログの消去を試行する頻度を制御します (ログコンパクションが有効であることを前提とします )。デフォルトでは、ログの 50% を超えてログが圧縮されるログを取り除くことはできません。この比率は、重複することで最大領域がログに記録されました(最大 50% のログが複製される可能性がある)。比率が大きいほど、より効率的な消去が少なくなりますが、ログの領域がより多くなります。max.compaction.lag.ms または min.compaction.lag.ms 設定も指定される場合、ログコンパクターは、ダーティーの割合のしきい値が満たされて、ログに、min.compaction.lag.ms のレコードが少なくとも min.compaction.lag.ms のレコードが付きます。 または、(i)ログに最大期間の max.compaction.lag.ms 期間のダーティー(複合でない)レコードがある場合です。

min.compaction.lag.ms

type: long
デフォルト: 0
有効値: [0,…​]
サーバーデフォルトプロパティー: log.cleaner.min.compaction.lag.ms
Importance: medium

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

min.insync.replicas

type: int
Default: 1
Valid Values: [1,…​]
Server Default Property: min.insync.replicas
Importance: medium

プロデューサーが ack を「all」(または「-1」)に設定する場合、この設定は、書き込みが正常に考慮されるように書き込みを確認する必要のあるレプリカの最小数を指定します。この最小値が満たされない場合、プロデューサーは例外を発生させます(NotEnoughReplicasAfterAppend のいずれか)。min.insync.replicasacks を使用すると、より優れた持続性の保証を実施することができます。典型的なシナリオは、レプリケーション係数 3 のトピックを作成し、min.insync.replicas を 2 に設定し、acks が「all」で生成することです。これにより、大多数のレプリカが書き込みを受信しない場合に、プロデューサーが例外を発生させます。

preallocate

type: boolean
Default: false
Server Default Property: log.preallocate
Importance: medium

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

retention.bytes

type: long
デフォルト: -1
サーバーデフォルトプロパティー: log.retention.bytes
インポートガイドライン: medium

この設定では、パーティションの最大サイズ(ログセグメントで構成される)が拡張でき、「削除」保持ポリシーを使用している場合には、古いログセグメントを破棄して領域を解放することができます。デフォルトでは、時間制限のみに制限はありません。この制限はパーティションレベルで適用されるため、トピックの保持をバイト単位で計算するためパーティションの数によって乗算されます。

retention.ms

type: long
Default: 604800000(7 days)
有効な値: [-1,…​]
Server Default Property: log.retention.ms
Importance: medium

この設定は、「削除」保持ポリシーを使用している場合に、古いログセグメントを破棄して領域を解放するまでの時間を制御します。これは、コンシューマーによるデータの読み取りタイミングに関する SLA を表しています。-1 に設定すると、時間制限が適用されません。

segment.bytes

type: int
デフォルト: 1073741824(1 gibibyte)
有効な値: [14,…​]
Server Default Property: log.segment.bytes
Importance: medium

この設定は、ログのセグメントファイルサイズを制御します。保持およびクリーニングは、常にファイルを 1 つずつ実行します。したがって、セグメントサイズが大きいほどファイルの数が少なくなる一方、保持を制御するよりも粒度が低くなります。

segment.index.bytes

type: int
Default: 10485760(10 mebibytes)
有効な値: [0,…​]
サーバーデフォルトプロパティー: log.index.size.max.bytes
のインポート機能: medium

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

segment.jitter.ms

type: long
デフォルト: 0
有効な値: [0,…​]
サーバーデフォルトプロパティー: log.roll.jitter.ms
インポートランス: medium

セグメントのローリング継承を防ぐために、スケジュールされたセグメントロール時間からランダムな差し引いた最大値。

segment.ms

type: long
Default: 604800000(7 days)
Valid values: [1,…​]
Server Default Property: log.roll.ms
Importance: medium

この設定により、保持が古いデータを削除/圧縮できるように、セグメントファイルが一杯でない場合は、Kafka がログのロールを強制的に実行する期間を制御します。

unclean.leader.election.enable

type: boolean
Default: false
サーバーデフォルトプロパティー: unclean.leader.election.enable
Importance: medium

ISR セットにないレプリカを最後の手段としてリーダーとして選択したくない場合は、データが失われる可能性があります。

message.downconversion.enable

type: boolean
Default: true
サーバーデフォルトプロパティー: log.message.downconversion.enable
Importance: low

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.