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

TiDB 構成ファイルは、コマンドライン パラメーターよりも多くのオプションをサポートしています。デフォルトの構成ファイルconfig.toml.exampleダウンロードし、その名前をconfig.tomlに変更できます。このドキュメントでは、 コマンドラインオプションに関係しないオプションのみについて説明します。

ヒント:

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

split-table

  • テーブルごとに個別のリージョンを作成するかどうかを決定します。
  • デフォルト値: true
  • 多数のテーブル (たとえば、10 万テーブル以上) を作成する必要がある場合は、 falseに設定することをお勧めします。

tidb-max-reuse-chunk v6.4.0 の新機能

  • チャンク割り当てのキャッシュされたチャンク オブジェクトの最大数を制御します。この構成項目の値を大きすぎる値に設定すると、OOM のリスクが増加する可能性があります。
  • デフォルト値: 64
  • 最小値: 0
  • 最大値: 2147483647

tidb-max-reuse-column v6.4.0 の新機能

  • チャンク割り当てのキャッシュされた列オブジェクトの最大数を制御します。この構成項目の値を大きすぎる値に設定すると、OOM のリスクが増加する可能性があります。
  • デフォルト値: 256
  • 最小値: 0
  • 最大値: 2147483647

token-limit

  • リクエストを同時に実行できるセッションの数。
  • タイプ: 整数
  • デフォルト値: 1000
  • 最小値: 1
  • 最大値 (64 ビット プラットフォーム): 18446744073709551615
  • 最大値 (32 ビット プラットフォーム): 4294967295

temp-dir v6.3.0 の新機能

  • TiDB が一時データを保存するために使用するファイル システムの場所。機能が TiDB ノードのローカルstorageを必要とする場合、TiDB は対応する一時データをこの場所に保存します。
  • インデックスの作成時にtidb_ddl_enable_fast_reorgが有効な場合、新しく作成されたインデックスに対してバックフィルする必要があるデータは、最初に TiDB ローカル一時ディレクトリに保存され、次にバッチで TiKV にインポートされるため、インデックスの作成が高速化されます。
  • データのインポートにIMPORT INTOを使用すると、並べ替えられたデータはまず TiDB ローカル一時ディレクトリに保存され、次に TiKV にバッチでインポートされます。
  • デフォルト値: "/tmp/tidb"

注記:

ディレクトリが存在しない場合、TiDB は起動時に自動的に作成します。ディレクトリの作成が失敗した場合、または TiDB にそのディレクトリに対する読み取りおよび書き込み権限がない場合、予期しない問題が発生する可能Fast Online DDLがあります。

oom-use-tmp-storage

  • 単一の SQL ステートメントがシステム変数tidb_mem_quota_queryで指定されたメモリクォータを超えた場合に、一部の演算子の一時storageを有効にするかどうかを制御します。
  • デフォルト値: true

tmp-storage-path

  • 単一の SQL ステートメントがシステム変数tidb_mem_quota_queryで指定されたメモリクォータを超えた場合に、一部の演算子の一時storage域パスを指定します。
  • デフォルト値: <temporary directory of OS>/<OS user ID>_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storageMC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA= <host>:<port>/<statusHost>:<statusPort>Base64エンコード結果です。
  • この設定は、システム変数tidb_enable_tmp_storage_on_oomONの場合にのみ有効です。

tmp-storage-quota

  • tmp-storage-pathでstorageのクォータを指定します。単位はバイトです。
  • 単一の SQL ステートメントが一時ディスクを使用し、TiDBサーバーの一時ディスクの合計ボリュームがこの設定値を超えると、現在の SQL 操作がキャンセルされ、 Out of Global Storage Quota!エラーが返されます。
  • この構成の値が0より小さい場合、上記のチェックと制限は適用されません。
  • デフォルト値: -1
  • tmp-storage-pathで使用可能な残りのstorageがtmp-storage-quotaで定義された値よりも少ない場合、TiDBサーバーは起動時にエラーを報告し、終了します。

lease

  • DDL リースのタイムアウト。
  • デフォルト値: 45s
  • 単位:秒

compatible-kill-query

  • KILLステートメントを MySQL 互換に設定するかどうかを決定します。
  • デフォルト値: false
  • compatible-kill-query enable-global-kill falseに設定されている場合にのみ有効です。
  • enable-global-killfalseの場合、クエリを強制終了するときにTIDBキーワードを追加する必要があるかどうかはcompatible-kill-query制御されます。
    • compatible-kill-queryfalse場合、TiDB のKILL xxxの動作は MySQL の動作とは異なります。 TiDB でクエリを強制終了するには、 KILL TIDB xxxなどのTIDBキーワードを追加する必要があります。
    • compatible-kill-querytrue場合、TiDB でクエリを強制終了するために、 TIDBキーワードを追加する必要はありません。クライアントが常に同じ TiDB インスタンスに接続されることが確実でない限り、構成ファイルでcompatible-kill-queryからtrueを設定することは強く推奨されません。これは、デフォルトの MySQL クライアントでControl + Cを押すと、 KILLが実行される新しい接続が開かれるためです。クライアントと TiDB クラスターの間にプロキシがある場合、新しい接続が別の TiDB インスタンスにルーティングされる可能性があり、これにより誤って別のセッションが強制終了される可能性があります。
  • enable-global-killtrueの場合、 KILL xxxKILL TIDB xxxは同じ効果がありますが、 Control + Cを使用してクエリを強制終了することはサポートされていません。
  • KILLステートメントの詳細については、 [TIDB]を殺すを参照してください。

check-mb4-value-in-utf8

  • utf8mb4文字チェックを有効にするかどうかを決定します。この機能が有効な場合、文字セットがutf8mb4文字がutf8に挿入されると、エラーが返されます。
  • デフォルト値: false
  • v6.1.0 以降、 utf8mb4文字チェックを有効にするかどうかは、TiDB 設定項目instance.tidb_check_mb4_value_in_utf8またはシステム変数tidb_check_mb4_value_in_utf8によって決まります。 check-mb4-value-in-utf8引き続き有効です。ただし、 check-mb4-value-in-utf8instance.tidb_check_mb4_value_in_utf8の両方が設定されている場合は、後者が有効になります。

treat-old-version-utf8-as-utf8mb4

  • 古いテーブルのutf8文字セットをutf8mb4として扱うかどうかを決定します。
  • デフォルト値: true

alter-primary-key (非推奨)

  • 主キー制約を列に追加するか列から削除するかを決定します。
  • デフォルト値: false
  • このデフォルト設定では、主キー制約の追加または削除はサポートされていません。 alter-primary-keytrueを設定することでこの機能を有効にできます。ただし、スイッチをオンにする前にテーブルがすでに存在しており、その主キー列のデータ型が整数の場合は、この構成項目をtrueに設定しても、列から主キーを削除することはできません。

