http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> what is the upgrade process for sta...
# questions-and-troubleshooting
b
@Rocky what is the upgrade process for starrocks when using the helm operator?
r
Upgrading StarRocks using the Helm Operator is a streamlined process where the Operator manages the rolling update of your cluster components. To ensure a safe upgrade, it is critical to follow the recommended sequence and version paths. 1. Pre-upgrade Preparation * Backup Metadata: Before any major or minor upgrade, it is highly recommended to back up your FE metadata. * Checkpoint Check: Ensure that a recent metadata checkpoint has been created. You can force this by running the following SQL command in your StarRocks cluster:
Copy code
sql
    ALTER SYSTEM CREATE IMAGE;
Verify that the image file has synchronized to all Follower FEs by checking the 
fe.log
on the Leader FE. * Upgrade Path: * Minor Versions: It is recommended to upgrade consecutively (e.g., v2.4 -> v2.5 -> v3.0). * Major Versions: To upgrade to v3.x, you must first be on at least v2.5. 2. Update Helm Repository Fetch the latest chart versions from the StarRocks repository:
Copy code
bash
helm repo update
helm search repo starrocks
3. Upgrade Sequence (Crucial) StarRocks requires that BEs (and CNs) are upgraded before FEs. This is because BEs are backward compatible with FEs, but newer FEs may not be compatible with older BEs. Step A: Upgrade BE/CN Nodes Update your 
values.yaml
file with the new image tag for the BE (and CN if applicable), or use the 
--set
flag:
Copy code
bash
helm upgrade <release_name> starrocks/kube-starrocks \
  --reuse-values \
  --set starrocksCluster.starRocksBeSpec.image=<new_be_image>
The Operator will perform a rolling restart of the BE pods. Monitor the status:
Copy code
bash
kubectl get pods -n <namespace>
Wait until all BE/CN pods are in the 
Running
and 
Ready
state before proceeding. Step B: Upgrade FE Nodes Once the BEs are stable, update the FE image tag:
Copy code
bash
helm upgrade <release_name> starrocks/kube-starrocks \
  --reuse-values \
  --set starrocksCluster.starRocksFeSpec.image=<new_fe_image>
