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

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

check-mb4-value-in-utf8

  • utf8mb4文字のチェックを有効にするかどうかを決定します。この機能を有効にすると、文字セットがutf8で、 mb4文字がutf8に挿入されると、エラーが返されます。
  • デフォルト値: false
  • v6.1.0 以降、 utf8mb4文字チェックを有効にするかどうかは、TiDB 構成項目instance.tidb_check_mb4_value_in_utf8またはシステム変数tidb_check_mb4_value_in_utf8によって決定されます。7 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 ノードは、現在の TiDB バージョンを確認するために値server-versionを使用します。したがって、予期しない動作を回避するには、TiDB クラスターをアップグレードする前に、値server-versionを空または現在の TiDB クラスターの実際のバージョンに設定する必要があります。

repair-mode

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

repair-table-list

  • repair-table-listrepair-modetrueに設定されている場合にのみ有効です。 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 で許可される同時クライアント接続の最大数を設定します。5 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 の新機能

  • グローバル キル (インスタンス間のクエリまたは接続の終了) 機能を有効にするかどうかを制御します。
  • デフォルト値: 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

  • ログ出力レベルを指定します。
  • warn info fatal : debug error
  • デフォルト値: info

format

  • ログ出力形式を指定します。
  • 値のオプション: jsontext
  • デフォルト値: 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構成は削除されます。3 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によって決定されます。5 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
  • 単位: ミリ秒
  • クエリの消費時間がこの値より大きい場合、このクエリはスロークエリとみなされ、そのログはスロークエリログに出力されます。出力レベルlog.level"debug"の場合、このパラメータの設定に関係なく、すべてのクエリがスロークエリログに記録されることに注意してください。
  • v6.1.0 以降、スロー ログの消費時間のしきい値は、TiDB 構成項目instance.tidb_slow_log_thresholdまたはシステム変数tidb_slow_log_thresholdで指定されます。5 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によって決定されます。5 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

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

cluster-ssl-cert

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

cluster-ssl-key

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

spilled-file-encryption-method

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

auto-tls

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

tls-version

  • MySQL プロトコル接続の最小 TLS バージョンを設定します。
  • デフォルト値: ""、TLSv1.1 以上を許可します。
  • "TLSv1.1" "TLSv1.2" "TLSv1.3" "TLSv1.0"

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

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

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

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

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

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

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

  • セッション移行のためにTiプロキシで使用される証明書ファイル パス。
  • デフォルト値: ""
  • 値が空の場合、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

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

stmt-count-limit

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

txn-entry-size-limit v4.0.10 および v5.0.0 の新機能

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

txn-total-size-limit

  • TiDB における単一トランザクションのサイズ制限。
  • デフォルト値: 104857600 (バイト単位)
  • 1 回のトランザクションで、キー値レコードの合計サイズはこの値を超えることはできません。このパラメータの最大値は1099511627776 (1 TB) です。下流のコンシューマー Kafka ( arbiterクラスターなど) にbinlogを使用した場合、このパラメータの値は1073741824 (1 GB) 以下にする必要があります。これは、1 GB が Kafka が処理できる単一のメッセージ サイズの上限であるためです。それ以外の場合、この制限を超えるとエラーが返されます。
  • 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 は、デフォルトで両側のテーブルの条件なしのJOINステートメント ( WHEREフィールド) の実行をサポートしています。値をfalseに設定すると、サーバーはそのようなJOINステートメントが出現したときに実行を拒否します。

注記:

クラスターを作成するときは、 cross-join false に設定しないでください。そうしないと、クラスターの起動に失敗します。

stats-lease

  • 統計の再読み込み、テーブル行数の更新、自動分析を実行する必要があるかどうかの確認、フィードバックを使用した統計の更新、列の統計の読み込みの時間間隔。
  • デフォルト値: 3s
    • TiDB はstats-lease間隔で統計情報をチェックし、更新が存在する場合はそれをメモリに更新します。
    • TiDB は、 20 * stats-lease時間間隔で、DML によって生成された行の合計数と変更された行の数をシステム テーブルに更新します。
    • TiDB はstats-lease間隔で、自動的に分析する必要があるテーブルとインデックスをチェックします。
    • stats-lease間隔で、TiDB はメモリにロードする必要がある列統計をチェックします。
    • 200 * stats-lease間隔で、TiDB はメモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。
    • 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_PRIORITYDELAYEDHIGH_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]です。

concurrently-init-stats v8.1.0 および v7.5.2 の新機能

  • TiDB の起動時に統計を同時に初期化するかどうかを制御します。
  • デフォルト値: false

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

  • TiDB の起動時に軽量統計初期化を使用するかどうかを制御します。
  • デフォルト値: v7.2.0 より前のバージョンの場合はfalse 、v7.2.0 以降のバージョンの場合はtrue
  • lite-init-statsの値がtrueの場合、統計の初期化では、インデックスまたは列のヒストグラム、TopN、または Count-Min Sketch はメモリにロードされません。 lite-init-statsの値がfalseの場合、統計の初期化では、インデックスと主キーのヒストグラム、TopN、および Count-Min Sketch はメモリにロードされますが、主キー以外の列のヒストグラム、TopN、または Count-Min Sketch はメモリにロードされません。 オプティマイザーが特定のインデックスまたは列のヒストグラム、TopN、および Count-Min Sketch を必要とする場合、必要な統計は同期的または非同期的にメモリにロードされます ( 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

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

rpc-metrics

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

opentracing.サンプラー

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

type

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

param

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

sampling-server-url

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

max-operations

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

sampling-refresh-interval

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

オープントレーシングレポーター

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

queue-size

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

buffer-flush-interval

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

log-spans

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

local-agent-host-port

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

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

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

batch-wait-size

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

overload-threshold

  • TiKV 負荷のしきい値。TiKV 負荷がこのしきい値を超えると、TiKV の負荷を軽減するために0さらにbatchパケットが収集されます。3 の値がtikv-client.max-batch-sizeより大きい場合にのみ有効です。この値を変更しないことをお勧めします。
  • デフォルト値: 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]
  • 単位: ミリ秒
  • クエリの消費時間がこの値より大きい場合、このクエリはスロークエリとみなされ、そのログはスロークエリログに出力されます。出力レベルlog.level"debug"の場合、このパラメータの設定に関係なく、すべてのクエリがスロークエリログに記録されることに注意してください。
  • 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_PRIORITYDELAYEDHIGH_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 の新機能

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

プロキシプロトコル

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

networks

  • PROXYプロトコルを使用してTiDBに接続できるプロキシサーバーのIPアドレスのリスト
  • デフォルト値: ""
  • 通常、リバース プロキシの背後で TiDB にアクセスすると、TiDB はリバース プロキシサーバーの IP アドレスをクライアントの IP アドレスとして取得します。PROXY プロトコルを有効にすると、このプロトコルをサポートする HAProxy などのリバース プロキシは、実際のクライアント IP アドレスを TiDB に渡すことができます。
  • このパラメータを設定すると、TiDB は設定されたソース IP アドレスが PROXY プロトコルを使用して TiDB に接続できるようにします。PROXY 以外のプロトコルが使用されている場合、この接続は拒否されます。このパラメータを空のままにすると、どの IP アドレスも PROXY プロトコルを使用して TiDB に接続できません。値には、 ,を区切り文字として IP アドレス (192.168.1.50) または CIDR (192.168.1.0/24) を指定できます。3 *任意の 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することができますが、正確性の問題が発生する可能性があります。1 変数をクエリすると、式の作成に直接使用しても安全な関数を取得できます。
  • デフォルト値: false

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