注記:

この構成項目は非推奨になり、現在は@tidb_enable_clustered_indexの値がINT_ONLYの場合にのみ有効になります。主キーを追加または削除する必要がある場合は、テーブルの作成時に代わりにNONCLUSTEREDキーワードを使用します。 CLUSTEREDタイプの主キーの詳細については、 クラスター化インデックスを参照してください。

server-version

  • 次の状況で、TiDB によって返されるバージョン文字列を変更します。
    • 内蔵VERSION()機能使用時。
    • TiDB がクライアントへの最初の接続を確立し、サーバーのバージョン文字列を含む最初のハンドシェイク パケットを返すとき。詳細はMySQL 初期ハンドシェイク パケットを参照してください。
  • デフォルト値: ""
  • デフォルトでは、TiDB バージョン文字列の形式は5.7.${mysql_latest_minor_version}-TiDB-${tidb_version}です。

注記:

TiDB ノードは、値server-versionを使用して現在の TiDB バージョンを確認します。したがって、予期しない動作を回避するには、TiDB クラスターをアップグレードする前に、値server-versionを空、または現在の TiDB クラスターの実際のバージョンに設定する必要があります。

repair-mode

  • 信頼できない修復モードを有効にするかどうかを決定します。 repair-modetrueに設定されている場合、 repair-table-list内の不良テーブルはロードできません。
  • デフォルト値: false
  • repair構文はデフォルトではサポートされていません。これは、TiDB の開始時にすべてのテーブルがロードされることを意味します。

repair-table-list

  • repair-table-list repair-mode trueに設定されている場合にのみ有効です。 repair-table-listは、インスタンス内で修復する必要がある不良テーブルのリストです。リストの例は次のとおりです: ["db.table1","db.table2"...]
  • デフォルト値: []
  • デフォルトではリストは空です。これは、修復する必要がある不良テーブルがないことを意味します。

new_collations_enabled_on_first_bootstrap

  • 新しい照合順序のサポートを有効または無効にします。
  • デフォルト値: true
  • 注: この構成は、最初に初期化される TiDB クラスターに対してのみ有効です。初期化後は、この構成項目を使用して新しい照合順序のサポートを有効または無効にすることはできません。

max-server-connections

  • TiDB で許可される同時クライアント接続の最大数。リソースを制御するために使用されます。
  • デフォルト値: 0
  • デフォルトでは、TiDB は同時クライアント接続数に制限を設定しません。この構成項目の値が0より大きく、実際のクライアント接続の数がこの値に達すると、TiDBサーバーは新しいクライアント接続を拒否します。
  • v6.2.0 以降、TiDB 構成項目instance.max_connectionsまたはシステム変数max_connectionsは、TiDB で許可される同時クライアント接続の最大数を設定するために使用されます。 max-server-connectionsは引き続き有効です。ただし、 max-server-connectionsinstance.max_connections同時に設定した場合は、後者が有効になります。

max-index-length

  • 新しく作成されるインデックスの最大許容長を設定します。
  • デフォルト値: 3072
  • 単位:バイト
  • 現在、有効な値の範囲は[3072, 3072*4]です。 MySQL と TiDB (バージョン < v3.0.11) にはこの設定項目はありませんが、どちらも新しく作成されるインデックスの長さを制限します。 MySQL でのこの制限は3072です。 TiDB (バージョン =< 3.0.7) では、この制限は3072*4です。 TiDB (3.0.7 < バージョン < 3.0.11) では、この制限は3072です。この構成は、MySQL および以前のバージョンの TiDB と互換性を持たせるために追加されました。

table-column-count-limit v5.0 の新機能

  • 単一テーブル内の列数の制限を設定します。
  • デフォルト値: 1017
  • 現在、有効な値の範囲は[1017, 4096]です。

index-limit v5.0 の新機能

  • 単一テーブル内のインデックスの数の制限を設定します。
  • デフォルト値: 64
  • 現在、有効な値の範囲は[64, 512]です。

enable-telemetry v4.0.2 の新機能

  • TiDB でのテレメトリ収集を有効または無効にします。
  • デフォルト値: false
  • TiDB インスタンスでこの構成がtrueに設定されている場合、この TiDB インスタンスのテレメトリ収集が有効になり、システム変数tidb_enable_telemetry有効になります。
  • すべての TiDB インスタンスでこの構成がfalseに設定されている場合、TiDB のテレメトリ収集は無効になり、 tidb_enable_telemetryシステム変数は有効になりません。詳細はテレメトリーを参照してください。

deprecate-integer-display-length

  • この構成項目がtrueに設定されている場合、整数型の表示幅は非推奨になります。
  • デフォルト値: false

enable-tcp4-only v5.0 の新機能

  • TCP4 のみでのリスニングを有効または無効にします。
  • デフォルト値: false
  • TCPヘッダーからの実際のクライアントIPは「tcp4」プロトコルで正しく解析できるため、ロード バランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。

enable-enum-length-limit v5.0 の新機能

  • 単一のENUM要素と単一のSET要素の最大長を制限するかどうかを決定します。
  • デフォルト値: true
  • この構成値がtrueの場合、単一のENUM要素および単一のSET要素の最大長は 255 文字であり、 MySQL 8.0と互換性があります。この構成値がfalseの場合、単一要素の長さには制限がなく、TiDB (v5.0 以前) と互換性があります。

graceful-wait-before-shutdown v5.0 の新機能

  • サーバーをシャットダウンするときに TiDB が待機する秒数を指定します。これにより、クライアントは切断できるようになります。
  • デフォルト値: 0
  • TiDB がシャットダウンを待機しているとき (猶予期間内)、HTTP ステータスは障害を示し、ロード バランサーがトラフィックを再ルーティングできるようになります。

enable-global-kill v6.1.0 の新機能

  • Global Kill (インスタンス間でのクエリまたは接続の終了) 機能を有効にするかどうかを制御します。
  • デフォルト値: true
  • 値がtrueの場合、 KILLKILL TIDBステートメントの両方でインスタンス間のクエリまたは接続を終了できるため、クエリまたは接続が誤って終了することを心配する必要はありません。クライアントを使用して任意の TiDB インスタンスに接続し、 KILLまたはKILL TIDBステートメントを実行すると、ステートメントはターゲット TiDB インスタンスに転送されます。クライアントと TiDB クラスターの間にプロキシがある場合、ステートメントKILLKILL TIDBも実行のためにターゲット TiDB インスタンスに転送されます。
  • v7.3.0 以降、 enable-global-killenable-32bits-connection-id両方がtrueに設定されている場合、MySQL コマンド ラインControl+Cを使用してクエリまたは接続を終了できます。詳細については、 KILLを参照してください。

