TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiKVコンフィグレーションファイル

TiKV 構成ファイルは、コマンドライン パラメーターよりも多くのオプションをサポートしています。デフォルトの構成ファイルはetc/config-template.tomlにあり、その名前をconfig.tomlに変更します。

このドキュメントでは、コマンドライン パラメーターに含まれないパラメーターのみについて説明します。詳細については、 コマンドラインパラメータを参照してください。

ヒント：

設定項目の値を調整する必要がある場合は、 構成を変更するを参照してください。

グローバル構成

abort-on-panic

  • TiKV パニック時にabort()を呼び出してプロセスを終了するかどうかを設定します。このオプションは、TiKV がシステムでコア ダンプ ファイルの生成を許可するかどうかに影響します。

    • この構成項目の値がfalseの場合、TiKV がパニックになると、 exit()を呼び出してプロセスを終了します。
    • この構成項目の値がtrueの場合、TiKV がパニックになると、TiKV はabort()を呼び出してプロセスを終了します。現時点では、TiKV により、システムは終了時にコア ダンプ ファイルを生成できます。コア ダンプ ファイルを生成するには、コア ダンプに関連するシステム構成 (たとえば、 ulimit -cコマンドを使用してコア ダンプ ファイルのサイズ制限を設定し、コア ダンプ パスを構成するなど) を実行する必要もあります。オペレーティング システムが異なると、関連する構成も異なります。 ）。コア ダンプ ファイルが多くのディスク領域を占有し、TiKV のディスク領域が不足することを避けるために、TiKV データとは異なるディスク パーティションにコア ダンプ生成パスを設定することをお勧めします。

  • デフォルト値: false

slow-log-file

  • 遅いログを保存するファイル
  • この設定項目が設定されておらず、 log.file.filenameが設定されている場合、スローログはlog.file.filenameで指定されたログファイルに出力されます。
  • slow-log-fileもlog.file.filename設定されていない場合、デフォルトですべてのログが「stderr」に出力されます。
  • 両方の設定項目が設定されている場合、通常ログはlog.file.filenameで指定したログファイルに出力され、スローログはslow-log-fileで指定したログファイルに出力されます。
  • デフォルト値: ""

slow-log-threshold

  • 低速ログを出力するためのしきい値。処理時間がこの閾値よりも長い場合、遅いログが出力されます。
  • デフォルト値: "1s"

memory-usage-limit

  • TiKV インスタンスのメモリ使用量の制限。 TiKV のメモリ使用量がこのしきい値にほぼ達すると、内部キャッシュが削除されてメモリが解放されます。

  • ほとんどの場合、TiKV インスタンスは利用可能なシステムメモリの合計の 75% を使用するように設定されているため、この構成項目を明示的に指定する必要はありません。メモリの残りの 25% は OS ページ キャッシュ用に予約されています。詳細についてはstorage.block-cache.capacityを参照してください。

  • 単一の物理マシンに複数の TiKV ノードを展開する場合でも、この構成項目を設定する必要はありません。この場合、TiKV インスタンスは5/3 * block-cache.capacityのメモリを使用します。

  • さまざまなシステムメモリ容量のデフォルト値は次のとおりです。

    • システム=8G ブロックキャッシュ=3.6G メモリ使用量制限=6G ページキャッシュ=2G
    • システム=16G ブロックキャッシュ=7.2G メモリ使用量制限=12G ページキャッシュ=4G
    • システム=32G ブロックキャッシュ=14.4G メモリ使用量制限=24G ページキャッシュ=8G

ログv5.4.0 の新機能

  • ログに関するコンフィグレーション項目です。

  • v5.4.0 より、TiKV と TiDB のログ設定項目を整合させるため、TiKV は以前の設定項目log-rotation-timespanを非推奨とし、 log-level 、 log-format 、 log-file 、 log-rotation-sizeを以下の設定項目に変更します。古い構成項目のみを設定し、その値がデフォルト以外の値に設定されている場合、古い項目は新しい項目との互換性を維持します。新旧両方の設定項目が設定されている場合は、新しい設定項目が有効になります。

level v5.4.0 の新機能

  • ログレベル
  • オプションの値: "debug" 、 "info" 、 "warn" 、 "error" 、 "fatal"
  • デフォルト値: "info"

format v5.4.0 の新機能

  • ログ形式
  • オプション"text"値: "json"
  • デフォルト値: "text"

イネーブルタイムスタンプv5.4.0 の新enable-timestamp

  • ログのタイムスタンプを有効にするか無効にするかを決定します。
  • オプションfalse値: true
  • デフォルト値: true

log.file v5.4.0 の新機能

  • ログファイルに関するコンフィグレーション項目です。

filename v5.4.0 の新機能

  • ログファイル。本設定項目が設定されていない場合、デフォルトでログは「stderr」に出力されます。この設定項目を設定すると、対応するファイルにログが出力されます。
  • デフォルト値: ""

max-size v5.4.0 の新機能

  • 単一のログ ファイルの最大サイズ。ファイルサイズがこの設定項目で設定した値より大きい場合、システムは自動的に 1 つのファイルを複数のファイルに分割します。
  • デフォルト値: 300
  • 最大値： 4096
  • 単位: MiB

max-days v5.4.0 の新機能

  • TiKV がログ ファイルを保持する最大日数。
    • 構成項目が設定されていない場合、またはその値がデフォルト値0に設定されている場合、TiKV はログ ファイルをクリーンアップしません。
    • このパラメーターが0以外の値に設定されている場合、TiKV はmax-daysの後に期限切れのログ ファイルをクリーンアップします。
  • デフォルト値: 0

max-backups v5.4.0 の新機能

  • TiKV が保持するログ ファイルの最大数。
    • 構成項目が設定されていない場合、またはその値がデフォルト値0に設定されている場合、TiKV はすべてのログ ファイルを保持します。
    • 構成項目が0以外の値に設定されている場合、TiKV は最大でmax-backupsで指定された数の古いログ ファイルを保持します。たとえば、値が7に設定されている場合、TiKV は最大 7 つの古いログ ファイルを保持します。
  • デフォルト値: 0

pd.enable-forwarding v5.0.0 の新機能

  • ネットワーク分離の可能性がある場合に、TiKV の PD クライアントがフォロワー経由でリーダーにリクエストを転送するかどうかを制御します。
  • デフォルト値: false
  • 環境でネットワークが分離されている可能性がある場合、このパラメータを有効にすると、サービスが利用できなくなる期間を短縮できます。
  • 分離、ネットワークの中断、またはダウンタイムが発生したかどうかを正確に判断できない場合、このメカニズムを使用すると判断を誤るリスクがあり、可用性とパフォーマンスの低下が発生します。ネットワーク障害が発生したことがない場合は、このパラメータを有効にすることはお勧めできません。

サーバー

  • サーバーに関連するコンフィグレーション項目。

addr

  • リスニングIPアドレスとリスニングポート
  • デフォルト値: "127.0.0.1:20160"

advertise-addr

  • クライアント通信用のリスニング アドレスをアドバタイズする
  • この構成項目が設定されていない場合は、値addrが使用されます。
  • デフォルト値: ""

status-addr

  • 構成アイテムは、 HTTPアドレスを通じて TiKV ステータスを直接報告します。

  • ステータス アドレスを無効にするには、値を""に設定します。

  • デフォルト値: "127.0.0.1:20180"

status-thread-pool-size

  • HTTP API サービスのワーカー スレッドの数
  • デフォルト値: 1
  • 最小値: 1

grpc-compression-type

  • gRPC メッセージの圧縮アルゴリズム
  • "gzip" "deflate"値: "none"
  • デフォルト値: "none"

grpc-concurrency

grpc-concurrent-stream

  • gRPC ストリームで許可される同時リクエストの最大数
  • デフォルト値: 1024
  • 最小値: 1

grpc-memory-pool-quota

  • gRPC で使用できるメモリサイズを制限します
  • デフォルト値: 制限なし
  • OOM が発生した場合に備えてメモリを制限します。使用量を制限すると、ストールが発生する可能性があることに注意してください

grpc-raft-conn-num

  • Raft通信における TiKV ノード間の最大リンク数
  • デフォルト値: 1
  • 最小値: 1

max-grpc-send-msg-len

  • 送信できる gRPC メッセージの最大長を設定します
  • デフォルト値: 10485760
  • 単位: バイト
  • 最大値： 2147483647

grpc-stream-initial-window-size

  • gRPC ストリームのウィンドウ サイズ
  • デフォルト値: 2MB
  • 単位: KB|MB|GB
  • 最小値: "1KB"

grpc-keepalive-time

  • gRPC がkeepalive Ping メッセージを送信する時間間隔
  • デフォルト値: "10s"
  • 最小値: "1s"

grpc-keepalive-timeout

  • gRPC ストリームのタイムアウトを無効にします
  • デフォルト値: "3s"
  • 最小値: "1s"

concurrent-send-snap-limit

  • 同時に送信されるスナップショットの最大数
  • デフォルト値: 32
  • 最小値: 1

concurrent-recv-snap-limit

  • 同時に受信するスナップショットの最大数
  • デフォルト値: 32
  • 最小値: 1

end-point-recursion-limit

  • TiKV がコプロセッサーDAG 式をデコードするときに許可される再帰レベルの最大数
  • デフォルト値: 1000
  • 最小値: 1

end-point-request-max-handle-duration

  • タスクを処理するための TiDB の TiKV へのプッシュダウン リクエストに許可される最長期間
  • デフォルト値: "60s"
  • 最小値: "1s"

snap-io-max-bytes-per-sec

  • スナップショット処理時の最大許容ディスク帯域幅
  • デフォルト値: "100MB"
  • 単位: KB|MB|GB
  • 最小値: "1KB"

enable-request-batch

  • リクエストをバッチで処理するかどうかを決定します
  • デフォルト値: true

labels

  • { zone = "us-west-1", disk = "ssd" }などのサーバー属性を指定します。
  • デフォルト値: {}

background-thread-count

  • バックグラウンド プールの作業スレッド数。これには、エンドポイント スレッド、 BRスレッド、分割チェック スレッド、リージョンスレッド、および遅延に影響されないタスクのその他のスレッドが含まれます。
  • デフォルト値: CPU コアの数が 16 未満の場合、デフォルト値は2です。それ以外の場合、デフォルト値は3です。

end-point-slow-log-threshold

  • TiDB のプッシュダウン リクエストが低速ログを出力するまでの時間のしきい値。処理時間がこの閾値よりも長い場合、スローログが出力されます。
  • デフォルト値: "1s"
  • 最小値: 0

raft-client-queue-size

  • TiKV のRaftメッセージのキュー サイズを指定します。時間内に送信されなかったメッセージが多すぎてバッファがいっぱいになったり、メッセージが破棄されたりする場合は、より大きな値を指定してシステムの安定性を向上させることができます。
  • デフォルト値: 8192

simplify-metrics v6.2.0 の新機能

  • 返された監視メトリックを簡素化するかどうかを指定します。値をtrueに設定すると、TiKV は一部のメトリックをフィルターで除外することにより、各リクエストに対して返されるデータの量を減らします。
  • デフォルト値: false

forward-max-connections-per-address v5.0.0 の新機能

  • サービスおよびサーバーへのリクエストの転送用の接続プールのサイズを設定します。設定する値が小さすぎると、リクエストのレイテンシーと負荷分散に影響します。
  • デフォルト値: 4

読み取りプール.統合

読み取りリクエストを処理する単一スレッド プールに関連するコンフィグレーションアイテム。このスレッド プールは、バージョン 4.0 以降、元のstorageスレッド プールおよびコプロセッサ スレッド プールに取って代わります。

min-thread-count

  • 統合読み取りプールの最小作業スレッド数
  • デフォルト値: 1

max-thread-count

  • 統合読み取りプールまたは UnifyReadPool スレッド プールの最大作業スレッド数。このスレッド プールのサイズを変更する場合は、 TiKV スレッド プールのパフォーマンス チューニングを参照してください。
  • 値の範囲: [min-thread-count, MAX(4, CPU quota * 10)] 。 MAX(4, CPU quota * 10) 4とCPU quota * 10のうち大きい方の値を取得します。
  • デフォルト値: MAX(4、CPU * 0.8)