The Operator will upgrade the Follower FEs first and the Leader FE last to maintain cluster availability. 4. Upgrade the Operator (Optional) If you are also upgrading the StarRocks Operator version itself (e.g., changing the Helm chart version), you can do so by specifying the new chart version. The 
kube-starrocks
chart usually handles the Operator and Cluster together:
Copy code
bash
helm upgrade <release_name> starrocks/kube-starrocks --version <new_chart_version> -f my-values.yaml
5. Verify the Upgrade Check the cluster version by logging into StarRocks and running:
Copy code
sql
SELECT current_version();
Also, verify the status of the nodes:
Copy code
sql
SHOW FRONTENDS;
SHOW BACKENDS;
Summary of Best Practices * Sequential Upgrades: Do not skip minor versions (e.g., don't go from 2.3 directly to 2.5). * Image Order: Always update BE image first, then FE image. * Monitoring: Keep an eye on the pod status and the FE 
sys_log
during the process to catch any metadata compatibility issues early. References • deployment/sr_operator.md • deployment/upgrade.md • deployment/helm.md • administration/stargo.md
b
when i upgrade do i have to go through all patch versions or just the minors/majors
@Rocky when upgrading do i have to apply each patch version or can i just apply minor and major versions in order
r
When upgrading StarRocks, you do not need to apply every single patch version, but there are specific rules and recommendations for minor and major versions to ensure metadata compatibility and system stability. 1. Patch Versions (Third Digit) You can skip patch versions. For example, you can upgrade directly from v2.5.2 to v2.5.15 without installing every intermediate patch. Patch versions are designed to be fully compatible within the same minor release. 2. Minor Versions (Second Digit) Recommendation: Upgrade consecutively. While StarRocks technically allows skipping minor versions (e.g., going from v2.2.x directly to v2.5.x), it is strongly recommended to upgrade consecutively (v2.2 → v2.3 → v2.4 → v2.5). * Why? Consecutive upgrades reduce the risk of metadata migration errors. Each minor version may introduce structural changes to how metadata is stored, and jumping too many versions at once increases the complexity of these transitions. * Release Notes: You must read the release notes for every minor version you are "skipping" to ensure there are no breaking changes or required configuration updates. 3. Major Versions (First Digit) Prerequisites are mandatory. You cannot jump directly from an old major version to a new one if a specific "bridge" version is required. * Example: To upgrade to v3.0, your cluster must be running at least v2.5. You cannot jump from v2.3 directly to v3.0. Summary Table Upgrade Type | Can you skip? | Recommendation Patch (e.g., .1 to .5) | Yes | Safe to jump to the latest patch of your current minor version. Minor (e.g., .3 to .5) | Yes (Technically) | Not Recommended. Perform consecutive upgrades (3.1 → 3.2 → 3.3). Major (e.g., 2.x to 3.x) | No | You must reach the final minor version of the previous major branch first. Important Reminder for Helm Users Even when skipping patch versions, always follow the correct component order for each step: 1. Upgrade BEs/CNs first. 2. Wait for BEs/CNs to be healthy. 3. Upgrade FEs last. This order is critical because newer BEs are backward compatible with older FEs, but newer FEs may send instructions that older BEs cannot understand.
b
@Rocky can you alter the table that a routine load is attached to?
r
Yes, you can alter a table that a Routine Load is attached to. StarRocks is designed to handle schema changes (like adding or dropping columns) as online operations that generally do not block data ingestion. However, the Routine Load job will not automatically pick up the new columns or changes in data mapping. You must follow a specific process to ensure the data is loaded correctly into the new schema. 1. Behavior if you only Alter the Table If you run 
ALTER TABLE ... ADD COLUMN ...
but do not update the Routine Load job: * The job keeps running: The Routine Load will continue to consume data from Kafka. * Default values: Since the Routine Load job is unaware of the new column, it will not look for it in the Kafka message. The new column in StarRocks will be populated with its defined 
DEFAULT
value (or 
NULL
if no default is specified). * Data remains stable: Existing columns will continue to be populated as before. 2. Process to include New Columns in Routine Load To have your Routine Load job start ingesting data into the newly added column, follow these steps: 1. Alter the Table: Add the column to your StarRocks table.
Copy code
sql
    ALTER TABLE my_table ADD COLUMN new_col INT DEFAULT '0';
2. Pause the Routine Load: You cannot modify a Routine Load job while it is in the 
RUNNING
state.
Copy code
sql
    PAUSE ROUTINE LOAD FOR my_job_name;
3. Alter the Routine Load: Update the 
COLUMNS
mapping to include the new column. If you are using JSON or Avro, you may also need to update 
jsonpaths
.
Copy code
sql
    ALTER ROUTINE LOAD FOR my_job_name
    COLUMNS (old_col1, old_col2, new_col);
4. Resume the Routine Load:
Copy code
sql
    RESUME ROUTINE LOAD FOR my_job_name;
Important Considerations * Column Mapping: If your Routine Load was created without a 
COLUMNS
property (meaning it relies on the table's default column order), adding a column to the table might cause a mismatch if the Kafka data order doesn't change exactly when the table does. It is always a best practice to explicitly define the 
COLUMNS
mapping in your Routine Load job. * Monitoring: Use 
SHOW ALTER TABLE COLUMN
to verify that the table schema change has finished before resuming or altering your load job, especially for very large tables where schema changes take longer. * Asynchronous Nature: Remember that 
ALTER TABLE
for column changes is an asynchronous operation in StarRocks. The command returns immediately, but the background task may take some time to complete. References • best_practices/query_tuning/schema_tuning.md • loading/Load_to_Primary_Key_tables.md • knowledge/usage/best-practice.md • loading/Spark-connector-starrocks.md
b
@Rocky can you change a routine load to point to a different table?
r
No, you cannot change the target table of an existing Routine Load job using the 
ALTER ROUTINE LOAD
command. The 
ALTER ROUTINE LOAD
statement only supports modifying specific properties such as concurrency, error limits, task intervals, and Kafka offsets. The target table is fundamentally tied to the job's identity and metadata at the time of creation. How to move the load to a different table: If you need to point the data ingestion to a new table, you must follow these steps: 1. Stop the current job: You should stop the existing job to prevent further data from being loaded into the old table.
Copy code
sql
    STOP ROUTINE LOAD FOR my_old_job_name;
(Note: Using 
STOP
or 
DROP
is preferred over 
PAUSE
if you don't intend to use the old job again, as it cleans up the metadata.) 2. Get the current offset (Optional): If you want to ensure no data is lost or duplicated, run 
SHOW ROUTINE LOAD FOR my_old_job_name
before stopping it to see the last consumed Kafka offsets. 3. Create a new job: Create a new Routine Load job pointing to the new table. If you want to continue exactly where the previous job left off, specify the 
kafka_offsets
in the 
FROM KAFKA
section.
Copy code
sql
    CREATE ROUTINE LOAD my_new_job_name ON new_table_name
    COLUMNS(col1, col2, ...)
    PROPERTIES (...)
    FROM KAFKA (
        "kafka_broker_list" = "...",
        "kafka_topic" = "...",
        "kafka_offsets" = "..." -- Use the offsets from the old job here
    );
Summary of what can be altered: For future reference, you can alter: * 
desired_concurrent_number
* 
max_error_number
* 
max_batch_interval
/ 
max_batch_rows
/ 
max_batch_size
* 
jsonpaths
and 
json_root
* 
kafka_offsets
(to rewind or skip data) * 
WHERE
filters and 
COLUMNS
mapping (for the same table) But you cannot alter: * The target table name. * The Kafka topic name. * The Kafka broker list. References • sql-reference/sql-statements/loading_unloading/routine_load/ALTER_ROUTINE_LOAD.md • loading/RoutineLoad.md • sql-reference/sql-statements/loading_unloading/routine_load/CREATE_ROUTINE_LOAD.md • loading/load_from_pulsar.md
b
@Rocky how do i backup up FE metadata
r
To back up StarRocks FE (Frontend) metadata, you need to preserve the contents of the metadata directory (defined by the 
meta_dir
parameter in 
fe.conf
). The standard 
BACKUP
SQL statement is primarily for table data and does not include global FE metadata like user accounts, privileges, or resource groups. Therefore, you must perform a file-level backup of the metadata directory. 1. Preparation: Consolidate Metadata Before copying the files, it is best practice to force the FE to consolidate its edit logs (journal) into a fresh "image" file. This reduces the size of the backup and ensures consistency. Run this SQL command from any MySQL client connected to the Leader FE:
Copy code
sql
ALTER SYSTEM CREATE IMAGE;
Wait a few minutes for the FE to finish generating the new image file in 
meta/image/
. 2. Locate the Metadata Directory Check your 
fe.conf
file for the 
meta_dir
setting. By default, it is located at: 
[STARROCKS_HOME]/fe/meta
The directory contains two critical subfolders: * /image: Stores the periodic snapshots of the system state (metadata image). * /bdb: Stores the BDBJE (Berkeley DB Java Edition) journal logs, which contain the incremental changes since the last image. 3. Backup Procedure Option A: Manual File Backup (Recommended) You can back up the metadata while the FE is running if you have a High Availability (HA) cluster. 1. Identify a Non-Leader Node: Perform the backup on a Follower (non-leader) or Observer node. This avoids putting any load on the Leader FE. 2. Copy the Directory: Use a tool like 
tar
, 
rsync
, or a cloud snapshot tool to back up the entire 
meta_dir
.
Copy code
bash
    tar -czvf fe_meta_backup_$(date +%F).tar.gz /path/to/starrocks/fe/meta
3. Store Remotely: Move the archive to secure remote storage (S3, HDFS, etc.). Option B: Offline Backup If you have only one FE node, you should stop the FE to ensure full consistency, although copying while running is usually safe if an image was just created. 1. Stop the FE: 
./bin/stop_fe.sh
2. Copy the 
meta
directory. 3. Restart the FE: 
./bin/start_fe.sh --daemon
4. Recovery (Briefly) To restore from a backup: 1. Install a clean StarRocks FE of the same version. 2. Replace its 
meta/
directory with your backed-up version. 3. If the IP address has changed, you may need to start the FE with the 
--metadata_failure_recovery
flag or manually edit the 
meta/image/ROLE
file. Summary Checklist * Do not rely on 
BACKUP
SQL: It only backs up table data, not FE global metadata. * Use `ALTER SYSTEM CREATE IMAGE`: Do this first to ensure the backup is compact and up-to-date. * Back up the whole 
meta/
folder: Ensure you get both 
image
and 
bdb
subdirectories. * Frequency: It is recommended to automate this daily or before any major cluster operation (like an upgrade). References • sql-reference/sql-statements/backup_restore/BACKUP.md • administration/management/Backup_and_restore.md
b
@Rocky what iceberg maintenance operations does starrocks support
r
StarRocks provides comprehensive support for Apache Iceberg maintenance through a set of Stored Procedures and SQL commands. These operations allow you to manage storage, optimize performance, and handle data lifecycles directly from StarRocks. The general syntax for these maintenance procedures is:
Copy code
sql
ALTER TABLE [catalog.][database.]table_name EXECUTE <procedure_name>(<arguments>);
1. Data & Storage Optimization * Rewrite Data Files (
rewrite_data_files
): Merges small files into larger ones to improve query performance and reduce metadata pressure. You can filter specific partitions using a 
WHERE
clause.
Copy code
sql
    ALTER TABLE iceberg_table EXECUTE rewrite_data_files("min_file_size_bytes"=134217728) WHERE date >= '2024-01-01';
* Rewrite Manifests (
rewrite_manifests
): Optimizes the manifest files of the current snapshot by merging them, which speeds up metadata planning for queries.
Copy code
sql
    ALTER TABLE iceberg_table EXECUTE rewrite_manifests();
2. Cleanup & Metadata Management * Expire Snapshots (
expire_snapshots
): Removes old snapshots and deletes the underlying data files that are no longer needed. You can specify a retention period or a minimum number of snapshots to keep.
Copy code
sql
    ALTER TABLE iceberg_table EXECUTE expire_snapshots(older_than = '2024-01-01 00:00:00', retain_last = 5);
* Remove Orphan Files (
remove_orphan_files
): Scans the table directory and deletes files that are not referenced by any valid Iceberg snapshot.
Copy code
sql
    ALTER TABLE iceberg_table EXECUTE remove_orphan_files(older_than = '2024-03-01 00:00:00');
3. Snapshot & Version Control * Rollback to Snapshot (
rollback_to_snapshot
): Resets the table state to a specific snapshot ID.
Copy code
sql
    ALTER TABLE iceberg_table EXECUTE rollback_to_snapshot(852394123456789);
* Cherry-pick Snapshot (
cherrypick_snapshot
): Applies the changes from a specific historical snapshot to the current table state. * Branch & Tag Management: StarRocks supports creating and dropping Iceberg branches and tags for advanced lifecycle management and "Write-Audit-Publish" (WAP) workflows.
Copy code
sql
    -- Create a branch for testing
    ALTER TABLE iceberg_table CREATE BRANCH test_branch RETAIN 7 DAYS;
    -- Fast-forward main to a branch
    ALTER TABLE iceberg_table EXECUTE fast_forward('main', 'test_branch');
4. Metadata Caching (Performance) While not a "maintenance" command in the traditional sense, StarRocks maintains a Metastore Cache for Iceberg to avoid frequent calls to Hive Metastore or Glue. * You can manually refresh this metadata if external changes occur:
Copy code
sql
    REFRESH EXTERNAL TABLE iceberg_table;
* StarRocks also supports Background Refresh and Disk Caching for Iceberg metadata, which can be configured via FE properties (e.g., 
enable_iceberg_metadata_disk_cache
). Summary of Support Operation | Command/Procedure | Purpose Compaction | 
rewrite_data_files
| Merge small files. Cleanup | 
expire_snapshots
| Delete old versions/data. Garbage Collection | 
remove_orphan_files
| Delete unreferenced files. Time Travel Fix | 
rollback_to_snapshot
| Undo recent changes. Metadata Tuning | 
rewrite_manifests
| Optimize manifest list. Lifecycle | 
CREATE BRANCH/TAG
| Manage data versions. Note: Ensure your StarRocks user has the necessary privileges to execute these procedures on the external catalog. References • data_source/catalog/iceberg/iceberg_timetravel.md • data_source/catalog/iceberg/procedures.md
b
@Rocky what does State = EOF mean in processlist
r
In StarRocks, when you see 
State = EOF
in the 
SHOW PROCESSLIST
output, it generally means End of File. This is a normal state in the MySQL protocol (which StarRocks uses) indicating that the server has finished sending the result set to the client. Here is a breakdown of what this specifically signifies and why it appears: 1. Successful Data Transmission For 
SELECT
queries, StarRocks sends the data in packets. Once the last row of the result set has been sent, the server sends an "EOF packet" to tell the client there is no more data. * EOF: The query has successfully executed, and the server has transmitted all requested rows. * OK: Typically used for statements that don't return a result set (like 
INSERT
, 
UPDATE
, or 
DDL
), or for the final response of a command that didn't involve a row-based result set. 2. Waiting for Client Acknowledgment If a query stays in the 
EOF
state for an extended period, it often indicates a client-side bottleneck: * The server has the data ready (or has sent it), but the client application is slow to "fetch" or consume the rows. * The connection is still open, and the server is waiting for the client to acknowledge the end of the stream or to send the next command. 3. Comparison of Common States State | Meaning Pending | The query is in the internal queue waiting for resources (CPU/Memory). Running | The query is actively being processed by the BE (Backend) nodes. EOF | Data processing is finished; the server has finished sending the result set. OK | The operation completed successfully (common for non-SELECTs). Troubleshooting "Sticky" EOF States If you see many connections stuck in 
EOF
for a long time (high 
Time
value in processlist): * Check the Client: The application might be retrieving a very large result set and processing it slowly row-by-row. * Network Latency: There might be a delay in transmitting the final packets across the network. * Connection Pooling: Some client libraries keep the session in this state until the result set object is explicitly closed in the code. Summary: 
EOF
is not an error; it is a signal that the "work" of the query is done from the database's perspective, and it is now just finalizing the communication with your application. References • using_starrocks/running_queries.md • administration/management/monitor_manage_big_queries.md • faq/Sql_faq.md • administration/management/resource_management/Query_management.md
b
@Rocky what does State = NOOP mean in processlist
r
In StarRocks, seeing 
State = NOOP
 in the 
SHOW PROCESSLIST
or audit logs is relatively uncommon but typically indicates a "No Operation" state. This status generally appears in the following scenarios: 1. Prepared Statements (Most Common) When using Server-Side Prepared Statements (e.g., via a JDBC driver with 
useServerPrepStmts=true
), the MySQL protocol involves multiple phases: 
COM_STMT_PREPARE
, 
COM_STMT_EXECUTE
, etc. * The PREPARE phase itself does not execute data processing; it only parses the statement and returns a statement ID. * StarRocks may record these non-executing phases with a 
State = NOOP
and 
IsQuery = false
because no actual scan or compute work was performed yet. 2. Handshake or Administrative Pings Connections from certain monitoring tools or load balancers may send "heartbeat" packets or empty commands just to keep a connection alive. If StarRocks receives a command that requires no processing or result generation, it may briefly surface as 
NOOP
. 3. Internal Forwarding/Optimization In some cases, if a query is forwarded from one FE to another (e.g., in a multi-FE setup where a follower forwards a DDL to the Leader), the original node might mark its local proxy-state as 
NOOP
while waiting for the remote execution to complete, or use it as a placeholder for optimized-out operators in a query plan. 4. Empty Statements If a client sends an empty string or a comment-only string as a command, the server might classify the execution state as 
NOOP
since there is no work to perform. Summary for Troubleshooting: * Is it an error? No. 
NOOP
is not an error state. * What if I see many of them? If you see many connections stuck in 
NOOP
with high 
Time
values, check if your application is using prepared statements heavily or if a monitoring tool is holding open idle connections. * Performance Impact: Generally zero. 
NOOP
indicates the absence of resource-heavy operations (Scan/CPU/Memory). References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • administration/management/monitor_manage_big_queries.md References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md
b
@Rocky how do i change the log level for audit logs?
r
In StarRocks, "log level" for audit logs works differently than for system logs. Audit logs (
fe.audit.log
) do not use standard severity levels like INFO or DEBUG. Instead, you control their verbosity by configuring audit modules and performance thresholds. 1. Adjusting Audit Verbosity (Modules) You can define which types of events are recorded by setting the 
audit_log_modules
. By default, it tracks 
query
and 
slow_query
. * Parameter: 
audit_log_modules
* Available Modules: 
query
, 
slow_query
, 
connection
(connection logging was added in v3.0). * How to change: This parameter is not mutable at runtime and must be changed in your 
fe.conf
followed by an FE restart.
Copy code
properties
    # Example: Add connection logging
    audit_log_modules = slow_query, query, connection
2. Changing the "Slow Query" Threshold If you want to reduce the volume of the 
slow_query
log (effectively raising the "level" of what counts as a slow query), you can change the millisecond threshold. * Parameter: 
qe_slow_log_ms
(Default: 5000ms) * How to change: This is mutable and can be changed dynamically without a restart.
Copy code
sql
    -- Change threshold to 10 seconds (10000 ms)
    ADMIN SET FRONTEND CONFIG ("qe_slow_log_ms" = "10000");
3. Enabling/Disabling SQL Text If you want to audit that a query happened but hide the actual SQL string (for privacy or to save space), you can toggle this setting: * Parameter: 
enable_audit_sql
(Default: 
true
) * Note: This is *not mutable*; requires an FE restart. 4. System Log Level (Distinction) If you are looking for actual severity levels (INFO, WARN, ERROR, DEBUG), these apply to the System Log (
fe.log
), not the audit log. * Command:
Copy code
sql
    -- Change FE system log level to WARN
    ADMIN SET FRONTEND CONFIG ("sys_log_level" = "WARN");
Summary of Audit Configuration Goal | Parameter | Mutable? Change what's audited | 
audit_log_modules
| No (Restart required) Change slow query sensitivity | 
qe_slow_log_ms
| Yes Enable/Disable slow query log | 
enable_qe_slow_log
| Yes Change log format (JSON/Text) | 
audit_log_json_format
| Yes Log retention days | 
audit_log_delete_age
| No (Restart required) Rocky's Tip: To see your current settings, run 
ADMIN SHOW FRONTEND CONFIG LIKE '%audit%';
. References • administration/management/FE_configuration.md • administration/management/logs.md • sql-reference/sql-statements/cluster-management/nodes_processes/ADMIN_SET_CONFIG.md References • administration/management/FE_configuration.md
b
@Rocky can i limit the number of rows allowed to scan?
r
Yes, you can limit the number of rows allowed to be scanned in StarRocks. The primary way to do this is by using Resource Groups. 1. Using Resource Groups (Recommended) Starting from StarRocks v2.x, you can define a 
big_query_scan_rows_limit
within a Resource Group. Any query that matches this resource group and attempts to scan more rows than the limit will be automatically terminated. Example: To create a resource group that limits queries to scanning no more than 100,000 rows:
Copy code
sql
CREATE RESOURCE GROUP scan_limit_group
TO (user='tg_user') -- Apply to specific users
WITH (
    'cpu_core_limit' = '1',
    'mem_limit' = '10%',
    'big_query_scan_rows_limit' = '100000'
);
If a query exceeds this, it will return an error like: 
ERROR 1064 (HY000): exceed big query scan_rows limit: current is XXX but limit is 100000
2. Other Related Limits While there isn't a single "session variable" that globally stops a scan mid-way like the resource group property does, you can use these related settings to control query scope: * 
scan_olap_partition_num_limit
 (Added in v3.3.9): Limits the number of partitions a single query can scan. This is very effective for preventing "full table scans" on large partitioned tables.
Copy code
sql
    SET scan_olap_partition_num_limit = 10;
* 
sql_select_limit
: Limits the number of rows returned to the client (similar to adding 
LIMIT X
to every query), though it doesn't necessarily stop the backend from scanning more rows to process the result (e.g., in an 
ORDER BY
).
Copy code
sql
    SET sql_select_limit = 1000;
* 
query_mem_limit
: Often, queries that scan too many rows also consume too much memory. Setting a strict memory limit can indirectly kill "runaway" scan queries.
Copy code
sql
    SET query_mem_limit = 2147483648; -- 2GB
Summary If you want a hard limit on scanned rows, use Resource Groups. If you want to prevent accidental full scans of partitioned tables, use 
scan_olap_partition_num_limit
. References • administration/management/monitor_manage_big_queries.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md References • administration/management/BE_configuration.md • administration/management/resource_management/Query_management.md • sql-reference/System_variable.md • administration/management/monitor_manage_big_queries.md
b
@Rocky can i write audit logs to a file but write all other logs to console?
r
In StarRocks (specifically the Frontend/FE), there is currently no single configuration flag to split logs so that audit logs go to a file while other logs go to the console. The logging behavior is primarily controlled by the 
sys_log_to_console
parameter, which is an "all-or-nothing" toggle. How it works today: * 
sys_log_to_console = false
(Default): All logs (
fe.log
, 
fe.warn.log
, 
fe.audit.log
, etc.) are written to their respective files in the directory specified by 
sys_log_dir
and 
audit_log_dir
. * 
sys_log_to_console = true
(or environment variable 
SYS_LOG_TO_CONSOLE=1
): All logs are redirected to the console (standard error), and file-based logging is disabled. Recommended Workarounds: 1. Use the "Symlink" Approach (Best for Docker/Kubernetes) If you are running in a container and want 
fe.log
on your 
kubectl logs
but want to keep 
fe.audit.log
on a persistent volume for security/auditing: 1. Leave 
sys_log_to_console = false
. 2. In your container startup script or entrypoint, create a symbolic link for the main log file:
Copy code
bash
    ln -sf /dev/stdout /opt/starrocks/fe/log/fe.log
3. Note: Because StarRocks uses 
RollingFile
appenders, rotation might fail or create "dead" links once the file size limit is reached. You should set 
log_roll_size_mb
to a very large value to prevent rotation of the symlinked file. 2. Custom Log4j2 Configuration StarRocks FE uses Log4j2. You can provide a custom 
log4j2.xml
to gain granular control. 1. Create a custom 
log4j2.xml
. 2. Define a 
Console
appender for the root logger and a 
RollingFile
appender specifically for the 
audit
logger. 3. Point to this file by adding this to your 
JAVA_OPTS
in `fe.conf`:
Copy code
properties
    JAVA_OPTS="-Dlog4j.configurationFile=/path/to/your/custom/log4j2.xml"
3. AuditLoader Plugin Instead of managing local files, you can use the AuditLoader plugin. This reads the local 
fe.audit.log
and loads the data into a StarRocks table. This allows you to set 
sys_log_to_console = true
(to get system logs on console) and still have your audit data safely stored and queryable in a database table. Summary of Future Changes There is active development (as of late 2024/2025) to introduce more granular flags like 
audit_log_to_disk_enabled
to allow "dual logging" (console for system logs + disk for audit logs) natively. Check your specific version's release notes for these newer parameters. References • administration/management/FE_configuration.md • administration/management/logs.md • administration/management/audit_loader.md References • administration/management/FE_configuration.md • administration/management/logs.md • administration/management/audit_loader.md
b
@Rocky are there things in starrocks that only the root user can do
r
In StarRocks, the 
root
user is the primary "Superuser" account created automatically upon installation. While StarRocks uses a Role-Based Access Control (RBAC) system that allows you to delegate almost any task to other users, there are a few specific things that are exclusive to the 
root
user or its associated 
root
role. 1. Root Password Management This is the most significant restriction: Only the 
root
user itself can change its own password. * Even a user with the 
user_admin
role (who can create, drop, and change passwords for all other users) cannot change the password for the 
root
account. * If you lose the 
root
password, you cannot fix it via SQL from another admin account. You must restart the Frontend (FE) with 
enable_auth_check = false
in the 
fe.conf
to bypass security and reset it. 2. The "Union" of All Privileges While StarRocks defines specialized administrative roles, only the 
root
role automatically grants the union of all system-level privileges. * 
user_admin
: Can manage users and roles but cannot manage cluster nodes or databases. * 
cluster_admin
: Can manage nodes but cannot manage users or data. * 
db_admin
: Can manage data but cannot manage users or nodes. * 
root
: Automatically holds every privilege in the system (NODE, GRANT, OPERATE, etc.) without needing separate role assignments. 3. Immutable System Identity * Initial Bootstrap: 
root
is the only user that exists by default. It is the starting point for all other security configurations. * Undeletable: You cannot drop the 
root
user. * Immutable Role: The 
root
role itself is immutable. You cannot revoke privileges from the 
root
role to limit what a 
root
user can do. 4. Privilege Restrictions for Other Roles Certain high-level system privileges are restricted from being granted directly to custom roles or users; they are only available through the built-in roles that 
root
inherits. For example: * The 
NODE
 privilege (required to add/drop BE or FE nodes) is assigned only to 
cluster_admin
and 
root
. * The 
GRANT
 privilege (required to grant any privilege to others) is assigned only to 
user_admin
and 
root
. Best Practices Tip: Because the 
root
user is so powerful and its password is so restricted, StarRocks recommends: 1. Setting a strong password for 
root
immediately after deployment. 2. Creating a 
user_admin
and a 
db_admin
 for daily management. 3. Locking away the 
root
credentials and only using them for high-level emergency maintenance or initial setup. References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/built_in_roles.md • administration/user_privs/authorization/privilege_item.md References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/User_privilege.md • administration/user_privs/authorization/built_in_roles.md
b
@Rocky can i rename a role
r
No, StarRocks does not currently support a direct 
RENAME ROLE
command. To effectively "rename" a role, you must follow a manual migration process: 1. Create a new role with the desired name. 2. Grant the same privileges to the new role that the old role has. 3. Grant the new role to the users who are currently assigned the old role. 4. Drop the old role. Example Workflow If you want to rename 
old_role
to `new_role`:
Copy code
sql
-- 1. Create the new role
CREATE ROLE new_role;

-- 2. Grant privileges to the new role 
-- (You would repeat the GRANT commands used for the original role)
GRANT SELECT ON ALL TABLES IN DATABASE db1 TO ROLE new_role;

-- 3. Assign the new role to users
GRANT new_role TO USER 'jack'@'%';

-- 4. Drop the old role
DROP ROLE old_role;
Tips * Checking Privileges: You can use 
SHOW GRANTS FOR ROLE old_role;
to see exactly what privileges need to be migrated to the new role. * Inheritance: If you are using role inheritance (granting one role to another), remember to grant the new role to the same parent/child roles as the old one. * Permissions Required: You must have the 
user_admin
system-defined role or the 
GRANT
privilege to perform these operations. References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/DROP_ROLE.md • sql-reference/sql-statements/account-management/CREATE_ROLE.md References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/DROP_ROLE.md • sql-reference/sql-statements/table_bucket_part_index/ALTER_TABLE.md • release_notes/release-3.0.md • administration/user_privs/authorization/privilege_item.md
b
@Rocky can you rename a resource group
r
No, StarRocks does not currently support a direct 
RENAME RESOURCE GROUP
command. To "rename" a resource group, you must follow a manual migration process by creating a new one with the desired name and deleting the old one. Recommended Workflow 1. Retrieve the current configuration First, check the existing resource limits and classifiers for the group you want to rename:
Copy code
sql
-- Replace 'old_group_name' with your actual group name
SHOW RESOURCE GROUP old_group_name;
Note down the values for 
cpu_weight
(or 
exclusive_cpu_cores
), 
mem_limit
, 
concurrency_limit
, and any classifiers listed. 2. Create the new resource group Use the 
CREATE RESOURCE GROUP
command to create a new group with the same settings:
Copy code
sql
CREATE RESOURCE GROUP new_group_name 
TO (
    -- Replicate the classifiers here
    user='example_user', 
    role='example_role'
) 
WITH (
    "cpu_weight" = "10",
    "mem_limit" = "20%"
);
3. Delete the old resource group Once you have verified the new group exists, you can drop the old one:
Copy code
sql
DROP RESOURCE GROUP old_group_name;
Important Considerations * Active Sessions: If any users are currently connected and have manually set their resource group via 
SET resource_group = 'old_group_name';
, their sessions will point to a non-existent group once it is dropped. They will need to update their session variable or reconnect. * Classifiers: Resource group matching via classifiers (user, role, IP, etc.) is automatic. Once the new group is created with the correct classifiers, new queries will automatically begin using it. * Privileges: You must have the 
SYSTEM
level 
CREATE RESOURCE GROUP
privilege and the 
DROP
privilege on the specific resource group to perform these actions. References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/DROP_RESOURCE_GROUP.md References • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md
b
why can't i set cpu_weight to 0 in a resource group
@Rocky why can't i set cpu_weight to 0 in a resource group
r
In StarRocks, you cannot set 
cpu_weight
to 0 because every resource group must have a valid, non-zero allocation of CPU resources to function. Here are the specific reasons and constraints: 1. Logical Requirement for Execution A resource group is designed to isolate and execute queries. Since 
cpu_weight
determines the relative share of CPU time a group receives, a value of 0 would mathematically mean the group is allocated 0% of the CPU. This would prevent any query assigned to that group from ever executing, essentially hanging the query indefinitely. 2. Mandatory CPU Configuration StarRocks requires that every resource group has at least one type of CPU limit configured. You must set either 
cpu_weight
(for shared/soft limits) or 
exclusive_cpu_cores
(for hard isolation), and the system enforces that the chosen value must be greater than 0. 3. Value Range Constraints As per the documentation: * 
cpu_weight
range: 
(0, avg_be_cpu_cores]
(must be greater than 0). * 
exclusive_cpu_cores
range: 
(0, min_be_cpu_cores - 1]
(must be greater than 0). What to do instead? * To give a group the lowest possible priority: Set 
cpu_weight
to 
1
. This ensures it only gets a tiny fraction of CPU cycles when other groups are busy but can still use more if the system is idle. * To stop queries from running in a group: If your goal is to prevent a specific set of users or roles from running queries, it is better to remove the classifiers from the resource group or use StarRocks' Privilege System to revoke their 
SELECT
permissions. * To temporarily "disable" a group: You can use the 
concurrency_limit
parameter. Setting 
concurrency_limit
to 
0
(which is allowed for that specific parameter) will prevent any new queries from starting in that group. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/Resource_isolation.md References • faq/resource_isolation_faq.md • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md
b
@Rocky what is mem_limit in a resource group
r
In StarRocks, 
mem_limit
 is a parameter used in a resource group to define the maximum percentage of memory that the group can consume on each Backend (BE) node. It acts as a "soft" or "hard" quota for memory isolation between different workloads (e.g., separating ETL from ad-hoc queries). Key Characteristics * Unit of Measure: It is expressed as a percentage of the BE's total query memory pool (the 
mem_limit
set in the BE config, which defaults to 90% of physical RAM). * Value Range: A decimal between 
0
and 
1
(e.g., 
0.5
) or a percentage string (e.g., 
'50%'
). * Scope: The limit is applied per BE node, not globally across the entire cluster. * Over-provisioning: You can set the total 
mem_limit
of all resource groups to exceed 100%. This allows for flexible resource sharing when some groups are idle. What happens when the limit is reached? 1. Query Failure: If the memory consumed by all queries in a resource group on a specific BE exceeds the calculated limit, new memory allocations will fail, and StarRocks will typically terminate the query with a "Memory limit exceeded" error. 2. Spilling to Disk: Since StarRocks v3.1.7, you can configure 
spill_mem_limit_threshold
. If the resource group's memory usage crosses this threshold (e.g., 80% of its 
mem_limit
), StarRocks will begin spilling intermediate query data to disk to avoid crashing the query. Example Configuration
Copy code
sql
CREATE RESOURCE GROUP analytic_group
TO (role='analyst')
WITH (
    "mem_limit" = "40%",      -- This group can use up to 40% of the BE query memory
    "cpu_weight" = "10"
);
Advanced: 
mem_pool
(v4.0+) In newer versions, you can use the 
mem_pool
parameter to group multiple resource groups together. If groups share the same 
mem_pool
ID, they collectively share a single 
mem_limit
. This is useful for multi-tenant scenarios where you want a set of users to share a total bucket of memory. References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • administration/management/monitoring/metrics.md
b
@Rocky what would cause this error ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0
r
The error 
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading authorization packet', system error: 0
typically indicates that the network connection was closed by the server (the StarRocks FE) during the initial authentication phase. In the context of StarRocks, this is often caused by one of the following three scenarios: 1. Known Bug (Password Reset Mode) There is a documented issue in older versions of StarRocks (specifically v2.1.x, v2.2.x, and v2.3.0) where attempting to log in while 
enable_auth_check = false
is set (a common practice to reset a lost root password) triggers a 
java.lang.IndexOutOfBoundsException
in the FE. This causes the FE to abruptly close the connection, leading to this specific error. * Fix: Upgrade to a newer version (v2.3.2 or later) or check the FE leader's 
fe.log
for a stack trace involving 
com.starrocks.mysql.MysqlProto.authenticate
. 2. Network Timeouts or DNS Issues The MySQL protocol requires a handshake. If the FE takes too long to resolve the client's hostname or if the network is unstable, the connection may time out during the "authorization packet" phase. * Troubleshooting: * Check if 
skip_name_resolve
is set to 
true
in your FE configuration (though StarRocks usually handles this internally, environment-level DNS delays can still interfere). * Increase the connection timeout on the client side or check the network latency between the client and the FE. 3. Load Balancer / Proxy Interference If you are connecting through a proxy (like HAProxy) or a Load Balancer (like F5), the proxy may be closing the connection before the authentication is complete. * Common Cause: The proxy might not be configured to handle the MySQL protocol correctly, or there is a mismatch in Proxy Protocol settings. * Solution: Ensure the load balancer's timeout settings are higher than the handshake requirement and verify that the "Proxy Protocol" is either enabled on both ends or disabled on both. How to Troubleshoot 1. Check FE Logs: Look at 
fe/log/fe.log
and 
fe/log/fe.warn.log
. If it's a server-side crash or a specific exception (like the 
IndexOutOfBoundsException
mentioned above), it will be logged there. 2. Test Direct Connection: Try connecting directly to the FE IP address instead of through a load balancer or VIP to rule out network infrastructure issues. 3. Verify Authentication Plugin: Ensure your client is using a compatible authentication method. StarRocks primarily uses 
mysql_native_password
. References • faq/operation_maintenance_faq.md • sql-reference/Error_code.md • administration/management/FE_configuration.md References • faq/operation_maintenance_faq.md • faq/Sql_faq.md • faq/Others.md • administration/management/FE_configuration.md • sql-reference/System_variable.md • administration/Meta_recovery.md • sql-reference/Error_code.md
b
@Rocky how do i list the default roles for a user
r
To list the default roles for a user in StarRocks, you can use several methods depending on whether you want to check the current session or the system configuration. 1. Using 
information_schema
(Recommended) The most precise way to see which roles are marked as "default" for a specific user is to query the 
information_schema.applicable_roles
table. This table contains an 
IS_DEFAULT
column.
Copy code
sql
SELECT ROLE_NAME 
FROM information_schema.applicable_roles 
WHERE USER = 'your_username' 
  AND IS_DEFAULT = 'YES';