enable-32bits-connection-id v7.3.0 の新機能

  • 32 ビット接続 ID 機能を有効にするかどうかを制御します。
  • デフォルト値: true
  • この構成項目とenable-global-kill両方がtrueに設定されている場合、TiDB は 32 ビットの接続 ID を生成します。これにより、MySQL コマンドラインControl+Cによってクエリまたは接続を終了できるようになります。

initialize-sql-file v6.6.0 の新機能

  • TiDB クラスターを初めて起動するときに実行される SQL スクリプトを指定します。
  • デフォルト値: ""
  • このスクリプト内のすべての SQL ステートメントは、権限チェックなしで最高の権限で実行されます。指定された SQL スクリプトの実行に失敗すると、TiDB クラスターの起動に失敗する可能性があります。
  • この構成アイテムは、システム変数の値の変更、ユーザーの作成、権限などの操作を実行するために使用されます。

enable-forwarding v5.0.0 の新機能

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

enable-table-lock v4.0.0 の新機能

  • テーブルロック機能を有効にするかどうかを制御します。
  • デフォルト値: false
  • テーブル ロックは、複数のセッション間での同じテーブルへの同時アクセスを調整するために使用されます。現在、 READWRITE 、およびWRITE LOCALロック タイプがサポートされています。構成項目がfalseに設定されている場合、 LOCK TABLESまたはUNLOCK TABLESステートメントを実行しても有効にならず、「LOCK/UNLOCK TABLES はサポートされていません」という警告が返されます。詳細については、 LOCK TABLESUNLOCK TABLES参照してください。

labels

  • サーバーラベルを指定します。たとえば、 { zone = "us-west-1", dc = "dc1", rack = "rack1", host = "tidb1" }
  • デフォルト値: {}

注記:

  • TiDB では、 zoneラベルはサーバーが配置されているゾーンを指定するために特別に使用されます。 zoneが null 以外の値に設定されている場合、対応する値がtxn-scoreFollower readなどの機能によって自動的に使用されます。
  • groupラベルはTiDB Operatorで特別な用途があります。 TiDB Operator使用してデプロイされたクラスターの場合、 groupラベルを手動で指定することは勧めできません。

ログ

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

level

  • ログの出力レベルを指定します。
  • 値のオプション: debuginfowarnerror 、およびfatal
  • デフォルト値: info

format

  • ログの出力形式を指定します。
  • 値のオプション: jsonおよびtext
  • デフォルト値: text

enable-timestamp

  • ログへのタイムスタンプ出力を有効にするかどうかを決定します。
  • デフォルト値: null
  • 値をfalseに設定すると、ログにはタイムスタンプが出力されません。

注記:

  • 下位互換性を保つために、最初のdisable-timestamp構成項目は引き続き有効です。ただし、 disable-timestampの値がenable-timestampの値と意味的に競合する場合 (たとえば、 enable-timestampdisable-timestampの両方がtrueに設定されている場合)、TiDB はdisable-timestampの値を無視します。
  • 現在、TiDB はログにタイムスタンプを出力するかどうかを決定するためにdisable-timestampを使用します。この状況では、 enable-timestampの値はnullになります。
  • 以降のバージョンでは、 disable-timestamp構成は削除されます。 disable-timestamp破棄し、意味的に理解しやすいenable-timestampを使用します。

enable-slow-log

  • スロークエリログを有効にするかどうかを決定します。
  • デフォルト値: true
  • スロークエリログを有効にするには、 enable-slow-logtrueを設定します。それ以外の場合は、 falseに設定します。
  • v6.1.0 以降、スロー クエリ ログを有効にするかどうかは、TiDB 構成項目instance.tidb_enable_slow_logまたはシステム変数tidb_enable_slow_logによって決定されます。 enable-slow-logは引き続き有効です。ただし、 enable-slow-loginstance.tidb_enable_slow_log同時に設定した場合は、後者が有効になります。

slow-query-file

  • スロークエリログのファイル名。
  • デフォルト値: tidb-slow.log
  • TiDB v2.1.8 ではスローログの形式が更新されたため、スローログはスローログファイルに別途出力されます。 v2.1.8 より前のバージョンでは、この変数はデフォルトで "" に設定されます。
  • 設定すると、スロークエリログが別途このファイルに出力されます。

slow-threshold

  • スローログの消費時間の閾値を出力します。
  • デフォルト値: 300
  • 単位: ミリ秒
  • クエリの値がデフォルト値より大きい場合、それは低速クエリであり、低速ログに出力されます。
  • v6.1.0 以降、スローログの消費時間の閾値は TiDB 設定項目instance.tidb_slow_log_thresholdまたはシステム変数tidb_slow_log_thresholdで指定されます。 slow-thresholdは引き続き有効です。ただし、 slow-thresholdinstance.tidb_slow_log_threshold同時に設定した場合は、後者が有効になります。

record-plan-in-slow-log

  • 実行計画を低速ログに記録するかどうかを決定します。
  • デフォルト値: 1
  • v6.1.0 以降、実行計画をスロー ログに記録するかどうかは、TiDB 構成項目instance.tidb_record_plan_in_slow_logまたはシステム変数tidb_record_plan_in_slow_logによって決定されます。 record-plan-in-slow-logは引き続き有効です。ただし、 record-plan-in-slow-loginstance.tidb_record_plan_in_slow_log同時に設定した場合は、後者が有効になります。

expensive-threshold

  • expensive操作の行数の閾値を出力します。
  • デフォルト値: 10000
  • クエリ行数 (統計に基づく中間結果を含む) がこの値より大きい場合、 expensive操作となり、接頭辞[EXPENSIVE_QUERY]付いたログが出力されます。

timeout v7.1.0 の新機能

  • TiDB でのログ書き込み操作のタイムアウトを設定します。ディスク障害が発生してログの書き込みができなくなった場合、この構成項目により、TiDB プロセスがハングせずにpanicを引き起こす可能性があります。
  • デフォルト値: 0 、タイムアウトが設定されていないことを示します。
  • 単位:秒
  • 一部のユーザー シナリオでは、TiDB ログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存され、永久に使用できなくなる可能性があります。このような場合、TiDB はそのような災害から自動的に回復できず、ログ書き込み操作は永久にブロックされます。 TiDB プロセスは実行されているように見えますが、リクエストには応答しません。この設定項目は、そのような状況に対処するように設計されています。