注記：

スレッド数を増やすとコンテキストの切り替えが多くなり、パフォーマンスが低下する可能性があります。この構成項目の値を変更することはお勧めできません。

stack-size

  • 統合スレッド プール内のスレッドのスタック サイズ
  • タイプ: 整数 + 単位
  • デフォルト値: "10MB"
  • 単位: KB|MB|GB
  • 最小値: "2MB"
  • 最大値：システム内でulimit -sHコマンドを実行した結果出力されるKバイト数。

max-tasks-per-worker

  • 統合読み取りプール内の単一スレッドに許可されるタスクの最大数。値を超えた場合はServer Is Busyを返します。
  • デフォルト値: 2000
  • 最小値: 2

auto-adjust-pool-size v6.3.0 の新機能

  • スレッド プール サイズを自動的に調整するかどうかを制御します。有効にすると、現在の CPU 使用率に基づいて UnifyReadPool スレッド プール サイズを自動的に調整することで、TiKV の読み取りパフォーマンスが最適化されます。スレッド プールの可能な範囲は[max-thread-count, MAX(4, CPU)]です。最大値はmax-thread-countと同じです。
  • デフォルト値: false

リードプール。storage

storageスレッドプールに関連するコンフィグレーション項目。

use-unified-pool

  • storage要求に統合スレッド プール ( readpool.unifiedで構成) を使用するかどうかを決定します。このパラメータの値がfalseの場合、別のスレッド プールが使用されます。これは、このセクション ( readpool.storage ) の残りのパラメータを通じて構成されます。
  • デフォルト値: このセクション ( readpool.storage ) に他の構成がない場合、デフォルト値はtrueです。それ以外の場合、下位互換性のために、デフォルト値はfalseです。このオプションを有効にする前に、必要に応じてreadpool.unifiedの構成を変更してください。

high-concurrency

  • 高優先度readリクエストを処理する同時スレッドの許容数
  • 8 ≤ cpu num ≤ 16の場合、デフォルト値はcpu_num * 0.5です。 cpu numが8より小さい場合、デフォルト値は4です。 cpu numが16より大きい場合、デフォルト値は8です。
  • 最小値: 1

normal-concurrency

  • 通常優先度readリクエストを処理する同時スレッドの許容数
  • 8 ≤ cpu num ≤ 16の場合、デフォルト値はcpu_num * 0.5です。 cpu numが8より小さい場合、デフォルト値は4です。 cpu numが16より大きい場合、デフォルト値は8です。
  • 最小値: 1

low-concurrency

  • 優先度の低いreadリクエストを処理する同時スレッドの許容数
  • 8 ≤ cpu num ≤ 16の場合、デフォルト値はcpu_num * 0.5です。 cpu numが8より小さい場合、デフォルト値は4です。 cpu numが16より大きい場合、デフォルト値は8です。
  • 最小値: 1

max-tasks-per-worker-high

  • 高優先度のスレッド プール内の単一スレッドに許可されるタスクの最大数。値を超えた場合はServer Is Busyを返します。
  • デフォルト値: 2000
  • 最小値: 2

max-tasks-per-worker-normal

  • 通常優先度のスレッド プール内の 1 つのスレッドに許可されるタスクの最大数。値を超えた場合はServer Is Busyを返します。
  • デフォルト値: 2000
  • 最小値: 2

max-tasks-per-worker-low

  • 低優先度のスレッド プール内の単一スレッドに許可されるタスクの最大数。値を超えた場合はServer Is Busyを返します。
  • デフォルト値: 2000
  • 最小値: 2

stack-size

  • ストレージ読み取りスレッド プール内のスレッドのスタック サイズ
  • タイプ: 整数 + 単位
  • デフォルト値: "10MB"
  • 単位: KB|MB|GB
  • 最小値: "2MB"
  • 最大値：システム内でulimit -sHコマンドを実行した結果出力されるKバイト数。

readpool.coprocessor

コプロセッサースレッドプールに関連するコンフィグレーション項目。

use-unified-pool

  • コプロセッサ要求に統合スレッド プール ( readpool.unifiedで構成) を使用するかどうかを決定します。このパラメータの値がfalseの場合、別のスレッド プールが使用されます。これは、このセクション ( readpool.coprocessor ) の残りのパラメータを通じて構成されます。
  • デフォルト値: このセクション ( readpool.coprocessor ) のパラメータが何も設定されていない場合、デフォルト値はtrueです。それ以外の場合、下位互換性のためにデフォルト値はfalseです。このパラメータを有効にする前に、 readpool.unifiedの設定項目を調整してください。

high-concurrency

  • チェックポイントなどの優先度の高いコプロセッサー要求を処理する同時スレッドの許容数
  • デフォルト値: CPU * 0.8
  • 最小値: 1

normal-concurrency

  • 通常優先度のコプロセッサー要求を処理する同時スレッドの許容数
  • デフォルト値: CPU * 0.8
  • 最小値: 1

low-concurrency

  • テーブル スキャンなど、優先度の低いコプロセッサー要求を処理する同時スレッドの許容数
  • デフォルト値: CPU * 0.8
  • 最小値: 1

max-tasks-per-worker-high

  • 高優先度のスレッド プール内の単一スレッドに許可されるタスクの数。この数を超えるとServer Is Busyが返されます。
  • デフォルト値: 2000
  • 最小値: 2

max-tasks-per-worker-normal

  • 通常優先度のスレッド プール内の 1 つのスレッドに許可されるタスクの数。この数を超えるとServer Is Busyが返されます。
  • デフォルト値: 2000
  • 最小値: 2

max-tasks-per-worker-low

  • 低優先度のスレッド プール内の単一スレッドに許可されるタスクの数。この数を超えるとServer Is Busyが返されます。
  • デフォルト値: 2000
  • 最小値: 2

stack-size

  • コプロセッサースレッドプール内のスレッドのスタックサイズ
  • タイプ: 整数 + 単位
  • デフォルト値: "10MB"
  • 単位: KB|MB|GB
  • 最小値: "2MB"
  • 最大値：システム内でulimit -sHコマンドを実行した結果出力されるKバイト数。

storage

storageに関するコンフィグレーション項目。

data-dir

  • RocksDB ディレクトリのstorageパス
  • デフォルト値: "./"

engine v6.6.0 の新機能

  • エンジンの種類を指定します。この構成は、新しいクラスターの作成時にのみ指定でき、一度指定すると変更できません。

  • デフォルト値: "raft-kv"

  • 値のオプション:

    • "raft-kv" : TiDB v6.6.0 より前のバージョンのデフォルトのエンジン タイプ。
    • "partitioned-raft-kv" : TiDB v6.6.0 で導入された新しいstorageエンジン タイプ。

scheduler-concurrency

  • キーの同時操作を防止するメモリロック機構を内蔵しています。各キーは異なるスロットにハッシュを持ちます。
  • デフォルト値: 524288
  • 最小値: 1

scheduler-worker-pool-size

  • スケジューラのスレッド プール内のスレッドの数。スケジューラ スレッドは主に、データの書き込み前にトランザクションの整合性をチェックするために使用されます。 CPU コアの数が16以上の場合、デフォルト値は8です。それ以外の場合、デフォルト値は4です。スケジューラのスレッドプールのサイズを変更する場合は、 TiKV スレッド プールのパフォーマンス チューニングを参照してください。
  • デフォルト値: 4
  • 値の範囲: [1, MAX(4, CPU)] 。 MAX(4, CPU)のCPU CPU コアの数を意味します。 MAX(4, CPU) 4とCPUのうち大きい方の値を取得します。

scheduler-pending-write-threshold

  • 書き込みキューの最大サイズ。この値を超えると、TiKV への新規書き込みに対してServer Is Busyエラーが返されます。
  • デフォルト値: "100MB"
  • 単位: MB|GB

enable-async-apply-prewrite

  • 事前書き込みリクエストを適用する前に、非同期コミット トランザクションが TiKV クライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用期間が長い場合にレイテンシーを簡単に削減でき、適用期間が安定していない場合に遅延ジッターを削減できます。
  • デフォルト値: false

reserve-space

  • TiKV が開始されると、ディスク保護としてディスク上に一部のスペースが予約されます。残りのディスク容量が予約容量より少ない場合、TiKV は一部の書き込み操作を制限します。予約領域は 2 つの部分に分かれており、予約領域の 80% はディスク領域が不足した場合の運用に必要な追加ディスク領域として使用され、残りの 20% は一時ファイルの保存に使用されます。スペースを再利用するプロセスで、余分なディスクスペースを使用しすぎてstorageが使い果たされた場合、この一時ファイルはサービスを復元するための最後の保護として機能します。
  • 一時ファイルの名前はspace_placeholder_fileで、 storage.data-dirディレクトリにあります。ディスク領域が不足して TiKV がオフラインになった場合、TiKV を再起動すると、一時ファイルは自動的に削除され、TiKV は領域を再利用しようとします。
  • 残りの容量が不足している場合、TiKV は一時ファイルを作成しません。保護の有効性は、予約されたスペースのサイズに関係します。予約領域のサイズは、ディスク容量の 5% とこの設定値の間の大きい方の値になります。この構成項目の値が"0MB"の場合、TiKV はこのディスク保護機能を無効にします。
  • デフォルト値: "5GB"
  • 単位: MB|GB

enable-ttl

  • TTL は「生存時間」の略です。この項目を有効にすると、TiKV は TTL に達したデータを自動的に削除します。 TTL の値を設定するには、クライアント経由でデータを書き込むときにリクエストで TTL 値を指定する必要があります。 TTL が指定されていない場合は、TiKV が対応するデータを自動的に削除しないことを意味します。
  • デフォルト値: false

ttl-check-poll-interval

  • 物理スペースを再利用するためにデータをチェックする間隔。データが TTL に達すると、TiKV はチェック中に物理スペースを強制的に再利用します。
  • デフォルト値: "12h"
  • 最小値: "0s"

background-error-recovery-window v6.1.0 の新機能

  • RocksDB が回復可能なバックグラウンド エラーを検出した後、TiKV が回復するまでの最大許容時間。一部のバックグラウンド SST ファイルが破損した場合、RocksDB は破損した SST ファイルが属するピアを特定した後、ハートビート経由で PD に報告します。次に、PD はスケジューリング操作を実行して、このピアを削除します。最後に、破損した SST ファイルは直接削除され、TiKV バックグラウンドは再び通常どおりに動作するようになります。
  • 破損した SST ファイルは、回復が完了する前にまだ存在します。この期間中、RocksDB はデータの書き込みを続行できますが、データの破損した部分が読み取られるとエラーが報告されます。
  • この時間枠内にリカバリが完了しない場合、TiKV はpanicになります。
  • デフォルト値: 1h

api-version v6.1.0 の新機能

  • TiKV が RawKV ストアとして機能するときに TiKV によって使用されるstorage形式とインターフェイスのバージョン。
  • 値のオプション:
    • 1 : API V1を使用し、クライアントから渡されたデータをエンコードせず、そのままのデータを格納します。 v6.1.0 より前のバージョンでは、TiKV はデフォルトで API V1 を使用します。
    • 2 : API V2 を使用します:
      • データはマルチバージョン同時実行制御 (MVCC) 形式で保存され、タイムスタンプは tikv-server によって PD (TSO) から取得されます。
      • データはさまざまな用途に応じてスコープ設定され、API V2 は単一クラスター内での TiDB、トランザクション KV、および RawKV アプリケーションの共存をサポートします。
      • API V2 を使用する場合は、同時にstorage.enable-ttl = trueを設定する必要があります。 API V2 は TTL 機能をサポートしているため、 enable-ttl明示的にオンにする必要があります。そうしないと、 storage.enable-ttlのデフォルトがfalseになるため、競合します。
      • API V2 が有効になっている場合、古いデータを再利用するには、少なくとも 1 つの tidb-server インスタンスをデプロイする必要があります。この tidb-server インスタンスは、読み取りサービスと書き込みサービスを同時に提供できます。高可用性を確保するために、複数の tidb-server インスタンスをデプロイできます。
      • API V2 にはクライアントのサポートが必要です。詳細については、API V2 のクライアントの対応する命令を参照してください。
      • v6.2.0 以降、RawKV の変更データ キャプチャ (CDC) がサポートされています。 RawKV CDCを参照してください。
  • デフォルト値: 1
  • API V1 と API V2 はstorage形式が異なります。 TiKV に TiDB データのみが含まれている場合にのみ、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 RawKV のバックアップと復元使用してデータを移行する必要があります。
  • API V2 を有効にした後は、TiKV クラスターを v6.1.0 より前のバージョンにダウングレードすることはできません。そうしないと、データが破損する可能性があります。