2. View Active Roles in the Current Session If you are logged in as the user and want to see which roles were automatically activated upon login (which are the default roles), use:
Copy code
sql
SELECT CURRENT_ROLE();
Note: This will only show the roles currently active. If you have manually changed roles using 
SET ROLE
during the session, this will reflect the change. 3. Using 
SHOW GRANTS
 While 
SHOW GRANTS
displays all roles assigned to a user, it does not always explicitly flag which ones are set as "default" in its summary output. However, it is the standard way to verify all roles a user possesses.
Copy code
sql
SHOW GRANTS FOR 'username'@'host';
Key Facts about Default Roles * Automatic Activation: Default roles are automatically activated whenever a user logs in. * The 
public
Role: Every user has the 
public
role activated by default, even if no other default roles are configured. * Setting Default Roles: You can modify a user's default roles using:
Copy code
sql
    SET DEFAULT ROLE role1, role2 TO username;
    -- OR
    ALTER USER username DEFAULT ROLE ALL;
* Global Activation: If you want all assigned roles to be activated automatically for every user upon login (bypassing the need for specific "default" settings), an administrator can run:
Copy code
sql
    SET GLOBAL activate_all_roles_on_login = TRUE;
References • sql-reference/information_schema/applicable_roles.md • sql-reference/sql-statements/account-management/SET_DEFAULT_ROLE.md • administration/user_privs/authorization/user_privs.md References • sql-reference/sql-statements/account-management/SHOW_AUTHENTICATION.md • sql-reference/sql-statements/account-management/SHOW_USERS.md • sql-reference/sql-statements/account-management/CREATE_USER.md • sql-reference/sql-statements/account-management/SHOW_GRANTS.md
b
@Rocky what is the recommended heap size for a starrocks cluster
r
In StarRocks, the "heap size" specifically refers to the Java Virtual Machine (JVM) memory used by the Frontends (FE) and, to a lesser extent, the Backends (BE). 1. Frontends (FE) - Metadata Management The FE is a Java process that stores all cluster metadata (tablets, schemas, etc.) in its heap. This is where heap configuration is most critical. Recommended Heap Sizes (FE): The heap size should be scaled based on the number of tablets (shards) in your cluster. Total Tablets | Recommended FE Heap (
-Xms
, 
-Xmx
) < 1 million | 16 GB 1 – 2 million | 32 GB 2 – 5 million | 64 GB 5 – 10 million | 128 GB Key Configuration Rules: * Consistency: Always set 
-Xms
(initial heap) and 
-Xmx
(max heap) to the same value in 
fe.conf
to prevent performance hits from heap resizing. * RAM Percentage: * If the machine has < 32 GB RAM, set the heap to ~70% of total RAM. * If the machine has
32 GB RAM
, set the heap to ~80% of total RAM. * File Location: Modify the 
JAVA_OPTS
line in 
fe/conf/fe.conf
.
Copy code
bash
    # Example for 16GB heap
    JAVA_OPTS="-Xmx16g -Xms16g ..."