ログファイル

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

filename

  • 一般ログファイルのファイル名。
  • デフォルト値: ""
  • 設定すると、このファイルにログが出力されます。

max-size

  • ログ ファイルのサイズ制限。
  • デフォルト値: 300
  • 単位:MB
  • 最大値は 4096 です。

max-days

  • ログが保持される最大日数。
  • デフォルト値: 0
  • ログはデフォルトで保持されます。値を設定すると、期限切れのログはmax-daysの後にクリーンアップされます。

max-backups

  • 保持されるログの最大数。
  • デフォルト値: 0
  • すべてのログ ファイルはデフォルトで保持されます。 7に設定すると、最大 7 つのログ ファイルが保持されます。

Security

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

enable-sem

  • Security強化モード (SEM) を有効にします。
  • デフォルト値: false
  • SEM のステータスは、システム変数tidb_enable_enhanced_securityを介して取得できます。

ssl-ca

  • PEM 形式の信頼された CA 証明書のファイル パス。
  • デフォルト値: ""
  • このオプションと--ssl-cert--ssl-keyを同時に設定すると、TiDB は、クライアントが証明書を提示するときに、このオプションで指定された信頼できる CA のリストに基づいてクライアント証明書を認証します。認証に失敗した場合、接続は終了します。
  • このオプションを設定してもクライアントが証明書を提示しない場合、クライアント証明書の認証なしで安全な接続が継続されます。

ssl-cert

  • PEM 形式の SSL 証明書のファイル パス。
  • デフォルト値: ""
  • このオプションと--ssl-key同時に設定すると、TiDB はクライアントが TLS を使用して TiDB に安全に接続できるようにします (強制はしません)。
  • 指定された証明書または秘密キーが無効な場合、TiDB は通常どおり起動しますが、安全な接続を受信できません。

ssl-key

  • PEM 形式の SSL 証明書キーのファイル パス、つまり--ssl-certで指定された証明書の秘密キー。
  • デフォルト値: ""
  • 現在、TiDB はパスワードで保護された秘密キーのロードをサポートしていません。

cluster-ssl-ca

  • TiKV または PD を TLS で接続するために使用される CA ルート証明書。
  • デフォルト値: ""

cluster-ssl-cert

  • TiKV または PD を TLS で接続するために使用される SSL 証明書ファイルのパス。
  • デフォルト値: ""

cluster-ssl-key

  • TiKV または PD を TLS で接続するために使用される SSL 秘密キー ファイルのパス。
  • デフォルト値: ""

spilled-file-encryption-method

  • 流出したファイルをディスクに保存するために使用される暗号化方法を決定します。
  • デフォルト値: "plaintext" 、暗号化を無効にします。
  • オプションの値: "plaintext"および"aes128-ctr"

auto-tls

  • 起動時に TLS 証明書を自動的に生成するかどうかを決定します。
  • デフォルト値: false

tls-version

  • MySQL プロトコル接続の最小 TLS バージョンを設定します。
  • デフォルト値: ""。TLSv1.1 以降が許可されます。
  • オプションの値: "TLSv1.0""TLSv1.1""TLSv1.2"および"TLSv1.3"

auth-token-jwks v6.4.0 の新機能

  • tidb_auth_token認証方法の JSON Web Key Sets (JWKS) のローカル ファイル パスを設定します。
  • デフォルト値: ""

auth-token-refresh-interval v6.4.0 の新機能

  • tidb_auth_token認証方法の JWKS 更新間隔を設定します。
  • デフォルト値: 1h

disconnect-on-expired-password v6.5.0 の新機能

  • パスワードの有効期限が切れたときに、TiDB がクライアント接続を切断するかどうかを決定します。
  • デフォルト値: true
  • オプションfalse値: true
  • これをtrueに設定すると、パスワードの有効期限が切れるとクライアント接続が切断されます。 falseに設定すると、クライアント接続は「サンドボックス モード」に制限され、ユーザーはパスワード リセット操作のみを実行できます。

session-token-signing-cert v6.4.0 の新機能

  • 証明書ファイルのパス。セッション移行のためにTiProxyによって使用されます。
  • デフォルト値: ""
  • 値が空の場合、TiProxy セッションの移行は失敗します。セッション移行を有効にするには、すべての TiDB ノードがこれを同じ証明書とキーに設定する必要があります。これは、すべての TiDB ノードに同じ証明書とキーを保存する必要があることを意味します。

session-token-signing-key v6.4.0 の新機能

パフォーマンス

パフォーマンスに関するコンフィグレーション項目。

max-procs

  • TiDB によって使用される CPU の数。
  • デフォルト値: 0
  • デフォルトの0マシン上のすべての CPU を使用することを示します。これを n に設定すると、TiDB は n 個の CPU を使用することもできます。

server-memory-quota v4.0.9 の新機能

  • tidb-server インスタンスのメモリ使用制限。
  • デフォルト値: 0 (バイト単位)。これはメモリ制限がないことを意味します。

max-txn-ttl

  • 1 つのトランザクションがロックを保持できる最長時間。この時間を超えると、トランザクションのロックが他のトランザクションによってクリアされ、このトランザクションを正常にコミットできなくなる可能性があります。
  • デフォルト値: 3600000
  • 単位: ミリ秒
  • この時間を超えてロックを保持するトランザクションは、コミットまたはロールバックのみ可能です。コミットが成功しない可能性があります。

stmt-count-limit

  • 単一の TiDB トランザクションで許可されるステートメントの最大数。
  • デフォルト値: 5000
  • ステートメントの数がstmt-count-limit超えた後にトランザクションがロールバックまたはコミットしない場合、TiDB はstatement count 5001 exceeds the transaction limitation, autocommit = falseエラーを返します。この設定は、再試行可能な楽観的トランザクションでのみ有効です。悲観的トランザクションを使用する場合、またはトランザクションの再試行を無効にしている場合、トランザクション内のステートメントの数はこの構成によって制限されません。

txn-entry-size-limit v5.0 の新機能

  • TiDB 内の 1 行のデータのサイズ制限。
  • デフォルト値: 6291456 (バイト単位)
  • トランザクション内の単一のキーと値のレコードのサイズ制限。サイズ制限を超えると、TiDB はentry too largeエラーを返します。この設定項目の最大値は125829120 (120 MB) を超えません。
  • TiKV にも同様の制限があることに注意してください。 1 回の書き込みリクエストのデータ サイズがraft-entry-max-size (デフォルトでは 8 MB) を超える場合、TiKV はこのリクエストの処理を拒否します。テーブルに大きなサイズの行がある場合は、両方の構成を同時に変更する必要があります。
  • デフォルト値のmax_allowed_packet (MySQL プロトコルのパケットの最大サイズ) は 67108864 (64 MiB) です。行がmax_allowed_packetより大きい場合、行は切り捨てられます。
  • デフォルト値のtxn-total-size-limit (TiDB の単一トランザクションのサイズ制限) は 100 MiB です。 txn-entry-size-limit値を増やして 100 MiB を超える場合は、それに応じてtxn-total-size-limit値も増やす必要があります。