storageのブロックキャッシュ

複数の RocksDB カラム Families (CF) 間でのブロックキャッシュの共有に関連するコンフィグレーションアイテム。

capacity

  • 共有ブロックキャッシュのサイズ。
  • デフォルト値: 総システムメモリサイズの 45%
  • 単位: KB|MB|GB

storageとフロー制御

TiKVのフロー制御機構に関するコンフィグレーション項目。このメカニズムは、RocksDB の書き込み停止メカニズムを置き換え、スケジューラーレイヤーでフローを制御します。これにより、スタックしたRaftstoreまたはアプライ スレッドによって引き起こされる二次災害が回避されます。

enable

  • フロー制御メカニズムを有効にするかどうかを決定します。 TiKV を有効にすると、KvDB の書き込み停止メカニズムと RaftDB の書き込み停止メカニズム (memtable を除く) が自動的に無効になります。
  • デフォルト値: true

memtables-threshold

  • kvDB memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作し始めます。 enableがtrueに設定されている場合、この構成項目はrocksdb.(defaultcf|writecf|lockcf).max-write-buffer-numberをオーバーライドします。
  • デフォルト値: 5

l0-files-threshold

  • kvDB L0 ファイルの数がこのしきい値に達すると、フロー制御メカニズムが動作し始めます。 enableがtrueに設定されている場合、この構成項目はrocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-triggerをオーバーライドします。
  • デフォルト値: 20

soft-pending-compaction-bytes-limit

  • KvDB 内の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムが一部の書き込みリクエストの拒否を開始し、 ServerIsBusyエラーを報告します。 enableがtrueに設定されている場合、この構成項目はrocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limitをオーバーライドします。
  • デフォルト値: "192GB"

hard-pending-compaction-bytes-limit

  • KvDB 内の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 ServerIsBusyエラーを報告します。 enableがtrueに設定されている場合、この構成項目はrocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limitをオーバーライドします。
  • デフォルト値: "1024GB"

storageの.io-rate-limit

I/Oレートリミッタに関するコンフィグレーション項目。

max-bytes-per-sec

  • サーバーが1 秒間にディスクに書き込みまたはディスクから読み取ることができる最大 I/O バイト (以下のmodeの構成項目によって決定) を制限します。この制限に達すると、TiKV はフォアグラウンド操作よりもバックグラウンド操作のスロットリングを優先します。この構成項目の値は、ディスクの最適な I/O 帯域幅 (たとえば、クラウド ディスク ベンダーによって指定された最大 I/O 帯域幅) に設定する必要があります。この構成値をゼロに設定すると、ディスク I/O 操作は制限されません。
  • デフォルト値: "0MB"

mode

  • どのタイプの I/O 操作をカウントし、しきい値max-bytes-per-sec未満に制限するかを決定します。現在、書き込み専用モードのみがサポートされています。
  • 値のオプション: "read-only" 、 "write-only" 、および"all-io"
  • デフォルト値: "write-only"

PD

endpoints

  • PD のエンドポイント。複数のエンドポイントを指定する場合は、カンマで区切る必要があります。
  • デフォルト値: ["127.0.0.1:2379"]

retry-interval

  • PD接続の初期化をリトライする間隔
  • デフォルト値: "300ms"

retry-log-every

  • PD クライアントがエラーを観察したときに、エラーの報告をスキップする頻度を指定します。たとえば、値が5の場合、PD クライアントはエラーを観察した後、4 回ごとにエラーの報告をスキップし、5 回ごとにエラーを報告します。
  • この機能を無効にするには、値を1に設定します。
  • デフォルト値: 10

retry-max-count

  • PD接続の初期化をリトライする最大回数
  • 再試行を無効にするには、その値を0に設定します。再試行回数の制限を解除するには、値を-1に設定します。
  • デフォルト値: -1

ラフトストア

Raftstoreに関連するコンフィグレーション項目。

prevote

  • prevoteを有効または無効にします。この機能を有効にすると、ネットワーク分割から回復した後のシステムのジッターを軽減できます。
  • デフォルト値: true

capacity

  • storage容量。データを保存できる最大サイズです。 capacityを指定しない場合は、現在のディスクの容量が優先されます。複数の TiKV インスタンスを同じ物理ディスクにデプロイするには、このパラメータを TiKV 構成に追加します。詳細はハイブリッド展開の主要なパラメータを参照してください。
  • デフォルト値: 0
  • 単位: KB|MB|GB