────────── 2. Backends (BE) - JNI & Java UDFs The BE is a C++ process, so the majority of its memory is managed by the C++ allocator (controlled by 
mem_limit
). However, the BE uses a JVM via JNI for specific tasks like accessing HDFS/Cloud Storage or running Java UDFs. Recommended Heap Sizes (BE): * Standard clusters: 1 GB to 2 GB is usually sufficient. * Heavy Java UDF usage: If you run many complex Java-based functions, you may need to increase this to 8 GB or 12 GB. * File Location: Modify the 
JAVA_OPTS
line in 
be/conf/be.conf
.
Copy code
bash
    # Example for 2GB heap for JNI/UDFs
    JAVA_OPTS="-Xmx2g -Xms2g ..."
────────── 3. Important Tips * Avoid Over-allocation: Do not set the FE heap so high that it leaves less than 2-4 GB for the Operating System. Doing so can cause the OS to kill the FE process (OOM Killer). * Monitoring: Use the StarRocks dashboard or Prometheus/Grafana to monitor the 
jvm_heap_size_bytes
metric. If the "Old Gen" memory usage is consistently above 80%, it’s time to increase the heap or consolidate tablets. * Off-Heap Memory: For the FE, it is recommended to set 
MALLOC_ARENA_MAX=1
in your environment to prevent the C-library from over-allocating virtual memory for the JVM's internal tasks. References • faq/Others.md • deployment/plan_cluster.md • sql-reference/sql-functions/JAVA_UDF.md References • administration/management/BE_configuration.md • sql-reference/sql-functions/JAVA_UDF.md
b
@Rocky how do i change all logging to json format
r
In StarRocks (starting from version 3.2.x), you can transition most Frontend (FE) logs to JSON format to improve integration with log aggregators like ELK, Splunk, or Datadog. Currently, native JSON logging is primarily supported for the Frontend (FE). The Backend (BE) system logs (glog-based) do not yet have a built-in "all-in-one" JSON toggle and remain in plaintext. 1. Configure FE Logs to JSON To change the FE logs to JSON, add or update the following parameters in your 
fe/conf/fe.conf
file and restart the FE: * System Logs (
fe.log
, 
fe.warn.log
):
Copy code
properties
    # Available from v3.2.10+
    sys_log_format = json