txn-total-size-limit

  • TiDB の単一トランザクションのサイズ制限。
  • デフォルト値: 104857600 (バイト単位)
  • 単一トランザクションでは、キーと値のレコードの合計サイズがこの値を超えることはできません。このパラメータの最大値は1099511627776 (1 TB) です。 binlogを使用してダウンストリーム コンシューマー Kafka ( arbiterクラスターなど) にサービスを提供している場合、このパラメーターの値は1073741824 (1 GB) 以下である必要があることに注意してください。これは、Kafka が処理できる 1 つのメッセージ サイズの上限が 1 GB であるためです。それ以外の場合、この制限を超えるとエラーが返されます。
  • TiDB v6.5.0 以降のバージョンでは、この構成は推奨されなくなりました。トランザクションのメモリサイズはセッションのメモリ使用量に累積され、セッションメモリのしきい値を超えると変数tidb_mem_quota_queryが有効になります。以前のバージョンとの互換性を保つために、以前のバージョンから TiDB v6.5.0 以降にアップグレードする場合、この構成は次のように機能します。
    • この構成が設定されていないか、デフォルト値 ( 104857600 ) に設定されている場合、アップグレード後、トランザクションのメモリサイズがセッションのメモリ使用量に累積され、変数tidb_mem_quota_queryが有効になります。
    • この構成がデフォルト ( 104857600 ) に設定されていない場合でも、その構成は有効であり、単一トランザクションのサイズを制御する動作はアップグレードの前後でも変わりません。これは、トランザクションのメモリサイズがtidb_mem_quota_query変数によって制御されないことを意味します。

tcp-keep-alive

  • TCPレイヤーでkeepaliveを有効にするかどうかを決定します。
  • デフォルト値: true

tcp-no-delay

  • TCPレイヤーで TCP_NODELAY を有効にするかどうかを決定します。 TiDB を有効にすると、TCP/IP プロトコルの Nagle アルゴリズムが無効になり、小さなデータ パケットの送信が可能になり、ネットワークレイテンシーが短縮されます。これは、データの送信量が少なく、遅延の影響を受けやすいアプリケーションに適しています。
  • デフォルト値: true

cross-join

  • デフォルト値: true
  • TiDB は、デフォルトで両側テーブルの条件 ( WHEREフィールド) なしでJOINステートメントの実行をサポートします。値をfalseに設定すると、そのようなJOINステートメントが表示されたときにサーバーは実行を拒否します。

stats-lease

  • 統計の再ロード、テーブルの行数の更新、自動分析の実行が必要かどうかの確認、フィードバックを使用した統計の更新、および列の統計のロードの時間間隔。
  • デフォルト値: 3s
    • TiDB はstats-lease回の間隔で更新の統計をチェックし、更新が存在する場合はメモリに更新します。
    • TiDB は、DML によって生成された行の総数とシステム テーブルに変更された行の数を20 * stats-lease回の間隔で更新します。
    • TiDB は、自動分析が必要なテーブルとインデックスをstats-leaseの間隔でチェックします。
    • TiDB は、メモリにロードする必要がある列統計をstats-leaseの間隔でチェックします。
    • TiDB は200 * stats-leaseの間隔で、メモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。
    • TiDB は5 * stats-leaseの間隔でシステム テーブルのフィードバックを読み取り、メモリにキャッシュされた統計を更新します。
  • stats-leaseを 0 に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計を 3 秒ごとに更新します。ただし、TiDB は、次の統計関連のシステム テーブルを自動的に変更しなくなりました。
    • mysql.stats_meta : TiDB は、トランザクションによって変更されたテーブル行の数を自動的に記録し、それをこのシステム テーブルに更新しなくなりました。
    • mysql.stats_histograms / mysql.stats_bucketsおよびmysql.stats_top_n : TiDB は統計を自動的に分析し、積極的に更新しなくなりました。
    • mysql.stats_feedback : TiDB は、クエリされたデータによって返された統計の一部に従ってテーブルとインデックスの統計を更新しなくなりました。

pseudo-estimate-ratio

  • テーブル内の (変更された行数)/(総行数) の比率。この値を超えると、システムは統計の有効期限が切れたとみなして、疑似統計が使用されます。
  • デフォルト値: 0.8
  • 最小値は0 、最大値は1です。

force-priority

  • すべてのステートメントの優先順位を設定します。
  • デフォルト値: NO_PRIORITY
  • 値のオプション: デフォルト値NO_PRIORITYは、ステートメントの優先順位が強制的に変更されないことを意味します。他のオプションは昇順でLOW_PRIORITYDELAYED 、およびHIGH_PRIORITYです。
  • v6.1.0 以降、すべてのステートメントの優先順位は、TiDB 構成項目instance.tidb_force_priorityまたはシステム変数tidb_force_priorityによって決定されます。 force-priorityは引き続き有効です。ただし、 force-priorityinstance.tidb_force_priority同時に設定した場合は、後者が有効になります。

注記:

v6.6.0 以降、TiDB はリソース制御をサポートします。この機能を使用すると、異なるリソース グループで異なる優先順位で SQL ステートメントを実行できます。これらのリソース グループに適切なクォータと優先順位を構成することで、異なる優先順位を持つ SQL ステートメントのスケジュール制御を向上させることができます。リソース制御が有効になっている場合、ステートメントの優先順位は無効になります。さまざまな SQL ステートメントのリソース使用量を管理するには、 リソース制御を使用することをお勧めします。

distinct-agg-push-down

  • オプティマイザがDistinctの集計関数 ( select count(distinct a) from tなど) をコプロセッサにプッシュダウンする操作を実行するかどうかを決定します。
  • デフォルト: false
  • この変数はシステム変数tidb_opt_distinct_agg_push_downの初期値です。

enforce-mpp

  • オプティマイザのコスト見積もりを無視し、クエリ実行に TiFlash の MPP モードを強制的に使用するかどうかを決定します。
  • デフォルト値: false
  • この構成項目は、初期値tidb_enforce_mppを制御します。たとえば、この構成項目がtrueに設定されている場合、デフォルト値のtidb_enforce_mppONです。