raftdb-path

  • Raftライブラリへのパス (デフォルトではstorage.data-dir/raft
  • デフォルト値: ""

raft-base-tick-interval

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • Raftステート マシンが動作する時間間隔
  • デフォルト値: "1s"
  • 最小値: 0より大きい

raft-heartbeat-ticks

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • ハートビートの送信時に通過したティック数。これは、ハートビートがraft-base-tick-interval * raft-heartbeat-ticksの時間間隔で送信されることを意味します。
  • デフォルト値: 2
  • 最小値: 0より大きい

raft-election-timeout-ticks

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • Raft の選択が開始されたときに渡されたティックの数。これは、 Raftグループにリーダーがいない場合、約raft-base-tick-interval * raft-election-timeout-ticksの時間間隔の後にリーダーの選挙が開始されることを意味します。
  • デフォルト値: 10
  • 最小値: raft-heartbeat-ticks

raft-min-election-timeout-ticks

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • Raft選挙が開始される間の最小ティック数。数値が0の場合、値raft-election-timeout-ticksが使用されます。このパラメータの値はraft-election-timeout-ticks以上である必要があります。
  • デフォルト値: 0
  • 最小値: 0

raft-max-election-timeout-ticks

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • Raft選挙が開始される最大ティック数。数値が0の場合、 raft-election-timeout-ticks * 2の値が使用されます。
  • デフォルト値: 0
  • 最小値: 0

raft-max-size-per-msg

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • 単一メッセージ パケットのサイズに対するソフト制限
  • デフォルト値: "1MB"
  • 最小値: 0より大きい
  • 最大値： 3GB
  • 単位: KB|MB|GB

raft-max-inflight-msgs

注記：

この構成項目は SQL ステートメントを介してクエリすることはできませんが、構成ファイルで構成することができます。

  • 確認するRaft丸太の数。この数値を超えると、 Raftステート マシンのログ送信が遅くなります。
  • デフォルト値: 256
  • 最小値: 0より大きい
  • 最大値： 16384

raft-entry-max-size

  • 単一ログの最大サイズのハード制限
  • デフォルト値: "8MB"
  • 最小値: 0
  • 単位: MB|GB

raft-log-compact-sync-interval v5.3 の新機能

  • 不要なRaftログを圧縮する時間間隔
  • デフォルト値: "2s"
  • 最小値: "0s"

raft-log-gc-tick-interval

  • Raftログを削除するポーリング タスクがスケジュールされる時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "3s"
  • 最小値: "0s"

raft-log-gc-threshold

  • Raftの残存丸太の最大許容数のソフトリミット
  • デフォルト値: 50
  • 最小値: 1

raft-log-gc-count-limit

  • Raftの残存丸太の許容数のハードリミット
  • デフォルト値: 3/4リージョンサイズに収容できるログ数 (各ログあたり 1MB として計算)
  • 最小値: 0

raft-log-gc-size-limit

  • Raft の残存丸太の許容サイズに対する厳しい制限
  • デフォルト値:リージョンサイズの 3/4
  • 最小値: 0より大きい

raft-log-reserve-max-ticks v5.3 の新機能

  • この構成項目で設定されたティック数が経過した後、残りのRaftログの数がraft-log-gc-thresholdで設定された値に達していない場合でも、TiKV はこれらのログに対してガベージコレクション(GC) を実行します。
  • デフォルト値: 6
  • 最小値: 0より大きい

raft-engine-purge-interval

  • ディスク領域をできるだけ早くリサイクルするために、古い TiKV ログ ファイルをパージする間隔。 Raftエンジンは交換可能なコンポーネントであるため、実装によってはパージ プロセスが必要です。
  • デフォルト値: "10s"

raft-entry-cache-life-time

  • メモリ内のログ キャッシュに許可される最大残り時間
  • デフォルト値: "30s"
  • 最小値: 0

hibernate-regions

  • Hibernateリージョンを有効または無効にします。このオプションを有効にすると、長時間アイドル状態のリージョンは自動的に休止状態に設定されます。これにより、アイドル状態のリージョンのRaftリーダーとフォロワーの間のハートビートメッセージによって生じる余分なオーバーヘッドが削減されます。 peer-stale-state-check-intervalを使用すると、休止状態のリージョンのリーダーとフォロワー間のハートビート間隔を変更できます。
  • デフォルト値: v5.0.2 以降のバージョンではtrue 。 v5.0.2 より前のバージョンではfalse

split-region-check-tick-interval

  • リージョン分割が必要かどうかを確認する間隔を指定します。 0 、この機能が無効であることを意味します。
  • デフォルト値: "10s"
  • 最小値: 0

region-split-check-diff

  • リージョン分割前にリージョンデータが超えることが許可される最大値
  • デフォルト値:リージョンサイズの 1/16。
  • 最小値: 0

region-compact-check-interval

  • RocksDB の圧縮を手動でトリガーする必要があるかどうかを確認する時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "5m"
  • 最小値: 0

region-compact-check-step

  • 手動圧縮の各ラウンドで一度にチェックされるリージョンの数

  • デフォルト値:

    • storage.engine="raft-kv"の場合、デフォルト値は100です。
    • storage.engine="partitioned-raft-kv"の場合、デフォルト値は5です。

  • 最小値: 0

region-compact-min-tombstones

  • RocksDB の圧縮をトリガーするために必要なトゥームストーンの数
  • デフォルト値: 10000
  • 最小値: 0

region-compact-tombstones-percent

  • RocksDB の圧縮をトリガーするために必要なトゥームストーンの割合
  • デフォルト値: 30
  • 最小値: 1
  • 最大値： 100

region-compact-min-redundant-rows v7.1.0 の新機能

  • RocksDB 圧縮をトリガーするために必要な冗長 MVCC 行の数。この設定は、Partitioned Raft KV ( storage.engine="partitioned-raft-kv" ) に対してのみ有効です。
  • デフォルト値: 50000
  • 最小値: 0

region-compact-redundant-rows-percent v7.1.0 の新機能

  • RocksDB 圧縮をトリガーするために必要な冗長 MVCC 行の割合。この設定は、Partitioned Raft KV ( storage.engine="partitioned-raft-kv" ) に対してのみ有効です。
  • デフォルト値: 20
  • 最小値: 1
  • 最大値： 100

report-region-buckets-tick-interval v6.1.0 の新機能

  • enable-region-bucketが true の場合、TiKV がバケット情報を PD に報告する間隔。
  • デフォルト値: 10s

pd-heartbeat-tick-interval

  • リージョンの PD へのハートビートがトリガーされる時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "1m"
  • 最小値: 0

pd-store-heartbeat-tick-interval

  • ストアの PD へのハートビートがトリガーされる時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "10s"
  • 最小値: 0

snap-mgr-gc-tick-interval

  • 期限切れのスナップショット ファイルのリサイクルがトリガーされる時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "1m"
  • 最小値: 0

snap-gc-timeout

  • スナップショット ファイルが保存される最長時間
  • デフォルト値: "4h"
  • 最小値: 0

snap-generator-pool-size v5.4.0 の新機能

  • snap-generatorスレッド プールのサイズを設定します。
  • リカバリ シナリオで TiKV でリージョンがスナップショットをより速く生成できるようにするには、対応するワーカーのsnap-generatorスレッドの数を増やす必要があります。この構成アイテムを使用して、 snap-generatorスレッド プールのサイズを増やすことができます。
  • デフォルト値: 2
  • 最小値: 1

lock-cf-compact-interval

  • TiKV がロックカラムファミリーの手動圧縮をトリガーする時間間隔
  • デフォルト値: "10m"
  • 最小値: 0

lock-cf-compact-bytes-threshold

  • TiKV がロックカラムファミリーの手動圧縮をトリガーするサイズ
  • デフォルト値: "256MB"
  • 最小値: 0
  • 単位：MB

notify-capacity

  • リージョンメッセージキューの最長の長さ。
  • デフォルト値: 40960
  • 最小値: 0

messages-per-tick

  • バッチごとに処理されるメッセージの最大数
  • デフォルト値: 4096
  • 最小値: 0

max-peer-down-duration

  • ピアに許可される非アクティブ期間の最長。タイムアウトのあるピアはdownとしてマークされ、PD は後でそのピアを削除しようとします。
  • デフォルト値: "10m"
  • 最小値: ハイバネートリージョンが有効な場合、最小値はpeer-stale-state-check-interval * 2です。 Hibernateリージョンが無効な場合、最小値は0です。

max-leader-missing-duration

  • Raftグループにリーダーがいない状態にピアが存在できる最長期間。この値を超えると、ピアは PD でピアが削除されたかどうかを確認します。
  • デフォルト値: "2h"
  • 最小値: abnormal-leader-missing-durationより大きい

abnormal-leader-missing-duration

  • Raftグループにリーダーがいない状態にピアが存在できる最長期間。この値を超えると、ピアは異常とみなされ、メトリクスとログにマークが付けられます。
  • デフォルト値: "10m"
  • 最小値: peer-stale-state-check-intervalより大きい

peer-stale-state-check-interval

  • Raftグループにリーダーがいない状態にピアがあるかどうかのチェックをトリガーする時間間隔。
  • デフォルト値: "5m"
  • 最小値: 2 * election-timeoutより大きい

leader-transfer-max-log-lag

  • Raftリーダーの転送中に転送先に許可される欠落ログの最大数
  • デフォルト値: 128
  • 最小値: 10

max-snapshot-file-raw-size v6.1.0 の新機能

  • スナップショット ファイルのサイズがこの設定値を超えると、このファイルは複数のファイルに分割されます。
  • デフォルト値: 100MiB
  • 最小値: 100MiB

snap-apply-batch-size

  • インポートされたスナップショット ファイルをディスクに書き込むときに必要なメモリキャッシュ サイズ
  • デフォルト値: "10MB"
  • 最小値: 0
  • 単位：MB

consistency-check-interval

  • 整合性チェックがトリガーされる時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "0s"
  • 最小値: 0

raft-store-max-leader-lease

  • Raftのリーダーとして最も長く信頼されていた期間
  • デフォルト値: "9s"
  • 最小値: 0

right-derive-when-split

  • リージョン分割時の新しいリージョンの開始キーを指定します。この設定項目がtrueに設定されている場合、開始キーは最大の分割キーになります。この設定項目がfalseに設定されている場合、開始キーは元のリージョンの開始キーになります。
  • デフォルト値: true

merge-max-log-gap

  • mergeを実行した場合に許容される欠落ログの最大数
  • デフォルト値: 10
  • 最小値: raft-log-gc-count-limitより大きい

merge-check-tick-interval

  • TiKV がリージョンをマージする必要があるかどうかをチェックする時間間隔
  • デフォルト値: "2s"
  • 最小値: 0より大きい

use-delete-range

  • rocksdb delete_rangeインターフェイスからデータを削除するかどうかを決定します
  • デフォルト値: false

cleanup-import-sst-interval

  • 期限切れの SST ファイルをチェックする時間間隔。 0 、この機能が無効であることを意味します。
  • デフォルト値: "10m"
  • 最小値: 0

local-read-batch-size

  • 1 回のバッチで処理される読み取りリクエストの最大数
  • デフォルト値: 1024
  • 最小値: 0より大きい

apply-yield-write-size v6.4.0 の新機能

  • 適用スレッドがポーリングの 1 ラウンドで 1 つの FSM (有限状態マシン) に対して書き込むことができる最大バイト数。これはソフトリミットです。
  • デフォルト値: "32KiB"
  • 最小値: 0より大きい
  • 単位: KiB|MiB|GiB

apply-max-batch-size

  • Raftステート マシンは、BatchSystem によってデータ書き込みリクエストをバッチで処理します。この設定項目は、1 つのバッチでリクエストを処理できるRaftステート マシンの最大数を指定します。
  • デフォルト値: 256
  • 最小値: 0より大きい
  • 最大値： 10240

apply-pool-size

  • データをディスクにフラッシュするプール内のスレッドの許容数。これは、適用スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 TiKV スレッド プールのパフォーマンス チューニングを参照してください。
  • デフォルト値: 2
  • 値の範囲: [1, CPU * 10] 。 CPU CPU コアの数を意味します。

store-max-batch-size

  • Raftステート マシンは、BatchSystem によってバッチでディスクにログをフラッシュするリクエストを処理します。この設定項目は、1 つのバッチでリクエストを処理できるRaftステート マシンの最大数を指定します。
  • hibernate-regionsが有効な場合、デフォルト値は256です。 hibernate-regionsが無効になっている場合、デフォルト値は1024です。
  • 最小値: 0より大きい
  • 最大値： 10240

store-pool-size

  • Raftを処理するプール内のスレッドの許容数。これはRaftstoreスレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 TiKV スレッド プールのパフォーマンス チューニングを参照してください。
  • デフォルト値: 2
  • 値の範囲: [1, CPU * 10] 。 CPU CPU コアの数を意味します。

store-io-pool-size v5.3.0 の新機能

future-poll-size

  • futureを駆動するスレッドの許容数
  • デフォルト値: 1
  • 最小値: 0より大きい

cmd-batch

  • リクエストのバッチ処理を有効にするかどうかを制御します。これを有効にすると、書き込みパフォーマンスが大幅に向上します。
  • デフォルト値: true

inspect-interval

  • TiKV は、特定の間隔でRaftstoreコンポーネントのレイテンシーを検査します。このパラメータは検査の間隔を指定します。レイテンシーがこの値を超える場合、この検査はタイムアウトとしてマークされます。
  • タイムアウト検査の割合に基づいて、TiKVノードが遅いかどうかを判断します。
  • デフォルト値: "500ms"
  • 最小値: "1ms"

raft-write-size-limit v5.3.0 の新機能

  • Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの設定項目の値より大きい場合、データはディスクに書き込まれます。 store-io-pool-sizeの値が0の場合、この構成項目は有効になりません。
  • デフォルト値: 1MB
  • 最小値: 0

report-min-resolved-ts-interval v6.0.0 の新機能

  • 最小解決タイムスタンプが PD リーダーに報告される間隔を決定します。この値が0に設定されている場合、レポートが無効になっていることを意味します。
  • デフォルト値: v6.3.0 より前のデフォルト値は"0s"です。 v6.3.0 以降、デフォルト値は"1s"で、これは正の最小値です。
  • 最小値: 0
  • 単位：秒

コプロセッサ

コプロセッサーに関するコンフィグレーション項目。

split-region-on-table

  • リージョンをテーブルごとに分割するかどうかを決定します。この機能は TiDB モードでのみ使用することをお勧めします。
  • デフォルト値: false

batch-split-limit

  • バッチに分割されるリージョンのしきい値。この値を増やすと、リージョン分割が高速化されます。
  • デフォルト値: 10
  • 最小値: 1

region-max-size

  • リージョンの最大サイズ。この値を超えると、リージョンが多数に分割されます。
  • デフォルト値: region-split-size / 2 * 3
  • 単位: KiB|MiB|GiB

region-split-size

  • 新しく分割されたリージョンのサイズ。この値は推定値です。
  • デフォルト値: "96MiB"
  • 単位: KiB|MiB|GiB

region-max-keys

  • リージョン内のキーの最大許容数。この値を超えると、リージョンが多数に分割されます。
  • デフォルト値: region-split-keys / 2 * 3

region-split-keys

  • 新しく分割されたリージョン内のキーの数。この値は推定値です。
  • デフォルト値: 960000

consistency-check-method

  • データの整合性チェックの方法を指定します
  • MVCC データの整合性チェックの場合、値を"mvcc"に設定します。生データの整合性チェックの場合は、値を"raw"に設定します。
  • デフォルト値: "mvcc"

コプロセッサーv2

coprocessor-plugin-directory

  • コンパイルされたコプロセッサ プラグインが配置されるディレクトリのパス。このディレクトリ内のプラグインは、TiKV によって自動的にロードされます。
  • この設定項目が設定されていない場合、コプロセッサ プラグインは無効になります。
  • デフォルト値: "./coprocessors"

enable-region-bucket v6.1.0 の新機能

  • リージョンをバケットと呼ばれる小さな範囲に分割するかどうかを決定します。バケットは、スキャンの同時実行性を向上させるために同時クエリの単位として使用されます。バケットの設計の詳細については、 動的サイズリージョンを参照してください。
  • デフォルト値: false

region-bucket-size v6.1.0 の新機能

  • enable-region-bucketが true の場合のバケットのサイズ。
  • デフォルト値: 96MiB

ロックスデータベース

RocksDBに関するコンフィグレーション項目

max-background-jobs

  • RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 TiKV スレッド プールのパフォーマンス チューニングを参照してください。
  • デフォルト値:
    • CPU コア数が 10 の場合、デフォルト値は9です。
    • CPU コアの数が 8 の場合、デフォルト値は7です。
    • CPU コア数がNの場合、デフォルト値はmax(2, min(N - 1, 9))です。
  • 最小値: 2

max-background-flushes

  • 同時バックグラウンド memtable フラッシュ ジョブの最大数
  • デフォルト値:
    • CPU コア数が 10 の場合、デフォルト値は3です。
    • CPU コアの数が 8 の場合、デフォルト値は2です。
    • CPU コア数がNの場合、デフォルト値は[(max-background-jobs + 3) / 4]です。
  • 最小値: 1

max-sub-compactions

  • RocksDB で同時に実行されるサブコンパクション操作の数
  • デフォルト値: 3
  • 最小値: 1

max-open-files

  • RocksDB が開くことができるファイルの総数
  • デフォルト値: 40960
  • 最小値: -1

max-manifest-file-size

  • RocksDB マニフェスト ファイルの最大サイズ
  • デフォルト値: "128MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

create-if-missing

  • DBスイッチを自動的に作成するかどうかを決定します。
  • デフォルト値: true

wal-recovery-mode

  • WALリカバリモード
  • オプションの値:
    • "tolerate-corrupted-tail-records" : すべてのログ上で不完全な末尾データを持つレコードを許容し、破棄します。
    • "absolute-consistency" : 破損したログが見つかった場合、回復を中止します。
    • "point-in-time" : 最初の破損したログが見つかるまで、ログを順番に回復します。
    • "skip-any-corrupted-records" : 災害後の回復。データは可能な限り復元され、破損したレコードはスキップされます。
  • デフォルト値: "point-in-time"

wal-dir

  • WALファイルが保存されているディレクトリ
  • デフォルト値: "/tmp/tikv/store"

wal-ttl-seconds

  • アーカイブされた WAL ファイルの生存時間。この値を超えると、システムはこれらのファイルを削除します。
  • デフォルト値: 0
  • 最小値: 0
  • 単位：秒

wal-size-limit

  • アーカイブされた WAL ファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。
  • デフォルト値: 0
  • 最小値: 0
  • 単位: B|KB|MB|GB

max-total-wal-size

  • RocksDB WAL の合計最大サイズ。これは、 data-dirのファイル内の*.logのファイルのサイズです。
  • デフォルト値: "4GB"

stats-dump-period

  • 統計情報がログに出力される間隔。
  • デフォルト値: 10m

compaction-readahead-size

  • RocksDB の圧縮中に先読み機能を有効にし、先読みデータのサイズを指定します。メカニカル ディスクを使用している場合は、値を少なくとも 2MB に設定することをお勧めします。
  • デフォルト値: 0
  • 最小値: 0
  • 単位: B|KB|MB|GB

writable-file-max-buffer-size

  • WritableFileWrite で使用される最大バッファ サイズ
  • デフォルト値: "1MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

use-direct-io-for-flush-and-compaction

  • バックグラウンドのフラッシュと圧縮での読み取りと書き込みの両方にO_DIRECTを使用するかどうかを決定します。このオプションのパフォーマンスへの影響: O_DIRECTバイパスを有効にすると、OS バッファ キャッシュの汚染が防止されますが、後続のファイルの読み取りでは、バッファ キャッシュへの内容の再読み取りが必要になります。
  • デフォルト値: false

rate-bytes-per-sec

  • RocksDB の圧縮レート リミッターによって許可される最大レート
  • デフォルト値: 10GB
  • 最小値: 0
  • 単位: B|KB|MB|GB

rate-limiter-refill-period

  • I/O トークンが補充される頻度を制御します。値を小さくすると、I/O バーストは減少しますが、CPU オーバーヘッドが増加します。
  • デフォルト値: "100ms"

rate-limiter-mode

  • RocksDB の圧縮レート リミッター モード
  • "all-io" "write-only"値: "read-only"
  • デフォルト値: "write-only"

rate-limiter-auto-tuned v5.0 の新機能

  • 最近のワークロードに基づいて RocksDB の圧縮レート リミッターの構成を自動的に最適化するかどうかを決定します。この構成を有効にすると、圧縮保留中のバイト数が通常よりわずかに多くなります。
  • デフォルト値: true

enable-pipelined-write

  • パイプライン書き込みを有効にするかどうかを制御します。この構成が有効な場合、以前のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプライン コミット メカニズムが使用されます。
  • デフォルト値: false

bytes-per-sync

  • ファイルが非同期で書き込まれている間に、OS がファイルをディスクに増分同期する速度。
  • デフォルト値: "1MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

wal-bytes-per-sync

  • WAL ファイルの書き込み中に OS が WAL ファイルをディスクに増分同期する速度
  • デフォルト値: "512KB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

info-log-max-size

  • 情報ログの最大サイズ
  • デフォルト値: "1GB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

info-log-roll-time

  • 情報ログが切り詰められる時間間隔。値が0sの場合、ログは切り捨てられません。
  • デフォルト値: "0s"

info-log-keep-log-file-num

  • 保存されるログ ファイルの最大数
  • デフォルト値: 10
  • 最小値: 0

info-log-dir

  • ログが保存されるディレクトリ
  • デフォルト値: ""

info-log-level

  • RocksDB のログレベル
  • デフォルト値: "info"

write-buffer-flush-oldest-first v6.6.0 の新機能

  • 現在の RocksDB のmemtableのメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。

  • デフォルト値: false

  • 値のオプション:

    • データ量が最も大きいfalse : memtableが SST ファイルにフラッシュされます。
    • true : 最も古いmemtable SST ファイルにフラッシュされます。この戦略はコールド データのmemtableクリアできるため、コールド データとホット データが明らかなシナリオに適しています。

write-buffer-limit v6.6.0 の新機能

  • 単一の TiKV 内のすべての RocksDB インスタンスの合計メモリ制限をmemtableに指定します。デフォルト値はマシンのメモリの 25% です。少なくとも 5 GiB のメモリを構成することをお勧めします。この設定は、Partitioned Raft KV ( storage.engine = "partitioned-raft-kv" ) に対してのみ有効です。
  • デフォルト値: 25%
  • 単位: KiB|MiB|GiB

ロックスデータベースタイタン

タイタン関連のコンフィグレーション項目。

enabled

  • Titan を有効または無効にします
  • デフォルト値: false

dirname

  • Titan Blob ファイルが保存されているディレクトリ
  • デフォルト値: "titandb"

disable-gc

  • Titan が Blob ファイルに対して実行するガベージ コレクション (GC) を無効にするかどうかを決定します
  • デフォルト値: false

max-background-gc

  • Titan の GC スレッドの最大数
  • デフォルト値: 4
  • 最小値: 1

ロックスデータベース.defaultcf |ロックスデータベースロックスデータベース.lockcf

rocksdb.defaultcf 、 rocksdb.writecf 、 rocksdb.lockcfに関するコンフィグレーション項目。

block-size

  • RocksDB ブロックのデフォルトのサイズ
  • defaultcfとwritecfのデフォルト値: "32KB"
  • lockcfのデフォルト値: "16KB"
  • 最小値: "1KB"
  • 単位: KB|MB|GB

block-cache-size

  • RocksDB ブロックのキャッシュ サイズ。
  • defaultcfのデフォルト値: Total machine memory * 25%
  • writecfのデフォルト値: Total machine memory * 15%
  • lockcfのデフォルト値: Total machine memory * 2%
  • 最小値: 0
  • 単位: KB|MB|GB

disable-block-cache

  • ブロックキャッシュを有効または無効にします
  • デフォルト値: false

cache-index-and-filter-blocks

  • キャッシュインデックスとフィルターを有効または無効にします。
  • デフォルト値: true

pin-l0-filter-and-index-blocks

  • レベル 0 SST ファイルのインデックス ブロックとフィルター ブロックをメモリに固定するかどうかを決定します。
  • デフォルト値: true

use-bloom-filter

  • ブルームフィルターを有効または無効にします
  • デフォルト値: true

optimize-filters-for-hits

  • フィルターのヒット率を最適化するかどうかを決定します。
  • defaultcfのデフォルト値: true
  • writecfとlockcfのデフォルト値: false

whole-key-filtering

  • キー全体をブルームフィルターに入れるかどうかを決定します
  • defaultcfとlockcfのデフォルト値: true
  • writecfのデフォルト値: false

bloom-filter-bits-per-key

  • ブルームフィルターが各キーに予約する長さ
  • デフォルト値: 10
  • 単位：バイト

block-based-bloom-filter

  • 各ブロックがブルームフィルターを作成するかどうかを決定します
  • デフォルト値: false

read-amp-bytes-per-bit

  • 読み取り増幅の統計を有効または無効にします。
  • オプションの値: 0 (無効)、> 0 (有効)。
  • デフォルト値: 0
  • 最小値: 0

compression-per-level

  • 各レベルのデフォルトの圧縮アルゴリズム
  • defaultcfのデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]
  • writecfのデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]
  • lockcfのデフォルト値: ["いいえ"、"いいえ"、"いいえ"、"いいえ"、"いいえ"、"いいえ"、"いいえ"]