This converts the main system logs into structured JSON events containing timestamps, levels, thread IDs, and stack traces. * Audit & Slow Query Logs (
fe.audit.log
, 
fe.slow_query.log
):
Copy code
properties
    # Available from v3.2.7+
    audit_log_json_format = true
This converts connection audits, query audits, and slow-query logs into machine-parsable JSON. * Internal Statistics Logs (
fe.internal.log
):
Copy code
properties
    internal_log_json_format = true
* Query Profile Logs: Query profiles are stored in JSON format by default when profile logging is enabled:
Copy code
properties
    enable_profile_log = true
2. Backend (BE) Considerations The BE process uses the C++ 
glog
library, which does not currently support a native JSON output format through configuration. * Recommendation: For BE logs (
<http://be.INFO|be.INFO>
, 
be.WARNING
), most users utilize a log collector like Filebeat, Fluentd, or Vector to tail the plaintext files and parse them into JSON fields before sending them to a centralized log management system. 3. Summary of Affected Files (FE) Log File | Parameter to Enable JSON 
fe.log
/ 
fe.warn.log
| 
sys_log_format = json
fe.audit.log
| 
audit_log_json_format = true
fe.slow_query.log
| 
audit_log_json_format = true
fe.big_query.log
| 
audit_log_json_format = true
fe.internal.log
| 
internal_log_json_format = true
fe.profile.log
| Enabled by default (if 
enable_profile_log=true
) Note: After changing these settings, any existing log parsers or dashboard regexes that rely on the old pipe-separated (
key=value
) format will need to be updated. References • administration/management/FE_configuration.md • administration/management/logs.md • administration/management/BE_configuration.md References • administration/management/FE_configuration.md • administration/management/logs.md • administration/management/BE_configuration.md • faq/operation_maintenance_faq.md • sql-reference/sql-statements/data-definition/ALTER_ROUTINE_LOAD.md • deployment/helm_chart_usage.md • deployment/k8s_operator.md References • administration/management/BE_configuration.md • administration/management/logs.md • administration/management/FE_configuration.md
b
what is the full list of properties that i can set in fe.conf
@Rocky what is the full list of properties that i can set in fe.conf
r
The full list of properties for 
fe.conf
is extensive, as it controls everything from networking and metadata to query execution and logging. Because there are hundreds of parameters, the best way to view the complete, up-to-date list for your specific version is through one of the following two methods: 1. View Dynamically (Recommended) You can see all configuration properties currently in effect (including those not explicitly set in your 
fe.conf
file) by running this SQL command in your StarRocks cluster:
Copy code
sql
ADMIN SHOW FRONTEND CONFIG;
* Key Columns: * `Name`: The property name. * `Value`: Current setting. * `IsMutable`: If 
true
, you can change it at runtime using 
ADMIN SET FRONTEND CONFIG ("name" = "value");
without restarting. If 
false
, you must update 
fe.conf
and restart the FE. ────────── 2. Main Configuration Categories If you are looking for specific types of properties, they are generally grouped into these functional areas: Server & Networking * `frontend_address`: The IP address of the FE. * `http_port`: Port for the Web UI and REST APIs (Default: 8030). * `rpc_port`: Port for Thrift RPC communication (Default: 9020). * `query_port`: Port for MySQL client connections (Default: 9030). * `edit_log_port`: Port used by BDB JE for metadata replication (Default: 9010). Metadata & Storage * `meta_dir`: Where the FE stores its metadata (highly recommended to put this on an SSD). * `max_bdbje_clock_delta_ms`: Maximum allowed time clock skew between FE nodes. * `metadata_checkpoint_period`: How often the FE creates a new metadata image. Query & Optimization * `max_query_retry_time`: How many times a query can be retried on failure. * `enable_cost_based_optimizer`: Enables/disables the CBO. * `statistic_collect_interval_sec`: How often the FE collects table statistics. Logging (JSON & Plaintext) * `sys_log_level`: Severity level (INFO, WARN, ERROR). * `sys_log_format`: Set to 
json
for structured logging (v3.2+). * `audit_log_json_format`: Set to 
true
to output query audits in JSON. Memory & JVM While these are technically environment variables usually set in 
fe.conf
, they are critical: * `JAVA_OPTS`: Used to set the JVM heap size (e.g., 
-Xmx16g -Xms16g
). ────────── 3. Official Documentation Reference For a deep dive into every single parameter, including its default value and whether it requires a restart, refer to the official StarRocks documentation: 👉 StarRocks FE Configuration Reference Pro Tip: If you're unsure which properties are "mutable" (changeable without a restart), check the 
IsMutable
column in the 
ADMIN SHOW FRONTEND CONFIG;
output. This is the most reliable way to know if you can apply a change instantly. References • administration/management/FE_configuration.md
Open in Slack
PreviousNext
Powered by