enable-stats-cache-mem-quota v6.1.0 の新機能

  • 統計キャッシュのメモリ割り当てを有効にするかどうかを制御します。
  • デフォルト値: true

stats-load-concurrency v5.4.0 の新機能

  • TiDB 同期ロード統計機能が同時に処理できる列の最大数。
  • デフォルト値: 5
  • 現在、有効な値の範囲は[1, 128]です。

stats-load-queue-size v5.4.0 の新機能

  • TiDB 同期ロード統計機能がキャッシュできる列リクエストの最大数。
  • デフォルト値: 1000
  • 現在、有効な値の範囲は[1, 100000]です。

lite-init-stats v7.1.0 の新機能

  • TiDB の起動時に軽量統計初期化を使用するかどうかを制御します。
  • デフォルト値: v7.2.0 より前のバージョンの場合はfalse 、v7.2.0 以降のバージョンの場合はtrue
  • lite-init-statsの値がtrueの場合、統計の初期化では、インデックスまたは列のヒストグラム、TopN、または Count-Min スケッチがメモリにロードされません。 lite-init-statsの値がfalseの場合、統計の初期化では、インデックスと主キーのヒストグラム、TopN、および Count-Min スケッチがメモリにロードされますが、非主キー列のヒストグラム、TopN、または Count-Min スケッチはメモリにロードされません。オプティマイザが特定のインデックスまたは列のヒストグラム、TopN、および Count-Min スケッチを必要とする場合、必要な統計が同期または非同期でメモリにロードされます ( tidb_stats_load_sync_waitによって制御されます)。
  • lite-init-statsからtrueに設定すると、統計の初期化が高速化され、不必要な統計のロードが回避されるため、TiDBメモリの使用量が削減されます。詳細は負荷統計を参照してください。

force-init-stats v6.5.7 および v7.1.0 の新機能

  • TiDB の起動時にサービスを提供する前に、統計の初期化が完了するまで待機するかどうかを制御します。
  • デフォルト値: v7.2.0 より前のバージョンの場合はfalse 、v7.2.0 以降のバージョンの場合はtrue
  • force-init-statsの値がtrueの場合、TiDB は起動時にサービスを提供する前に、統計の初期化が完了するまで待つ必要があります。テーブルとパーティションの数が多く、 lite-init-statsの値がfalseである場合、 force-init-statsからtrueに設定すると、TiDB がサービスの提供を開始するまでにかかる時間が長くなる可能性があることに注意してください。
  • force-init-statsの値がfalseの場合、TiDB は統計の初期化が完了する前でもサービスを提供できますが、オプティマイザは擬似統計を使用して決定を行うため、最適とは言えない実行計画が生じる可能性があります。

オープントレース

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

enable

  • opentracing を有効にして、一部の TiDB コンポーネントの呼び出しオーバーヘッドをトレースします。 opentracing を有効にすると、パフォーマンスがいくらか低下することに注意してください。
  • デフォルト値: false

rpc-metrics

  • RPC メトリクスを有効にします。
  • デフォルト値: false

opentracing.sampler

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

type

  • opentracing サンプラーのタイプを指定します。文字列値では大文字と小文字が区別されません。
  • デフォルト値: "const"
  • 値のオプション: "const""probabilistic""ratelimiting""remote"

param

  • opentracing サンプラーのパラメーター。
    • constタイプの場合、値は0または1で、 constサンプラーを有効にするかどうかを示します。
    • probabilisticタイプの場合、パラメーターはサンプリング確率を指定します。これは01の浮動小数点数にすることができます。
    • ratelimitingタイプの場合、パラメータは 1 秒あたりにサンプリングされるスパンの数を指定します。
    • remoteタイプの場合、パラメーターはサンプリング確率を指定します。これは01の浮動小数点数にすることができます。
  • デフォルト値: 1.0

sampling-server-url

  • jaeger-agent サンプリングサーバーの HTTP URL。
  • デフォルト値: ""

max-operations

  • サンプラーがトレースできる操作の最大数。操作がトレースされない場合は、デフォルトの確率サンプラーが使用されます。
  • デフォルト値: 0

sampling-refresh-interval

  • jaeger-agent サンプリング ポリシーをポーリングする頻度を制御します。
  • デフォルト値: 0

opentracing.reporter

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

queue-size

  • レポーターがメモリ内で記録するキュー サイズ。
  • デフォルト値: 0

buffer-flush-interval

  • レポーターがメモリ内のスパンをstorageにフラッシュする間隔。
  • デフォルト値: 0

log-spans

  • 送信されたすべてのスパンのログを印刷するかどうかを決定します。
  • デフォルト値: false

local-agent-host-port

  • レポーターがスパンを jaeger-agent に送信するアドレス。
  • デフォルト値: ""

tikvクライアント

grpc-connection-count

  • 各 TiKV で確立される接続の最大数。
  • デフォルト値: 4

grpc-keepalive-time

  • TiDB ノードと TiKV ノード間の RPC 接続のkeepalive時間間隔。指定された時間間隔内にネットワーク パケットがない場合、gRPC クライアントは TiKV に対してpingコマンドを実行して、TiKV が生きているかどうかを確認します。
  • デフォルト: 10
  • 単位:秒

grpc-keepalive-timeout

  • TiDB ノードと TiKV ノード間の RPC keepaliveチェックのタイムアウト。
  • デフォルト値: 3
  • 単位:秒

grpc-compression-type

  • TiDB ノードと TiKV ノード間のデータ転送に使用される圧縮タイプを指定します。デフォルト値は"none"で、圧縮しないことを意味します。 gzip 圧縮を有効にするには、この値を"gzip"に設定します。
  • デフォルト値: "none"
  • "gzip"オプション: "none"

commit-timeout

  • トランザクションコミット実行時の最大タイムアウト。
  • デフォルト値: 41s
  • この値はRaft選出タイムアウトの 2 倍より大きく設定する必要があります。

max-batch-size

  • バッチで送信される RPC パケットの最大数。値が0ではない場合、 BatchCommands API を使用して TiKV にリクエストが送信され、同時実行性が高い場合には RPCレイテンシーを短縮できます。この値は変更しないことをお勧めします。
  • デフォルト値: 128

max-batch-wait-time

  • データ パケットを大きなパケットにバッチでカプセル化し、TiKV ノードに送信するまでmax-batch-wait-timeを待機します。 tikv-client.max-batch-sizeの値が0より大きい場合にのみ有効です。この値は変更しないことをお勧めします。
  • デフォルト値: 0
  • 単位: ナノ秒

batch-wait-size

  • バッチで TiKV に送信されるパケットの最大数。この値は変更しないことをお勧めします。
  • デフォルト値: 8
  • 値が0の場合、この機能は無効になります。