bottommost-level-compression

  • 最レイヤーの圧縮アルゴリズムを設定します。この構成項目はcompression-per-level設定をオーバーライドします。
  • データが LSM ツリーに書き込まれて以来、RocksDB は最レイヤーのcompression-per-level配列で指定された最後の圧縮アルゴリズムを直接採用しません。 bottommost-level-compressionにより、最レイヤーは最初から最適な圧縮効果の圧縮アルゴリズムを使用できるようになります。
  • 最レイヤーの圧縮アルゴリズムを設定したくない場合は、この設定項目の値をdisableに設定します。
  • デフォルト値: "zstd"

write-buffer-size

  • メムテーブルのサイズ
  • defaultcfとwritecfのデフォルト値: "128MB"
  • lockcfのデフォルト値: "32MB"
  • 最小値: 0
  • 単位: KB|MB|GB

max-write-buffer-number

  • memtable の最大数。 storage.flow-control.enableがtrueに設定されている場合、 storage.flow-control.memtables-thresholdこの構成項目をオーバーライドします。
  • デフォルト値: 5
  • 最小値: 0

min-write-buffer-number-to-merge

  • フラッシュをトリガーするために必要な memtable の最小数
  • デフォルト値: 1
  • 最小値: 0

max-bytes-for-level-base

  • 基本レベル (レベル 1) の最大バイト数。通常、memtable の 4 倍のサイズに設定されます。レベル 1 のデータ サイズが制限値max-bytes-for-level-baseに達すると、レベル 1 の SST ファイルと、それらに重複するレベル 2 の SST ファイルが圧縮されます。
  • defaultcfとwritecfのデフォルト値: "512MB"
  • lockcfのデフォルト値: "128MB"
  • 最小値: 0
  • 単位: KB|MB|GB
  • 不必要な圧縮を減らすために、値max-bytes-for-level-baseを L0 のデータ量とほぼ同じに設定することをお勧めします。たとえば、圧縮方法が「no:no:lz4:lz4:lz4:lz4:lz4」の場合、L0 と L1 には圧縮がなく、L0 の圧縮のトリガー条件は次のとおりであるため、 max-bytes-for-level-baseの値はwrite-buffer-size * 4になります。 SST ファイルの数が 4 (デフォルト値) に達していることを確認します。 L0 と L1 の両方で圧縮を採用する場合、memtable から圧縮された SST ファイルのサイズを理解するには、RocksDB ログを分析する必要があります。たとえば、ファイル サイズが 32 MB の場合、 max-bytes-for-level-base ～ 128 MB の値を設定することをお勧めします ( 32 MB * 4 )。

target-file-size-base

  • 基本レベルでのターゲット ファイルのサイズ。 enable-compaction-guard値がtrueの場合、この値はcompaction-guard-max-output-file-sizeで上書きされます。
  • デフォルト値: "8MB"
  • 最小値: 0
  • 単位: KB|MB|GB

level0-file-num-compaction-trigger

  • 圧縮をトリガーする L0 のファイルの最大数
  • defaultcfとwritecfのデフォルト値: 4
  • lockcfのデフォルト値: 1
  • 最小値: 0

level0-slowdown-writes-trigger

  • 書き込み停止をトリガーする L0 のファイルの最大数。 storage.flow-control.enableがtrueに設定されている場合、 storage.flow-control.l0-files-thresholdこの構成項目をオーバーライドします。
  • デフォルト値: 20
  • 最小値: 0

level0-stop-writes-trigger

  • 書き込みを完全にブロックするために必要な L0 のファイルの最大数
  • デフォルト値: 36
  • 最小値: 0

max-compaction-bytes

  • 圧縮ごとにディスクに書き込まれる最大バイト数
  • デフォルト値: "2GB"
  • 最小値: 0
  • 単位: KB|MB|GB

compaction-pri

  • 圧縮の優先タイプ
  • オプションの値:
    • "by-compensated-size" : ファイル サイズの順にファイルを圧縮し、大きなファイルを優先して圧縮します。
    • "oldest-largest-seq-first" : 更新時刻が最も古いファイルの圧縮を優先します。この値は、狭い範囲のホット キーを更新する場合にのみ使用してください。
    • "oldest-smallest-seq-first" : 長期間次のレベルに圧縮されない範囲を持つファイルの圧縮を優先します。キー空間全体でホット キーをランダムに更新する場合、この値により書き込み増幅がわずかに減少する可能性があります。
    • "min-overlapping-ratio" : オーバーラップ率が高いファイルの圧縮を優先します。ファイルがさまざまなレベルで小さい場合 ( the file size in the next level ÷ the file size in this levelの結果が小さい場合)、TiKV は最初にこのファイルを圧縮します。多くの場合、この値により書き込み増幅を効果的に削減できます。
  • defaultcfとwritecfのデフォルト値: "min-overlapping-ratio"
  • lockcfのデフォルト値: "by-compensated-size"

dynamic-level-bytes

  • 動的レベルバイトを最適化するかどうかを決定します
  • デフォルト値: true

num-levels

  • RocksDB ファイル内の最大レベル数
  • デフォルト値: 7

max-bytes-for-level-multiplier

  • レイヤーのデフォルトの増幅倍数
  • デフォルト値: 10

compaction-style

  • 圧縮方法
  • "fifo" "universal"値: "level"
  • デフォルト値: "level"

disable-auto-compactions

  • 自動圧縮を無効にするかどうかを決定します。
  • デフォルト値: false

soft-pending-compaction-bytes-limit

  • 保留中の圧縮バイトのソフト制限。 storage.flow-control.enableがtrueに設定されている場合、 storage.flow-control.soft-pending-compaction-bytes-limitこの構成項目をオーバーライドします。
  • デフォルト値: "192GB"
  • 単位: KB|MB|GB

