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_collect_warehouse_metrics
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:この項目が
trueに設定されている場合、システムはウェアハウスごとのメトリックを収集してエクスポートします。これを有効にすると、ウェアハウスレベルのメトリック (スロット/使用量/可用性) がメトリック出力に追加され、メトリックのカーディナリティと収集オーバーヘッドが増加します。ウェアハウス固有のメトリックを省略し、CPU/ネットワークと監視ストレージコストを削減するには無効にします。 - 導入時期:v3.5.0
enable_http_detail_metrics
- デフォルト:false
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:true の場合、HTTP サーバーは詳細な HTTP ワーカーメトリック (特に
HTTP_WORKER_PENDING_TASKS_NUMゲージ) を計算して公開します。これを有効にすると、サーバーは Netty ワーカーエクゼキューターを反復処理し、各NioEventLoopでpendingTasks()を呼び出して保留中のタスクカウントを合計します。無効の場合、ゲージはコストを回避するために 0 を返します。この追加の収集は CPU およびレイテンシーに敏感である可能性があるため、デバッグまたは詳細な調査のためにのみ有効にしてください。 - 導入時期:v3.2.3
proc_profile_collect_time_s
- デフォルト:120
- タイプ:Int
- 単位:Seconds
- 変更可能:Yes
- 説明:単一プロセスプロファイル収集の期間 (秒単位)。
proc_profile_cpu_enableまたはproc_profile_mem_enableがtrueに設定されている場合、AsyncProfiler が起動し、コレクタースレッドはこの期間だけスリープし、その後プロファイラーが停止してプロファイルが書き込まれます。値が大きいほどサンプルカバレッジとファイルサイズは増加しますが、プロファイラーの実行時間が長くなり、その後の収集が遅れます。値が小さいほどオーバーヘッドは減少しますが、不十分なサンプルが生成される可能性があります。proc_profile_file_retained_daysやproc_profile_file_retained_size_bytesなどの保持設定とこの値が一致していることを確認してください。 - 導入時期:v3.2.12
ストレージ
alter_table_timeout_second
- デフォルト:86400
- タイプ:Int
- 単位:Seconds
- 変更可能:Yes
- 説明:スキーマ変更操作 (ALTER TABLE) のタイムアウト期間。
- 導入時期:-
capacity_used_percent_high_water
- デフォルト:0.75
- タイプ:double
- 単位:Fraction (0.0–1.0)
- 変更可能:Yes
- 説明:バックエンド負荷スコアを計算する際に使用されるディスク容量使用率 (総容量に対する割合) の高水位しきい値。
BackendLoadStatistic.calcSoreはcapacity_used_percent_high_waterを使用してLoadScore.capacityCoefficientを設定します。バックエンドの使用率が 0.5 未満の場合、係数は 0.5 になります。使用率がcapacity_used_percent_high_waterを超える場合、係数は 1.0 になります。それ以外の場合、係数は使用率に応じて線形に推移します (2 * usedPercent - 0.5)。係数が 1.0 の場合、負荷スコアは完全に容量比率によって決定されます。値が低いほどレプリカ数の重みが増加します。この値を調整すると、バランサーがディスク使用率の高いバックエンドにペナルティを課す積極性が変わります。 - 導入時期:v3.2.0
catalog_trash_expire_second
- デフォルト:86400
- タイプ:Long
- 単位:Seconds
- 変更可能:Yes
- 説明:データベース、テーブル、またはパーティションが削除された後にメタデータが保持される最長期間。この期間が経過すると、データは削除され、RECOVER コマンドで回復することはできません。
- 導入時期:-
catalog_recycle_bin_erase_min_latency_ms
- デフォルト:600000
- タイプ:Long
- 単位:Milliseconds
- 変更可能:Yes
- 説明:データベース、テーブル、またはパーティションが削除された際にメタデータが消去されるまでの最小遅延時間(ミリ秒単位)。これにより、削除ログよりも先に消去ログが書き込まれることを回避します。
- 導入時期:-
catalog_recycle_bin_erase_max_operations_per_cycle
- デフォルト:500
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:リサイクルビンからデータベース、テーブル、またはパーティションを実際に削除する操作における、1 サイクルあたりの最大消去回数。消去操作はロックを保持するため、1 バッチのサイズが大きくなりすぎないようにしてください。
- 導入時期:-
catalog_recycle_bin_erase_fail_retry_interval_ms
- デフォルト:60000
- タイプ:Long
- 単位:Milliseconds
- 変更可能:Yes
- 説明:リサイクルビン内の削除操作が失敗した場合の再試行間隔(ミリ秒単位)。
- 導入時期:-
check_consistency_default_timeout_second
- デフォルト:600
- タイプ:Long
- 単位:Seconds
- 変更可能:Yes
- 説明:レプリカの一貫性チェックのタイムアウト期間。タブレットのサイズに基づいてこのパラメーターを設定できます。
- 導入時期:-
consistency_check_cooldown_time_second
- デフォルト:24 * 3600
- タイプ:Int
- 単位:Seconds
- 変更可能:Yes
- 説明:同じタブレットの一貫性チェック間で必要な最小間隔 (秒単位) を制御します。タブレット選択中、タブレットは
tablet.getLastCheckTime()が(currentTimeMillis - consistency_check_cooldown_time_second * 1000)未満の場合にのみ適格と見なされます。デフォルト値 (24 * 3600) は、バックエンドのディスク I/O を減らすために、タブレットごとに約 1 日に 1 回のチェックを強制します。この値を減らすとチェック頻度とリソース使用量が増加し、増やすと不整合の検出が遅れる代わりに I/O が減少します。この値は、インデックスのタブレットリストからクールダウンしたタブレットをフィルタリングする際にグローバルに適用されます。 - 導入時期:v3.5.5
consistency_check_end_time
- デフォルト:"4"
- タイプ:String
- 単位:Hour of day (0-23)
- 変更可能:No
- 説明:ConsistencyChecker の作業ウィンドウの終了時間 (時、0-23) を指定します。値はシステムタイムゾーンの SimpleDateFormat("HH") で解析され、0-23 (1 桁または 2 桁) として受け入れられます。StarRocks はこれを
consistency_check_start_timeとともに使用して、一貫性チェックジョブをスケジュールして追加する時期を決定します。consistency_check_start_timeがconsistency_check_end_timeより大きい場合、ウィンドウは深夜をまたぎます (たとえば、デフォルトはconsistency_check_start_time= "23" からconsistency_check_end_time= "4")。consistency_check_start_timeがconsistency_check_end_timeと等しい場合、チェッカーは実行されません。解析に失敗すると FE の起動がエラーをログに記録して終了するため、有効な時刻文字列を指定してください。 - 導入時期:v3.2.0
consistency_check_start_time
- デフォルト:"23"
- タイプ:String
- 単位:Hour of day (00-23)
- 変更可能:No
- 説明:ConsistencyChecker の作業ウィンドウの開始時間 (時、00-23) を指定します。値はシステムタイムゾーンの SimpleDateFormat("HH") で解析され、0-23 (1 桁または 2 桁) として受け入れられます。StarRocks はこれを
consistency_check_end_timeとともに使用して、一貫性チェックジョブをスケジュールして追加する時期を決定します。consistency_check_start_timeがconsistency_check_end_timeより大きい場合、ウィンドウは深夜をまたぎます (たとえば、デフォルトはconsistency_check_start_time= "23" からconsistency_check_end_time= "4")。consistency_check_start_timeがconsistency_check_end_timeと等しい場合、チェッカーは実行されません。解析に失敗すると FE の起動がエラーをログに記録して終了するため、有効な時刻文字列を指定してください。 - 導入時期:v3.2.0
consistency_tablet_meta_check_interval_ms
- デフォルト:2 * 3600 * 1000
- タイプ:Int
- 単位:Milliseconds
- 変更可能:Yes
- 説明:ConsistencyChecker が
TabletInvertedIndexとLocalMetastoreの間の完全なタブレットメタの一貫性スキャンを実行するために使用する間隔 (ミリ秒)。runAfterCatalogReadyのデーモンは、現在の時間 - lastTabletMetaCheckTimeがこの値を超えたときに checkTabletMetaConsistency をトリガーします。無効なタブレットが最初に検出された場合、そのtoBeCleanedTimeはnow + (consistency_tablet_meta_check_interval_ms / 2)に設定されるため、実際の削除は後続のスキャンまで遅延されます。この値を増やすとスキャン頻度と負荷が減少し (クリーンアップが遅くなる)、減らすと古いタブレットの検出と削除が高速化されます (オーバーヘッドが増加する)。 - 導入時期:v3.2.0
default_replication_num
- デフォルト:3
- タイプ:Short
- 単位:-
- 変更可能:Yes
- 説明:StarRocks でテーブルを作成する際に、各データパーティションのレプリカのデフォルト数を設定します。この設定 は、CREATE TABLE DDL で
replication_num=xを指定することで、テーブル作成時に上書きできます。 - 導入時期:-
enable_auto_tablet_distribution
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:バケット数を自動的に設定するかどうか。
- このパラメーターが
TRUEに設定されている場合、テーブルを作成したりパーティションを追加したりする際にバケット数を指定する必要はありません。StarRocks は自動的にバケット数を決定します。 - このパラメーターが
FALSEに設定されている場合、テーブルを作成したりパーティションを追加したりする際にバケット数を手動で指定する必要があります。テーブルに新しいパーティションを追加する際にバケット数を指定しない場合、新しいパーティションはテーブル作成時に設定されたバケット数を継承します。ただし、新しいパーティションにバケット数を手動で指定することもできます。
- このパラメーターが
- 導入時期:v2.5.7
enable_experimental_rowstore
- デ フォルト:false
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:ハイブリッド行指向・列指向ストレージ機能を有効にするかどうか。
- 導入時期:v3.2.3
enable_fast_schema_evolution
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:StarRocks クラスター内のすべてのテーブルでFast Schema Evolutionを有効にするかどうか。有効な値は
TRUEとFALSE(デフォルト) です。Fast Schema Evolutionを有効にすると、スキーマ変更の速度が向上し、列の追加または削除時のリソース使用量が削減されます。 - 導入時期:v3.2.0
NOTE
- StarRocks Shared-data クラスターは v3.3.0 以降でこのパラメーターをサポートしています。
- 特定のテーブルのFast Schema Evolutionを設定する必要がある場合 (特定のテーブルのFast Schema Evolutionを無効にするなど) は、テーブル作成時にテーブルプロパティ
fast_schema_evolutionを設定できます。
enable_online_optimize_table
- デフォルト:true
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:最適化ジョブ作成時に StarRocks が非ブロッキングのオンライン最適化パスを使用するかどうかを制御します。
enable_online_optimize_tableが true で、ターゲットテーブルが互換性チェックを満たす場合 (パーティション/キー/ソート指定なし、分散がRandomDistributionDescでない、ストレージタイプがCOLUMN_WITH_ROWでない、レプリケートストレージが有効、テーブルがクラウドネイティブテーブルまたはマテリアライズドビューでない)、プランナーは書き込みをブロックせずに最適化を実行するためにOnlineOptimizeJobV2を作成します。false の場合、または互換性条件が失敗した場合、StarRocks はOptimizeJobV2にフォールバックします。これは、最適化中に書き込み操作をブロックする可能性があります。 - 導入時期:v3.3.3, v3.4.0, v3.5.0
enable_strict_storage_medium_check
- デフォルト:false
- タイプ:Boolean
- 単位:-
- 変更可能:Yes
- 説明:ユーザーがテーブルを作成する際に、FE が BE のストレージメディアを厳密にチェックするかどうか。このパラメーターが
TRUEに設定されている場合、FE はユーザーがテーブルを作成する際に BE のストレージメ ディアをチェックし、BE のストレージメディアが CREATE TABLE ステートメントで指定されたstorage_mediumパラメーターと異なる場合、エラーを返します。例えば、CREATE TABLE ステートメントで指定されたストレージメディアが SSD であるのに、BE の実際のストレージメディアが HDD である場合、テーブル作成は失敗します。このパラメーターがFALSEの場合、FE はユーザーがテーブルを作成する際に BE のストレージメディアをチェックしません。 - 導入時期:-
max_bucket_number_per_partition
- デフォルト:1024
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:パーティション内に作成できるバケットの最大数。
- 導入時期:v3.3.2
max_column_number_per_table
- デフォルト:10000
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:テーブル内に作成できる列の最大数。
- 導入時期:v3.3.2
max_dynamic_partition_num
- デフォルト:500
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:動的パーティションテーブルの分析または作成時に一度に作成できる最大パーティション数を制限します。動的パーティションプロパティ検証中、
systemtask_runs_max_history_numberは予想されるパーティション (終了オフセット + 履歴パーティション番号) を計算し、合計がmax_dynamic_partition_numを超える場合、DDL エラーをスローします。正当に大きなパーティション範囲を予想する場合にのみこの値を増やしてください。増やすとより多くのパーティションを作成できますが、メタデータサイズ、スケジューリング作業、および運用上の複雑さが増加する可能性があります。 - 導入時期:v3.2.0
max_partition_number_per_table
- デフォルト:100000
- タイプ:Int
- 単位:-
- 変更可能:Yes
- 説明:テーブル内に作成できるパーティションの最大数。
- 導入時期:v3.3.2