FE 設定 - 認証、クエリ、およびロード
FE パラメータは、動的パラメータと静的パラメータに分類されます。
-
動的パラメータは、SQL コマンドを実行することで設定および調整でき、非常に便利です。ただし、FE を再起動すると設定が無効になります。そのため、fe.conf ファイルの設定項目も変更して、変更が失われないようにすることをお勧めします。
-
静的パラメータは、FE の設定ファイル fe.conf でのみ設定および調整できます。このファイルを変更した後、変更を有効にするには FE を再起動する必要があります。
パラメータが動的パラメータであるかどうかは、ADMIN SHOW CONFIG の出力の IsMutable 列で示されます。TRUE は動的パラメータを示します。
動的および静的 FE パラメータの両方が fe.conf ファイルで設定できることに注意してください。
FE 設定項目の表示
FE の起動後、MySQL クライアントで ADMIN SHOW FRONTEND CONFIG コマンドを実行して、パラメーター設定を確認できます。特定のパラメーターの設定をクエリするには、次のコマンドを実行します。
ADMIN SHOW FRONTEND CONFIG [LIKE "pattern"];
返されるフィールドの詳細な説明については、ADMIN SHOW CONFIG を参照してください。
クラスター管理関連コマンドを実行するには、管理者権限が必要です。
FE パラメーターの設定
FE 動的パラメーターの設定
ADMIN SET FRONTEND CONFIG を使用して、FE 動的パラメーターの設定を構成または変更できます。
ADMIN SET FRONTEND CONFIG ("key" = "value");
ADMIN SET FRONTEND で行った設定変更は、FE が再起動すると fe.conf ファイルのデフォルト値に戻ります。したがって、変更を永続的にしたい場合は、fe.conf の設定項目も変更することをお勧めします。
FE 静的パラメーターの設定
FE の静的パラメータは、設定ファイル fe.conf を変更し、FE を再起動して変更を反映させることで設定されます。
このトピックでは、以下の種類のFE構成について紹介します:
ユーザー、ロール、権限
enable_task_info_mask_credential
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:true の場合、StarRocks は
information_schema.tasksおよびinformation_schema.task_runsで返される前に、タスク SQL 定義から資格情報を編集します。これは、DEFINITION 列に SqlCredentialRedactor.redact を適用することで行われます。information_schema.task_runsでは、定義がタ スク実行ステータスから来るか、空の場合にタスク定義ルックアップから来るかに関係なく、同じ編集が適用されます。false の場合、生のタスク定義が返されます (資格情報が公開される可能性があります)。マスキングは CPU/文字列処理作業であり、タスクまたはtask_runsの数が大きい場合は時間がかかる場合があります。非編集定義が必要であり、セキュリティリスクを受け入れる場合にのみ無効にしてください。 - 導入時期:v3.5.6
privilege_max_role_depth
- デフォルト:16
- タイプ:Int
- Unit:
- 変更可能:Yes
- 説明:ロールの最大ロール深度 (継承レベル)。
- 導入時期:v3.0.0
privilege_max_total_roles_per_user
- デフォルト:64
- タイプ:Int
- Unit:
- 変更可能:Yes
- 説明:ユーザーが持つことができるロールの最大数。
- 導入時期:v3.0.0
クエリエンジン
brpc_send_plan_fragment_timeout_ms
- デフォルト:60000
- タイプ:Int
- 単位:Milliseconds
- 変更可能:Yes
- 説明:プランフラグメントを送信する前に BRPC TalkTimeoutController に適用されるタイムアウト (ミリ秒単位)。
BackendServiceClient.sendPlanFragmentAsyncは、バックエンドexecPlanFragmentAsyncを呼び出す前にこの値を設定します。これは、BRPC がアイドル接続を接続プールから借りる際や送信を実行する際に待機する期間を管理します。超過した場合、RPC は失敗し、メソッドの再試行ロジックをトリガーする可能性があります。競合時に迅速に失敗させるにはこれを低く設定し、一時的なプール枯渇や低速ネットワークを許容するには高く設定します。注意: 非常に大きな値は、失敗検出を遅延させ、要求スレッドをブロックする可能性があります。 - 導入時期:v3.3.11, v3.4.1, v3.5.0
connector_table_query_trigger_analyze_large_table_interval
- デフォルト:12 * 3600
- タイプ:Int
- 単位:Second
- 変更可能:Yes
- 説明:大規模テーブルのクエリトリガー ANALYZE タスクの間隔。
- 導入時期:v3.4.0
connector_table_query_trigger_analyze_max_pending_task_num
- デフォルト:100
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:FE で保留状態にあるクエリトリガー ANALYZE タスクの最大数。
- 導入時期:v3.4.0
connector_table_query_trigger_analyze_max_running_task_num
- デフォルト:2
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:FE で実行状態にあるクエリトリガー ANALYZE タスクの最大数。
- 導入時期:v3.4.0
connector_table_query_trigger_analyze_small_table_interval
- デフォルト:2 * 3600
- タイプ:Int
- 単位:Second
- 変更可能:Yes
- 説明:小規模テーブルのクエリトリガー ANALYZE タスクの間隔。
- 導入時期:v3.4.0
connector_table_query_trigger_analyze_small_table_rows
- デフォルト:10000000
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:クエリトリガー ANALYZE タスクのテーブルが小規模テーブルであるかどうかを判断するためのしきい値。
- 導入時期:v3.4.0
connector_table_query_trigger_task_schedule_interval
- デフォルト:30
- タイプ:Int
- 単位:Second
- 変更可能:Yes
- 説明 :スケジューラースレッドがクエリトリガーバックグラウンドタスクをスケジュールする間隔。この項目は v3.4.0 で導入された
connector_table_query_trigger_analyze_schedule_intervalを置き換えるものです。ここで、バックグラウンドタスクとは v3.4 のANALYZEタスクと、v3.4 以降の低カーディナリティ列の辞書収集タスクを指します。 - 導入時期:v3.4.2
create_table_max_serial_replicas
- デフォルト:128
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:シリアルに作成するレプリカの最大数。実際のレプリカ数がこの値を超えると、レプリカは並行して作成されます。テーブル作成に時間がかかりすぎる場合は、この値を減らしてみてください。
- 導入時期:-
default_mv_partition_refresh_number
- デフォルト:1
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:マテリアライズドビューの更新が複数のパーティションを伴う場合、このパラメーターは、デフォルトで 1 つのバッチで更新される パーティションの数を制御します。 バージョン 3.3.0 以降、システムはデフォルトで一度に 1 つのパーティションを更新して、潜在的なメモリ不足 (OOM) の問題を回避します。以前のバージョンでは、デフォルトですべてのパーティションが一度に更新され、メモリ枯渇やタスク障害につながる可能性がありました。ただし、マテリアライズドビューの更新が多数のパーティションを伴う場合、一度に 1 つのパーティションのみを更新すると、スケジューリングのオーバーヘッドが過剰になり、全体の更新時間が長くなり、大量の更新レコードが生成される可能性があることに注意してください。そのような場合は、更新効率を向上させ、スケジューリングコストを削減するために、このパラメーターを適切に調整することをお勧めします。
- 導入時期:v3.3.0
default_mv_refresh_immediate
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:非同期マテリアライズドビューの作成後すぐに更新するかどうか。この項目が
trueに設定されている場合、新しく作成されたマテリアライズドビューはすぐに更新されます。 - 導入時期:v3.2.3
dynamic_partition_check_interval_seconds
- デフォルト:600
- タイプ:Long
- 単位:Seconds
- 変更可能:Yes
- 説明:新しいデータがチェックされる間隔。新しいデータが検出された場合、StarRocks は自動的にデータ用のパーティションを作成します。
- 導入時期:-
dynamic_partition_enable
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:動的パーティショニング機能を有効にするかどうか。この機能が有効になっている場合、StarRocks は新しいデータ用のパーティションを動的に作成し、期限切れのパーティションを自動的に削除してデータの鮮度を保証します。
- 導入時期:-
enable_active_materialized_view_schema_strict_check
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説 明:非アクティブなマテリアライズドビューをアクティブ化するときに、データ型の長さの一貫性を厳密にチェックするかどうか。この項目が
falseに設定されている場合、基底テーブルでデータ型の長さが変更されても、マテリアライズドビューのアクティブ化は影響を受けません。 - 導入時期:v3.3.4
mv_fast_schema_change_mode
- デフォルト: strict
- タイプ: String
- 単位: -
- 可変: はい
- 説明: マテリアライズドビュー (MV) の高速スキーマ進化 (FSE) の動作を制御します。有効な値は次のとおりです:
strict(デフォルト) -isSupportFastSchemaEvolutionInDangerが true の場合にのみ FSE を許可し、影響を受けるパーティションエントリをバージョンマップからクリアします。force-isSupportFastSchemaEvolutionInDangerが false の場合でも FSE を許可し、影響を受けるパーティションエントリをクリアしてリフレッシュ時に再計算をトリガーします。force_no_clear-isSupportFastSchemaEvolutionInDangerが false の場合でも FSE を許可しますが、パーティションエントリはクリアしません。 - 導入バージョン: v3.4.0