hard-pending-compaction-bytes-limit

  • 保留中の圧縮バイトのハード制限。 storage.flow-control.enableがtrueに設定されている場合、 storage.flow-control.hard-pending-compaction-bytes-limitこの構成項目をオーバーライドします。
  • デフォルト値: "256GB"
  • 単位: KB|MB|GB

enable-compaction-guard

  • TiKVリージョン境界で SST ファイルを分割するための最適化であるコンパクション ガードを有効または無効にします。この最適化により、圧縮 I/O が削減され、TiKV がより大きな SST ファイル サイズを使用できるようになり (したがって、全体の SST ファイルが少なくなります)、リージョンの移行時に古いデータを効率的にクリーンアップできるようになります。
  • defaultcfとwritecfのデフォルト値: true
  • lockcfのデフォルト値: false

compaction-guard-min-output-file-size

  • コンパクション ガードが有効な場合の SST ファイルの最小サイズ。この構成により、コンパクション ガードが有効になっているときに SST ファイルが小さすぎることが防止されます。
  • デフォルト値: "8MB"
  • 単位: KB|MB|GB

compaction-guard-max-output-file-size

  • コンパクション ガードが有効な場合の SST ファイルの最大サイズ。この構成により、コンパクション ガードが有効になっているときに SST ファイルが大きくなりすぎることがなくなります。この構成は、同じカラムファミリーのtarget-file-size-baseをオーバーライドします。
  • デフォルト値: "128MB"
  • 単位: KB|MB|GB

format-version v6.2.0 の新機能

  • SST ファイルのフォーマット バージョン。この構成項目は、新しく書き込まれたテーブルにのみ影響します。既存のテーブルの場合、バージョン情報はフッターから読み取られます。
  • オプションの値:
    • 0 : すべての TiKV バージョンで読み取り可能。デフォルトのチェックサム タイプは CRC32 であり、このバージョンではチェックサム タイプの変更はサポートされていません。
    • 1 : すべての TiKV バージョンで読み取り可能。 xxHash などのデフォルト以外のチェックサム タイプをサポートします。 RocksDB は、チェックサム タイプが CRC32 でない場合にのみデータを書き込みます。 (バージョン0は自動的にアップグレードされます)
    • 2 : すべての TiKV バージョンで読み取り可能。 LZ4、BZip2、Zlib 圧縮を使用して圧縮ブロックのエンコードを変更します。
    • 3 : TiKV v2.1 以降のバージョンで読み込むことができます。インデックス ブロック内のキーのエンコーディングを変更します。
    • 4 : TiKV v3.0 以降のバージョンで読み込むことができます。インデックス ブロック内の値のエンコードを変更します。
    • 5 : TiKV v6.1 以降のバージョンで読み込むことができます。フル フィルターとパーティション フィルターでは、異なるスキーマを使用した、より高速で正確なブルーム フィルター実装が使用されます。
  • デフォルト値: 2

ttl v7.1.2 の新機能

  • TTL より古い更新を含む SST ファイルは、圧縮対象として自動的に選択されます。これらの SST ファイルはカスケード方式で圧縮されるため、最下位のレベルまたはファイルに圧縮されます。
  • デフォルト値: "0s"は、デフォルトでは SST ファイルが選択されていないことを意味します。
  • 単位: s(秒)|h(時)|d(日)

periodic-compaction-seconds v7.1.2 の新機能

  • 定期的な圧縮の時間間隔。この値より古い更新を含む SST ファイルは圧縮対象として選択され、これらの SST ファイルが元々存在していたレベルと同じレベルに再書き込みされます。
    • デフォルト値: "0s"は、定期的な圧縮がデフォルトで無効であることを意味します。
  • 単位: s(秒)|h(時)|d(日)

ロックsdb.defaultcf.titan

rocksdb.defaultcf.titanに関するコンフィグレーション項目。

min-blob-size

  • Blob ファイルに保存される最小値。指定されたサイズより小さい値は LSM ツリーに格納されます。
  • デフォルト値: "1KB"
  • 最小値: 0
  • 単位: KB|MB|GB

blob-file-compression

  • Blob ファイルで使用される圧縮アルゴリズム
  • オプションの値: "no" 、 "snappy" 、 "zlib" 、 "bzip2" 、 "lz4" 、 "lz4hc" 、 "zstd"
  • デフォルト値: "lz4"

注記：

Snappy 圧縮ファイルは公式の Snappy フォーマットに存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。

blob-cache-size

  • BLOB ファイルのキャッシュ サイズ
  • デフォルト値: "0GB"
  • 最小値: 0
  • 単位: KB|MB|GB

min-gc-batch-size

  • GC を 1 回実行するために必要な BLOB ファイルの最小合計サイズ
  • デフォルト値: "16MB"
  • 最小値: 0
  • 単位: KB|MB|GB

max-gc-batch-size

  • 1 回の GC 実行に許可される BLOB ファイルの最大合計サイズ
  • デフォルト値: "64MB"
  • 最小値: 0
  • 単位: KB|MB|GB

discardable-ratio

  • Blob ファイルに対して GC がトリガーされる比率。 Blob ファイル内の無効な値の割合がこの割合を超えている場合にのみ、Blob ファイルを GC 用に選択できます。
  • デフォルト値: 0.5
  • 最小値: 0
  • 最大値： 1

sample-ratio

  • GC 中にファイルをサンプリングするときの (Blob ファイルから読み取られたデータ/Blob ファイル全体) の比率
  • デフォルト値: 0.1
  • 最小値: 0
  • 最大値： 1

merge-small-file-threshold

  • Blob ファイルのサイズがこの値より小さい場合でも、Blob ファイルが GC に選択される可能性があります。この場合、 discardable-ratioは無視されます。
  • デフォルト値: "8MB"
  • 最小値: 0
  • 単位: KB|MB|GB

blob-run-mode

  • Titan の実行モードを指定します。
  • オプションの値:
    • normal : 値のサイズがmin-blob-sizeを超える場合、データを BLOB ファイルに書き込みます。
    • read_only : BLOB ファイルへの新しいデータの書き込みを拒否しますが、BLOB ファイルから元のデータを読み取ります。
    • fallback : BLOB ファイル内のデータを LSM に書き込みます。
  • デフォルト値: normal

level-merge

  • 読み取りパフォーマンスを最適化するかどうかを決定します。 level-mergeを有効にすると、書き込み増幅が増加します。
  • デフォルト値: false

ラフトデータベース

raftdbに関するコンフィグレーション項目

max-background-jobs

max-sub-compactions

  • RocksDB で同時に実行されるサブコンパクション操作の数
  • デフォルト値: 2
  • 最小値: 1

max-open-files

  • RocksDB が開くことができるファイルの総数
  • デフォルト値: 40960
  • 最小値: -1

max-manifest-file-size

  • RocksDB マニフェスト ファイルの最大サイズ
  • デフォルト値: "20MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

create-if-missing

  • 値がtrueの場合、データベースが存在しない場合にデータベースが作成されます。
  • デフォルト値: true

stats-dump-period

  • 統計情報をログに出力する間隔
  • デフォルト値: 10m

wal-dir

  • Raft RocksDB WAL ファイルが保存されているディレクトリ。これは、WAL の絶対ディレクトリ パスです。この構成項目をrocksdb.wal-dirと同じ値に設定しないでください。
  • この設定項目が設定されていない場合、ログファイルはデータと同じディレクトリに保存されます。
  • マシン上に 2 つのディスクがある場合、RocksDB データと WAL ログを別のディスクに保存すると、パフォーマンスが向上する可能性があります。
  • デフォルト値: ""

wal-ttl-seconds

  • アーカイブされた WAL ファイルを保持する期間を指定します。この値を超えると、システムはこれらのファイルを削除します。
  • デフォルト値: 0
  • 最小値: 0
  • 単位：秒

wal-size-limit

  • アーカイブされた WAL ファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。
  • デフォルト値: 0
  • 最小値: 0
  • 単位: B|KB|MB|GB

max-total-wal-size

  • RocksDB WAL の合計最大サイズ
  • デフォルト値: "4GB"

compaction-readahead-size

  • RocksDB の圧縮中に先読み機能を有効にするかどうかを制御し、先読みデータのサイズを指定します。
  • メカニカル ディスクを使用する場合は、値を少なくとも2MBに設定することをお勧めします。
  • デフォルト値: 0
  • 最小値: 0
  • 単位: B|KB|MB|GB

writable-file-max-buffer-size

  • WritableFileWrite で使用される最大バッファ サイズ
  • デフォルト値: "1MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

use-direct-io-for-flush-and-compaction

  • バックグラウンドのフラッシュと圧縮での読み取りと書き込みの両方にO_DIRECTを使用するかどうかを決定します。このオプションのパフォーマンスへの影響: O_DIRECTバイパスを有効にすると、OS バッファ キャッシュの汚染が防止されますが、後続のファイルの読み取りでは、バッファ キャッシュへの内容の再読み取りが必要になります。
  • デフォルト値: false

enable-pipelined-write

  • パイプライン書き込みを有効にするかどうかを制御します。この構成が有効な場合、以前のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプライン コミット メカニズムが使用されます。
  • デフォルト値: true

allow-concurrent-memtable-write

  • memtable の同時書き込みを有効にするかどうかを制御します。
  • デフォルト値: true

bytes-per-sync

  • ファイルが非同期で書き込まれている間に、OS がファイルをディスクに増分同期する速度。
  • デフォルト値: "1MB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

wal-bytes-per-sync

  • WAL ファイルの書き込み時に OS が WAL ファイルをディスクに増分同期する速度
  • デフォルト値: "512KB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

info-log-max-size

  • 情報ログの最大サイズ
  • デフォルト値: "1GB"
  • 最小値: 0
  • 単位: B|KB|MB|GB

info-log-roll-time

  • 情報ログが切り詰められる間隔。値が0sの場合、ログは切り捨てられません。
  • デフォルト値: "0s" (ログが切り捨てられないことを意味します)

info-log-keep-log-file-num

  • RaftDB に保存される情報ログ ファイルの最大数
  • デフォルト値: 10
  • 最小値: 0

info-log-dir

  • 情報ログが保存されるディレクトリ
  • デフォルト値: ""

info-log-level

  • RaftDB のログレベル
  • デフォルト値: "info"

いかだエンジン

Raft Engineに関連するコンフィグレーション項目。

注記：

  • 初めてRaft Engine を有効にすると、TiKV はデータを RocksDB からRaft Engineに転送します。したがって、TiKV が開始されるまでさらに数十秒待つ必要があります。
  • TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。したがって、TiDB クラスターを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする前に、 enableからfalseに設定してRaft Engine を無効にし、構成を有効にするために TiKV を再起動します。

enable

  • Raftログを保存するためにRaft Engineを使用するかどうかを決定します。有効にすると、 raftdbの設定は無視されます。
  • デフォルト値: true

dir

  • raft ログ ファイルが保存されるディレクトリ。ディレクトリが存在しない場合は、TiKV の起動時に作成されます。
  • この設定項目が設定されていない場合は、 {data-dir}/raft-engineが使用されます。
  • マシン上に複数のディスクがある場合、TiKV のパフォーマンスを向上させるために、 Raft Engineのデータを別のディスクに保存することをお勧めします。
  • デフォルト値: ""

batch-compression-threshold

  • ログバッチのしきい値サイズを指定します。この構成より大きいログ バッチは圧縮されます。この構成項目を0に設定すると、圧縮は無効になります。
  • デフォルト値: "8KB"

bytes-per-sync

  • バッファリングされた書き込みの最大累積サイズを指定します。この設定値を超えると、バッファされた書き込みがディスクにフラッシュされます。
  • この構成項目を0に設定すると、増分同期は無効になります。
  • デフォルト値: "4MB"

target-file-size

  • ログファイルの最大サイズを指定します。ログ ファイルがこの値より大きい場合、ログ ファイルはローテーションされます。
  • デフォルト値: "128MB"

purge-threshold

  • メインログキューのしきい値サイズを指定します。この設定値を超えると、メイン ログ キューがパージされます。
  • この設定を使用して、 Raft Engineのディスク領域使用量を調整できます。
  • デフォルト値: "10GB"