overload-threshold

  • TiKV 負荷のしきい値。 TiKV 負荷がこのしきい値を超えると、TiKV の圧力を軽減するためにさらにbatchパケットが収集されます。 tikv-client.max-batch-sizeの値が0より大きい場合にのみ有効です。この値は変更しないことをお勧めします。
  • デフォルト値: 200

copr-req-timeout v7.5.0 の新機能

  • 単一のコプロセッサー要求のタイムアウト。
  • デフォルト値: 60
  • 単位:秒

tikv-client.copr-cache v4.0.0 の新機能

このセクションでは、コプロセッサーキャッシュ機能に関連する設定項目を紹介します。

capacity-mb

  • キャッシュされたデータの合計サイズ。キャッシュ領域がいっぱいになると、古いキャッシュ エントリが削除されます。値が0.0の場合、コプロセッサーキャッシュ機能は無効になります。
  • デフォルト値: 1000.0
  • 単位:MB
  • タイプ: フロート

txn-ローカル-ラッチ

トランザクションラッチに関するコンフィグレーション。ローカル トランザクションの競合が多数発生する場合は、これを有効にすることをお勧めします。

enabled

  • トランザクションのメモリロックを有効にするかどうかを決定します。
  • デフォルト値: false

capacity

  • ハッシュに対応するスロットの数。2 の指数倍に自動的に調整されます。各スロットは 32 バイトのメモリを占有します。設定が小さすぎると、データの書き込みが比較的広い範囲をカバーするシナリオ (データのインポートなど) で、実行速度が遅くなり、パフォーマンスが低下する可能性があります。
  • デフォルト値: 2048000

binlog

TiDB Binlogに関連する構成。

enable

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

write-timeout

  • Pumpへのbinlog の書き込みのタイムアウト。この値を変更することはお勧めできません。
  • デフォルト: 15s
  • 単位:秒

ignore-error

  • binlog をPumpに書き込むプロセスで発生したエラーを無視するかどうかを決定します。この値を変更することはお勧めできません。
  • デフォルト値: false
  • 値がtrueに設定され、エラーが発生すると、TiDB はbinlogの書き込みを停止し、 tidb_server_critical_error_total監視項目のカウントに1追加します。値がfalseに設定されている場合、binlogの書き込みは失敗し、TiDB サービス全体が停止します。

binlog-socket

  • binlogがエクスポートされるネットワーク アドレス。
  • デフォルト値: ""

strategy

  • binlogをエクスポートするときのPump選択の戦略。現在、 hashrange方法のみがサポートされています。
  • デフォルト値: range

状態

TiDB サービスのステータスに関連するコンフィグレーション。

report-status

  • HTTP API サービスを有効または無効にします。
  • デフォルト値: true

record-db-qps

  • データベース関連の QPS メトリクスを Prometheus に送信するかどうかを決定します。
  • デフォルト値: false

record-db-label

  • データベース関連の QPS メトリクスを Prometheus に送信するかどうかを決定します。
  • 期間やステートメントなど、 record-db-qpsよりも多くのメトリック タイプをサポートします。
  • デフォルト値: false

pessimistic-txn

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

max-retry-count

  • 悲観的トランザクションにおける各ステートメントの最大再試行回数。再試行回数がこの制限を超えると、エラーが発生します。
  • デフォルト値: 256

deadlock-history-capacity

  • 単一の TiDBサーバーのINFORMATION_SCHEMA.DEADLOCKSテーブルに記録できるデッドロック イベントの最大数。このテーブルがフルボリュームで、追加のデッドロック イベントが発生した場合、テーブル内の最も古いレコードが削除されて、最新のエラーが配置されます。
  • デフォルト値: 10
  • 最小値: 0
  • 最大値: 10000

deadlock-history-collect-retryable

pessimistic-auto-commitv6.0.0 の新機能

  • 悲観的トランザクション モードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっている場合でも、自動コミット トランザクションは依然として楽観的トランザクション モードを使用します。 pessimistic-auto-commit ( trueに設定) を有効にすると、自動コミット トランザクションも悲観的モードを使用します。これは、明示的にコミットされた他の悲観的トランザクションと一貫性があります。
  • 競合が発生するシナリオの場合、この構成を有効にした後、TiDB はグローバルなロック待機管理に自動コミット トランザクションを組み込みます。これにより、デッドロックが回避され、デッドロックの原因となる競合によってもたらされるレイテンシーのスパイクが軽減されます。
  • 競合のないシナリオの場合、自動コミット トランザクションが多数ある場合 (具体的な数は実際のシナリオによって決まります。たとえば、自動コミット トランザクションの数がアプリケーションの総数の半分以上を占めます)、単一トランザクションは大量のデータを処理するため、この構成を有効にするとパフォーマンスが低下します。たとえば、auto-commit INSERT INTO SELECTステートメントです。
  • デフォルト値: false

constraint-check-in-place-pessimisticv6.4.0 の新機能

分離読み取り

読み取り分離に関するコンフィグレーション項目。

engines

  • TiDB がどのエンジンからデータを読み取ることができるかを制御します。
  • デフォルト値: ["tikv", "tiflash", "tidb"]、エンジンがオプティマイザによって自動的に選択されることを示します。
  • 値のオプション: 「tikv」、「tiflash」、および「tidb」の任意の組み合わせ (例: ["tikv", "tidb"] または ["tiflash", "tidb"])

実例

tidb_enable_collect_execution_info

  • この構成は、各オペレーターの実行情報をスロークエリーログに記録するかどうかを制御します。
  • デフォルト値: true
  • v6.1.0 より前では、この構成はenable-collect-execution-infoによって設定されます。

tidb_enable_slow_log

  • この構成は、スロー ログ機能を有効にするかどうかを制御するために使用されます。
  • デフォルト値: true
  • 値のオプション: trueまたはfalse
  • v6.1.0 より前では、この構成はenable-slow-logによって設定されます。

tidb_slow_log_threshold

  • この設定は、スローログの消費時間の閾値を出力するために使用されます。クエリの所要時間がこの値よりも長い場合、そのクエリはスローログとみなされ、スロークエリログにログが出力されます。
  • デフォルト値: 300
  • 範囲: [-1, 9223372036854775807]
  • 単位: ミリ秒
  • v6.1.0 より前では、この構成はslow-thresholdによって設定されます。

in-mem-slow-query-topn-num v7.3.0 の新機能

  • この構成は、メモリにキャッシュされる最も遅いクエリの数を制御します。
  • デフォルト値: 30

in-mem-slow-query-recent-num v7.3.0 の新機能

  • この構成は、メモリにキャッシュされる、最近使用された低速クエリの数を制御します。
  • デフォルト値: 500