recovery-mode

  • リカバリ中のファイル破損に対処する方法を決定します。
  • 値のオプション: "absolute-consistency" 、 "tolerate-tail-corruption" 、 "tolerate-any-corruption"
  • デフォルト値: "tolerate-tail-corruption"

recovery-read-block-size

  • リカバリ中にログ ファイルを読み取るための最小 I/O サイズ。
  • デフォルト値: "16KB"
  • 最小値: "512B"

recovery-threads

  • ログ ファイルのスキャンと回復に使用されるスレッドの数。
  • デフォルト値: 4
  • 最小値: 1

memory-limit

  • Raft Engineのメモリ使用量の制限を指定します。
  • この構成値が設定されていない場合、使用可能なシステムメモリの 15% が使用されます。
  • デフォルト値: Total machine memory * 15%

format-version v6.3.0 の新機能

注記：

format-versionを2に設定した後、TiKV クラスターを v6.3.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする前に次の手順を実行します。

  1. enableからfalse設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にします。
  2. format-version ～ 1を設定します。
  3. enableからtrue設定してRaft Engine を有効にし、TiKV を再起動して設定を有効にします。
  • Raft Engineのログ ファイルのバージョンを指定します。
  • 値のオプション:
    • 1 : v6.3.0 より前の TiKV のデフォルトのログ ファイル バージョン。 TiKV 以降の v6.1.0 で読み込むことができます。
    • 2 : ログのリサイクルをサポートします。 TiKV 以降の v6.3.0 で読み込むことができます。
  • デフォルト値: 2

enable-log-recycle v6.3.0 の新機能

注記：

この設定項目は、 format-version >= 2 の場合にのみ使用できます。

  • Raft Engineで古いログ ファイルをリサイクルするかどうかを決定します。これを有効にすると、論理的にパージされたログ ファイルがリサイクル用に予約されます。これにより、書き込みワークロードのロングテールレイテンシーが短縮されます。
  • デフォルト値: true

prefill-for-recycle v7.0.0 の新機能

注記：

この設定項目は、 enable-log-recycleがtrueに設定されている場合にのみ有効になります。

  • Raft Engineでログをリサイクルするために空のログ ファイルを生成するかどうかを決定します。これを有効にすると、 Raft Engine は初期化中にログのリサイクルのために空のログ ファイルのバッチを自動的に埋め、初期化直後にログのリサイクルが有効になります。
  • デフォルト値: false

安全

セキュリティに関するコンフィグレーション項目。

ca-path

  • CA ファイルのパス
  • デフォルト値: ""

cert-path

  • X.509 証明書を含むプライバシー強化メール (PEM) ファイルのパス
  • デフォルト値: ""

key-path

  • X.509 キーを含む PEM ファイルのパス
  • デフォルト値: ""

cert-allowed-cn

  • クライアントによって提示された証明書で許容される X.509 共通名のリスト。リクエストは、提示された共通名がリスト内のエントリの 1 つと完全に一致する場合にのみ許可されます。
  • デフォルト値: [] 。これは、クライアント証明書の CN チェックがデフォルトで無効になっていることを意味します。

redact-info-log v4.0.8 の新機能

  • この構成項目は、ログの編集を有効または無効にします。構成値がtrueに設定されている場合、ログ内のすべてのユーザー データは?に置き換えられます。
  • デフォルト値: false

セキュリティ.暗号化

保存時の暗号化 (TDE)に関するコンフィグレーション項目。

data-encryption-method

  • データファイルの暗号化方式
  • 値のオプション: 「plaintext」、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、および「sm4-ctr」 (v6.3.0 以降でサポート)
  • 「plaintext」以外の値は暗号化が有効であることを意味し、その場合はマスターキーを指定する必要があります。
  • デフォルト値: "plaintext"

data-key-rotation-period

  • TiKV がデータ暗号化キーをローテーションする頻度を指定します。
  • デフォルト値: 7d

enable-file-dictionary-log

  • TiKV が暗号化メタデータを管理する場合、最適化を有効にして I/O とミューテックスの競合を削減します。
  • この構成パラメータが (デフォルトで) 有効になっている場合に発生する可能性のある互換性の問題を回避するには、詳細については保存時の暗号化- TiKV バージョン間の互換性を参照してください。
  • デフォルト値: true

master-key

previous-master-key

  • 新しいマスター キーをローテーションするときに古いマスター キーを指定します。設定形式はmaster-keyと同様です。マスターキーの構成方法については、 保存時の暗号化- 暗号化を構成するを参照してください。

輸入

TiDB LightningインポートおよびBRリストアに関連するコンフィグレーション項目。

num-threads

  • RPC リクエストを処理するスレッドの数
  • デフォルト値: 8
  • 最小値: 1

stream-channel-window

  • ストリーム チャネルのウィンドウ サイズ。チャンネルがいっぱいになると、ストリームはブロックされます。
  • デフォルト値: 128

memory-use-ratio v6.5.0 の新機能

  • v6.5.0 以降、PITR はメモリ内のバックアップ ログ ファイルへの直接アクセスとデータの復元をサポートします。この設定項目は、TiKV の合計メモリに対する PITR に使用可能なメモリの比率を指定します。
  • 値の範囲: [0.0、0.5]
  • デフォルト値: 0.3 。これは、システムメモリの 30% が PITR に使用できることを意味します。値が0.0場合、PITR はログ ファイルをローカル ディレクトリにダウンロードすることによって実行されます。

注記：

v6.5.0 より前のバージョンでは、ポイントインタイム リカバリ (PITR) は、バックアップ ファイルをローカル ディレクトリにダウンロードすることによるデータの復元のみをサポートします。

GC

batch-keys

  • 1 回のバッチでガベージ コレクションされるキーの数
  • デフォルト値: 512

max-write-bytes-per-sec

  • GC ワーカーが 1 秒間に RocksDB に書き込むことができる最大バイト数。
  • 値が0に設定されている場合、制限はありません。
  • デフォルト値: "0"

enable-compaction-filter v5.0 の新機能

  • 圧縮フィルター機能で GC を有効にするかどうかを制御します
  • デフォルト値: true

ratio-threshold

  • GC をトリガーするガベージ率のしきい値。
  • デフォルト値: 1.1

バックアップ

BRバックアップに関するコンフィグレーション項目。

num-threads

  • バックアップを処理するワーカー スレッドの数
  • デフォルト値: MIN(CPU * 0.5, 8)
  • 値の範囲: [1, CPU]
  • 最小値: 1

batch-size

  • 1 回のバッチでバックアップするデータ範囲の数
  • デフォルト値: 8

sst-max-size

  • バックアップ SST ファイル サイズのしきい値。 TiKVリージョン内のバックアップ ファイルのサイズがこのしきい値を超える場合、ファイルは TiKVリージョンを複数のリージョン範囲に分割して複数のファイルにバックアップされます。分割されたリージョン内の各ファイルのサイズはsst-max-sizeと同じ (またはわずかに大きい) です。
  • たとえば、リージョン[a,e)のバックアップ ファイルのサイズがsst-max-sizeより大きい場合、ファイルはリージョン[a,b) 、 [b,c) 、 [c,d)および[d,e)の複数のファイルにバックアップされますが、 [a,b) 、 [b,c) 、 [c,d)のサイズは同じです。 sst-max-sizeのものと同じ (またはわずかに大きい)。
  • デフォルト値: "144MB"

enable-auto-tune v5.4.0 の新機能

  • クラスターのリソース使用率が高い場合に、クラスターへの影響を軽減するためにバックアップ タスクで使用されるリソースを制限するかどうかを制御します。詳細については、 BRオートチューンを参照してください。
  • デフォルト値: true

s3-multi-part-size v5.3.2 の新機能

注記：

この構成は、S3 レート制限によって引き起こされるバックアップの失敗に対処するために導入されました。この問題はバックアップデータのstorage構造を改良するで修正されました。したがって、この構成は v6.1.1 から非推奨となり、推奨されなくなりました。

  • バックアップ中に S3 へのマルチパート アップロードを実行するときに使用されるパート サイズ。この設定の値を調整して、S3 に送信されるリクエストの数を制御できます。
  • データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 マルチパートアップロードが自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。
  • デフォルト値: 5MiB

backup.hadoop

home

  • HDFS シェル コマンドの場所を指定し、TiKV がシェル コマンドを検索できるようにします。この設定項目は、環境変数$HADOOP_HOMEと同じ効果があります。
  • デフォルト値: ""

linux-user

  • TiKV が HDFS シェル コマンドを実行する Linux ユーザーを指定します。
  • この構成項目が設定されていない場合、TiKV は現在の Linux ユーザーを使用します。
  • デフォルト値: ""

ログバックアップ

ログバックアップに関するコンフィグレーション項目です。

v6.2.0 の新機能enable

  • ログのバックアップを有効にするかどうかを決定します。
  • デフォルト値: true

file-size-limit v6.2.0 の新機能

  • 保存されるバックアップ ログ データのサイズ制限。
  • デフォルト値: 256MiB
  • 注: 通常、値file-size-limitは、外部storageに表示されるバックアップ ファイルのサイズより大きくなります。これは、バックアップ ファイルが外部storageにアップロードされる前に圧縮されるためです。

initial-scan-pending-memory-quota v6.2.0 の新機能

  • ログ バックアップ中に増分スキャン データを保存するために使用されるキャッシュのクォータ。
  • デフォルト値: min(Total machine memory * 10%, 512 MB)

initial-scan-rate-limit v6.2.0 の新機能

  • ログ バックアップ中の増分データ スキャンのスループットのレート制限。
  • デフォルト値: 60。デフォルトのレート制限が 60 MB/秒であることを示します。

max-flush-interval v6.2.0 の新機能

  • ログバックアップにおいてバックアップデータを外部storageに書き込む最大間隔。
  • デフォルト値: 3分

num-threads v6.2.0 の新機能

  • ログのバックアップに使用されるスレッドの数。
  • デフォルト値: CPU * 0.5
  • 値の範囲: [2、12]

temp-path v6.2.0 の新機能

  • ログ ファイルが外部storageにフラッシュされる前に書き込まれる一時パス。
  • デフォルト値: ${deploy-dir}/data/log-backup-temp

CDC

TiCDC に関するコンフィグレーション項目。

min-ts-interval

  • 解決された TS が計算されて転送される間隔。
  • デフォルト値: "200ms"

old-value-cache-memory-quota

  • TiCDC の古い値によるメモリ使用量の上限。
  • デフォルト値: 512MB

sink-memory-quota

  • TiCDC データ変更イベントによるメモリ使用量の上限。
  • デフォルト値: 512MB

incremental-scan-speed-limit

  • 履歴データが段階的にスキャンされる最大速度。
  • デフォルト値: "128MB" 、1 秒あたり 128 MB を意味します。

incremental-scan-threads

  • 履歴データを段階的にスキャンするタスクのスレッド数。
  • デフォルト値: 4 、これは 4 つのスレッドを意味します。

incremental-scan-concurrency

  • 履歴データを段階的にスキャンするタスクの同時実行の最大数。
  • デフォルト値: 6 。これは、最大 6 つのタスクを同時に実行できることを意味します。
  • 注: incremental-scan-concurrencyの値はincremental-scan-threads以上である必要があります。そうしないと、TiKV は起動時にエラーを報告します。

resolved-ts

ステイル読み取りリクエストを処理するために解決済み TS を維持することに関連するコンフィグレーション項目。

enable

  • すべてのリージョンの解決済み TS を維持するかどうかを決定します。
  • デフォルト値: true

advance-ts-interval

  • 解決された TS が計算されて転送される間隔。
  • デフォルト値: "20s"

scan-lock-pool-size

  • 解決済み TS の初期化時に、TiKV が MVCC (マルチバージョン同時実行制御) ロック データをスキャンするために使用するスレッドの数。
  • デフォルト値: 2 、これは 2 つのスレッドを意味します。

pessimistic-txn

悲観的トランザクションの使用法については、 TiDB ペシミスティックトランザクションモードを参照してください。

wait-for-lock-timeout

  • TiKV の悲観的トランザクションが、他のトランザクションがロックを解放するのを待機する最長時間。タイムアウトになると、TiDB にエラーが返され、TiDB はロックの追加を再試行します。ロック待機タイムアウトはinnodb_lock_wait_timeoutに設定されます。
  • デフォルト値: "1s"
  • 最小値: "1ms"