tidb_expensive_query_time_threshold

  • この構成は、高価なクエリ ログを印刷するかどうかを決定するしきい値を設定するために使用されます。高価なクエリ ログと低速なクエリ ログの違いは次のとおりです。
    • スローログはステートメントの実行後に出力されます。
    • 負荷の高いクエリ ログには、実行時間がしきい値を超えて実行されているステートメントとその関連情報が出力されます。
  • デフォルト値: 60
  • 範囲: [10, 2147483647]
  • 単位: 秒
  • v5.4.0 より前では、この構成はexpensive-thresholdによって設定されます。

tidb_record_plan_in_slow_log

  • この構成は、低速クエリの実行計画を低速ログに含めるかどうかを制御するために使用されます。
  • デフォルト値: 1
  • 値のオプション: 1 (有効、デフォルト) または0 (無効)。
  • この設定の値はシステム変数tidb_record_plan_in_slow_logの値を初期化します。
  • v6.1.0 より前では、この構成はrecord-plan-in-slow-logによって設定されます。

tidb_force_priority

  • この設定は、TiDBサーバー上で実行されるステートメントのデフォルトの優先順位を変更するために使用されます。
  • デフォルト値: NO_PRIORITY
  • デフォルト値NO_PRIORITYは、ステートメントの優先順位が強制的に変更されないことを意味します。他のオプションは昇順でLOW_PRIORITYDELAYED 、およびHIGH_PRIORITYです。
  • v6.1.0 より前では、この構成はforce-priorityによって設定されます。

注記:

v6.6.0 以降、TiDB はリソース制御をサポートします。この機能を使用すると、異なるリソース グループで異なる優先順位で SQL ステートメントを実行できます。これらのリソース グループに適切なクォータと優先順位を構成することで、異なる優先順位を持つ SQL ステートメントのスケジュール制御を向上させることができます。リソース制御が有効になっている場合、ステートメントの優先順位は無効になります。さまざまな SQL ステートメントのリソース使用量を管理するには、 リソース制御を使用することをお勧めします。

max_connections

  • 単一の TiDB インスタンスに許可される接続の最大数。リソース制御に使用できます。
  • デフォルト値: 0
  • 範囲: [0, 100000]
  • デフォルト値0は制限がないことを意味します。この変数の値が0より大きく、接続数がその値に達すると、TiDBサーバーはクライアントからの新しい接続を拒否します。
  • この設定の値はシステム変数max_connectionsの値を初期化します。
  • v6.2.0 より前では、この構成はmax-server-connectionsによって設定されます。

tidb_enable_ddl

  • この構成は、対応する TiDB インスタンスが DDL 所有者になれるかどうかを制御します。
  • デフォルト値: true
  • 可能な値: OFFON
  • この設定の値はシステム変数tidb_enable_ddlの値を初期化します。
  • v6.3.0 より前では、この構成はrun-ddlによって設定されます。

tidb_stmt_summary_enable_persistent v6.6.0 の新機能

  • ステートメントの概要の永続性を有効にするかどうかを制御します。
  • デフォルト値: false
  • 詳細については、 永続化ステートメントの概要を参照してください。

tidb_stmt_summary_filename v6.6.0 の新機能

  • ステートメントの概要の永続性が有効になっている場合、この構成は永続データが書き込まれるファイルを指定します。
  • デフォルト値: tidb-statements.log

tidb_stmt_summary_file_max_days v6.6.0 の新機能

  • ステートメント概要の永続性が有効になっている場合、この構成は永続データ ファイルを保持する最大日数を指定します。
  • デフォルト値: 3
  • 単位:日
  • データ保持要件とディスク領域の使用量に基づいて値を調整できます。

tidb_stmt_summary_file_max_size v6.6.0 の新機能

  • ステートメント概要の永続性が有効になっている場合、この構成は永続データ ファイルの最大サイズを指定します。
  • デフォルト値: 64
  • 単位: MiB
  • データ保持要件とディスク領域の使用量に基づいて値を調整できます。

tidb_stmt_summary_file_max_backups v6.6.0 の新機能

  • ステートメント概要の永続化が有効になっている場合、この構成では、永続化できるデータ ファイルの最大数を指定します。 0ファイル数に制限がないことを意味します。
  • デフォルト値: 0
  • データ保持要件とディスク領域の使用量に基づいて値を調整できます。

プロキシプロトコル

PROXYプロトコルに関するコンフィグレーション項目。

networks

  • プロキシプロトコルを使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト
  • デフォルト値: ""
  • 一般に、リバース プロキシの背後で TiDB にアクセスすると、TiDB はリバース プロキシサーバーの IP アドレスをクライアントの IP アドレスとして取得します。 PROXY プロトコルを有効にすることにより、このプロトコルをサポートするリバース プロキシ (HAProxy など) は、実際のクライアント IP アドレスを TiDB に渡すことができます。
  • このパラメーターを構成すると、TiDB は、構成された送信元 IP アドレスが PROXY プロトコルを使用して TiDB に接続できるようにします。 PROXY 以外のプロトコルが使用されている場合、この接続は拒否されます。このパラメータを空のままにすると、PROXY プロトコルを使用して IP アドレスが TiDB に接続できなくなります。値には、区切り文字として,を使用した IP アドレス (192.168.1.50) または CIDR (192.168.1.0/24) を指定できます。 *任意の IP アドレスを意味します。

fallbackable v6.5.1 の新機能

  • PROXY プロトコル フォールバック モードを有効にするかどうかを制御します。この構成項目がtrueに設定されている場合、TiDB は、PROXY プロトコル仕様を使用せず、または PROXY プロトコル ヘッダーを送信せずに、 proxy-protocol.networksに属するクライアントによる TiDB への接続を受け入れることができます。デフォルトでは、TiDB はproxy-protocol.networksに属し、PROXY プロトコル ヘッダーを送信するクライアント接続のみを受け入れます。
  • デフォルト値: false

実験的

v3.1.0 で導入されたexperimentalセクションでは、TiDB の実験的機能に関連する構成について説明します。

allow-expression-index v4.0.0 の新機能

  • 式インデックスを作成できるかどうかを制御します。 TiDB v5.2.0 以降、式内の関数が安全であれば、この構成を有効にしなくても、この関数に基づいて式インデックスを直接作成できます。他の関数に基づいて式インデックスを作成する場合は、この構成を有効にできますが、正確性の問題が発生する可能性があります。 tidb_allow_function_for_expression_index変数をクエリすると、式の作成に直接使用しても安全な関数を取得できます。
  • デフォルト値: false

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

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.