wake-up-delay-duration

  • 悲観的トランザクションがロックを解放すると、ロックを待っているすべてのトランザクションのうち、最も小さいstart_tsを持つトランザクションだけがウェイクアップされます。他のトランザクションはwake-up-delay-duration後に起動されます。
  • デフォルト値: "20ms"

pipelined

  • この構成項目により、悲観的ロックを追加するパイプライン処理が可能になります。この機能を有効にすると、データがロックできることを検出した後、TiKV はただちに TiDB に後続のリクエストを実行し、悲観的ロックを非同期で書き込むように通知します。これにより、レイテンシーのほとんどが短縮され、悲観的トランザクションのパフォーマンスが大幅に向上します。ただし、悲観的ロックの非同期書き込みが失敗する可能性は依然として低いため、悲観的トランザクションのコミットが失敗する可能性があります。
  • デフォルト値: true

in-memory v6.0.0 の新機能

  • メモリ内の悲観的ロック機能を有効にします。この機能を有効にすると、悲観的トランザクションは、ロックをディスクに書き込んだり、ロックを他のレプリカに複製したりする代わりに、ロックをメモリに保存しようとします。これにより、悲観的トランザクションのパフォーマンスが向上します。ただし、悲観的ロックが失われ、悲観的トランザクションのコミットが失敗する可能性は依然として低いです。
  • デフォルト値: true
  • in-memory pipelinedの値がtrueの場合にのみ有効であることに注意してください。

クォータ

クォータリミッターに関するコンフィグレーション項目。

max-delay-duration v6.0.0 の新機能

  • 単一の読み取りまたは書き込みリクエストがフォアグラウンドで処理されるまで強制的に待機する最大時間。
  • デフォルト値: 500ms
  • 推奨設定: ほとんどの場合、デフォルト値を使用することをお勧めします。インスタンスでメモリ不足 (OOM) または激しいパフォーマンスのジッターが発生した場合は、値を 1S に設定して、リクエストの待機時間を 1 秒より短くすることができます。

フォアグラウンド クォータ リミッター

フォアグラウンド クォータ リミッターに関するコンフィグレーション項目。

TiKV がデプロイされているマシンのリソースが限られている (たとえば、CPU が 4 v とメモリが16 G しかない) とします。この状況では、TiKV のフォアグラウンドで処理される読み取りおよび書き込みリクエストが多すぎるため、バックグラウンドで使用される CPU リソースがそのようなリクエストの処理を支援するために占有され、TiKV のパフォーマンスの安定性に影響を与える可能性があります。この状況を回避するには、フォアグラウンド クォータ関連の構成項目を使用して、フォアグラウンドで使用される CPU リソースを制限します。リクエストによってクォータ リミッターがトリガーされると、リクエストは TiKV が CPU リソースを解放するまでしばらく待機することになります。正確な待機時間はリクエストの数によって異なり、最大待機時間は値max-delay-durationを超えることはありません。

foreground-cpu-time v6.0.0 の新機能

  • TiKV フォアグラウンドが読み取りおよび書き込みリクエストを処理するために使用する CPU リソースのソフト制限。
  • デフォルト値: 0 (制限なしを意味します)
  • 単位: millicpu (たとえば、 1500フォアグラウンド要求が 1.5v CPU を消費することを意味します)
  • 推奨設定: 4 コアを超えるインスタンスの場合は、デフォルト値0を使用します。 4 コアのインスタンスの場合、値を1000 ～ 1500の範囲に設定するとバランスが取れます。 2 コアのインスタンスの場合は、値を1200より小さくしてください。

foreground-write-bandwidth v6.0.0 の新機能

  • トランザクションがデータを書き込む帯域幅のソフト制限。
  • デフォルト値: 0KB (制限なしを意味します)
  • 推奨設定: foreground-cpu-time設定では書き込み帯域幅を制限するのに十分でない場合を除き、ほとんどの場合はデフォルト値0を使用します。このような例外を考慮して、4 コア以下のインスタンスでは50MBより小さい値を設定することをお勧めします。

foreground-read-bandwidth v6.0.0 の新機能

  • トランザクションとコプロセッサーがデータを読み取る帯域幅のソフト制限。
  • デフォルト値: 0KB (制限なしを意味します)
  • 推奨設定: foreground-cpu-time設定では読み取り帯域幅を制限するのに十分でない場合を除き、ほとんどの場合はデフォルト値0を使用します。このような例外を考慮して、4 コア以下のインスタンスでは20MBより小さい値を設定することをお勧めします。

バックグラウンド クォータ リミッター

バックグラウンドクォータリミッターに関するコンフィグレーション項目。

TiKV がデプロイされているマシンのリソースが限られている (たとえば、CPU が 4 v とメモリが16 G しかない) とします。この状況では、TiKV のバックグラウンドで処理される計算と読み取りおよび書き込みリクエストが多すぎる可能性があるため、フォアグラウンドで使用される CPU リソースがそのようなリクエストの処理を支援するために占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンド クォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限します。リクエストによってクォータ リミッターがトリガーされると、リクエストは TiKV が CPU リソースを解放するまでしばらく待機することになります。正確な待機時間はリクエストの数によって異なり、最大待機時間は値max-delay-durationを超えることはありません。

background-cpu-time v6.2.0 の新機能

  • 読み取りおよび書き込みリクエストを処理するために TiKV バックグラウンドで使用される CPU リソースのソフト制限。
  • デフォルト値: 0 (制限なしを意味します)
  • 単位: millicpu (たとえば、 1500バックグラウンド要求が 1.5v CPU を消費することを意味します)

background-write-bandwidth v6.2.0 の新機能

注記：

この構成項目はSHOW CONFIGの結果として返されますが、現在設定しても効果はありません。

  • バックグラウンド トランザクションがデータを書き込む帯域幅のソフト制限。
  • デフォルト値: 0KB (制限なしを意味します)

background-read-bandwidth v6.2.0 の新機能

注記：

この構成項目はSHOW CONFIGの結果として返されますが、現在設定しても効果はありません。

  • バックグラウンド トランザクションとコプロセッサーがデータを読み取る帯域幅のソフト制限。
  • デフォルト値: 0KB (制限なしを意味します)

enable-auto-tune v6.2.0 の新機能

  • クォータの自動調整を有効にするかどうかを決定します。この構成項目が有効になっている場合、TiKV は TiKV インスタンスの負荷に基づいてバックグラウンド リクエストのクォータを動的に調整します。
  • デフォルト値: false (自動チューニングが無効であることを意味します)

causal-ts v6.1.0 の新機能

TiKV API V2 が有効な場合のタイムスタンプの取得に関連するコンフィグレーション項目 ( storage.api-version = 2 )。

書き込みレイテンシーを短縮するために、TiKV はタイムスタンプのバッチをローカルに定期的に取得してキャッシュします。キャッシュされたタイムスタンプは、PD への頻繁なアクセスを回避し、短期間の TSO サービス障害を許容するのに役立ちます。

alloc-ahead-buffer v6.4.0 の新機能

  • 事前に割り当てられた TSO キャッシュ サイズ (期間内)。
  • TiKV が、この構成項目で指定された期間に基づいて TSO キャッシュを事前に割り当てることを示します。 TiKV は、前の期間に基づいて TSO 使用量を推定し、 alloc-ahead-buffer満たす TSO をローカルに要求してキャッシュします。
  • この構成項目は、TiKV API V2 が有効になっている場合 ( storage.api-version = 2 )、PD 障害の許容度を高めるためによく使用されます。
  • この構成項目の値を増やすと、TSO の消費量と TiKV のメモリオーバーヘッドが増加する可能性があります。十分な TSO を取得するには、PD のtso-update-physical-interval構成項目を減らすことをお勧めします。
  • テストによると、デフォルト値がalloc-ahead-bufferの場合、PD リーダーに障害が発生して別のノードに切り替わると、書き込みレイテンシーのレイテンシが短期間増加し、QPS が低下します (約 15%)。
  • ビジネスへの影響を避けるために、PD でtso-update-physical-interval = "1ms"を構成し、TiKV で次の構成項目を構成できます。
    • causal-ts.alloc-ahead-buffer = "6s"
    • causal-ts.renew-batch-max-size = 65536
    • causal-ts.renew-batch-min-size = 2048
  • デフォルト値: 3s

renew-interval

  • ローカルにキャッシュされたタイムスタンプが更新される間隔。
  • TiKV はrenew-intervalの間隔でタイムスタンプのリフレッシュのバッチを開始し、前の期間のタイムスタンプの消費量とalloc-ahead-bufferの設定に従って、キャッシュされたタイムスタンプの数を調整します。このパラメーターの設定値が大きすぎると、最新の TiKV ワークロードの変更が時間内に反映されません。このパラメータを小さい値に設定すると、PD の負荷が増加します。書き込みトラフィックが大きく変動する場合、タイムスタンプが頻繁に使い果たされる場合、および書き込みレイテンシーが増加する場合は、このパラメータをより小さい値に設定できます。同時に PD の負荷も考慮する必要があります。
  • デフォルト値: "100ms"

renew-batch-min-size

  • タイムスタンプ要求内の TSO の最小数。
  • TiKV は、前の期間のタイムスタンプの消費量に応じて、キャッシュされたタイムスタンプの数を調整します。少数の TSO のみが必要な場合、TiKV は、数がrenew-batch-min-sizeに達するまで要求された TSO を減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、必要に応じてこのパラメータをより大きな値に設定できます。このパラメータは単一の tikv サーバーのキャッシュ サイズであることに注意してください。パラメーターの設定値が大きすぎ、クラスターに多数の tikv サーバーが含まれている場合、TSO の消費が速すぎます。
  • Grafana の[TiKV-RAW] > [Causal timestamp]パネルでは、 TSO バッチ サイズは、アプリケーションのワークロードに応じて動的に調整された、ローカルにキャッシュされたタイムスタンプの数です。この指標を参照してrenew-batch-min-sizeを調整できます。
  • デフォルト値: 100

renew-batch-max-size v6.4.0 の新機能

  • タイムスタンプ要求内の TSO の最大数。
  • デフォルトの TSO 物理時間更新間隔 ( 50ms ) では、PD は最大 262144 個の TSO を提供します。要求された TSO がこの数を超えると、PD はそれ以上 TSO を提供しません。この構成アイテムは、TSO の枯渇と、TSO の枯渇による他のビジネスへの逆影響を回避するために使用されます。高可用性を向上させるためにこの構成項目の値を増やす場合、十分な TSO を取得するには、同時にtso-update-physical-intervalの値を減らす必要があります。
  • デフォルト値: 8192

リソース制御

TiKVstorageレイヤーのリソース制御に関するコンフィグレーション項目。

enabled v6.6.0 の新機能

  • 対応するリソース グループのリクエストユニット(RU)に従って、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうかを制御します。 TiDB リソース グループとリソース制御については、 TiDB リソース制御を参照してください。
  • この設定項目を有効にすると、TiDB で`tidb_enable_resource_controlが有効になっている場合にのみ機能します。この構成項目が有効になっている場合、TiKV はプライオリティ キューを使用して、フォアグラウンド ユーザーからのキューに入れられた読み取り/書き込み要求をスケジュールします。リクエストのスケジューリング優先度は、このリクエストを受信するリソース グループによって既に消費されているリソースの量に反比例し、対応するリソース グループのクォータに正の相関関係があります。
  • デフォルト値: true 。これは、リソース グループの RU に基づくスケジューリングが有効であることを意味します。

スプリット

ロードベースの分割に関するコンフィグレーション項目。

byte-threshold v5.0 の新機能

  • リージョンがホットスポットとして識別されるトラフィックのしきい値を制御します。

  • デフォルト値:

qps-threshold

  • リージョンがホットスポットとして識別される QPS しきい値を制御します。

  • デフォルト値:

region-cpu-overload-threshold-ratio v6.2.0 の新機能

  • リージョンがホットスポットとして識別される CPU 使用率のしきい値を制御します。

  • デフォルト値:

このページは役に立ちましたか？