@Rocky for a share nothing system what is the process to cleanly shut down a CN using HELM.

@Rocky for a share nothing system what is the process to cleanly shut down a CN using HELM.

To cleanly shut down or scale down a Compute Node (CN) in a StarRocks "shared-nothing" (standard) deployment using Helm, you primarily leverage the Graceful Exit mechanism. Since CNs are stateless (compute-only) even in shared-nothing architectures, they do not require the data decommissioning process that BE nodes do. Here is the process to cleanly shut down a CN using Helm: 1. Verify Prerequisites * StarRocks Version: Graceful Exit is supported from v3.3 onwards (v3.4+ is recommended for better Frontend awareness). * Configurations: Ensure the following parameters are set in your CN configuration (often passed via

config

in

values.yaml

): _ `loop_count_wait_fragments_finish`: (Default: 2) This determines how long the CN waits for running queries. The wait time is

value _ 10

seconds. Increase this if you have long-running queries. * `graceful_exit_wait_for_frontend_heartbeat`: (Recommended for v3.4+) Set to

true

to allow the FE to recognize the

SHUTDOWN

state before the node actually stops. 2. Update the Replica Count Identify the CN section in your Helm

values.yaml

file (or the

StarRocksCluster

CR if using the Operator) and reduce the

replicaCount

or

replicas

. Example

values.yaml

snippet:

yaml
starrocksCnSpec:
  replicas: 0  # Set to 0 to shut down all CNs, or reduce the number to scale down

Apply the change:

bash
helm upgrade <release_name> starrocks/starrocks-cluster -f values.yaml

3. What Happens During Shutdown When the Helm/Operator updates the cluster: 1. SIGTERM Signal: Kubernetes sends a

SIGTERM

signal to the CN Pod. 2. State Transition: The CN process catches this signal and marks its status as SHUTDOWN. 3. New Task Rejection: The CN begins rejecting new query fragments. 4. Wait for In-flight Queries: The CN continues processing existing query fragments until they complete or the

loop_count_wait_fragments_finish

timeout is reached. 5. FE Awareness: (In v3.4+) The FE receives the

SHUTDOWN

status via heartbeat and immediately stops routing new queries to that node. 6. Termination: Once all fragments are finished or the timeout expires, the CN process exits, and the Pod is removed. 4. Monitor the Process You can monitor the status of the CN nodes during the shutdown by running the following SQL command on your FE:

sql
SHOW COMPUTE NODES;

*

Alive

: Will remain

true

until the process actually stops. *

StatusCode

: Should transition to

SHUTDOWN

while it is waiting for queries to finish, then to

DISCONNECTED

once it has fully exited. Important Notes * Termination Grace Period: Ensure your Kubernetes

terminationGracePeriodSeconds

(default 30s) is longer than your StarRocks graceful exit timeout (

loop_count_wait_fragments_finish * 10

). If K8s kills the Pod before the CN finished its wait loop, queries may fail. * CN vs BE: Unlike Backends (BE), CNs do not store data tablets. Therefore, you do not need to run

ALTER SYSTEM DECOMMISSION BACKEND

. Simply scaling down the replicas is the correct and clean way to remove CNs. References • deployment/downgrade.md • administration/management/graceful_exit.md • deployment/sr_operator.md • deployment/upgrade.md

@Rocky I am creating few users in starrocks db and assigning them roles and privileges. Now I want to set a process to rotate those users password. What is the recommended way?

Hi! I'm Rocky. For rotating user passwords in StarRocks, the recommended approach depends on whether you are managing human users or application service accounts. Since StarRocks does not currently have a built-in automated "Password Rotation Policy" (like an expiration timer), you should use one of the following three methods: 1. The Recommended Way: External Authentication (LDAP/AD) For organizations, the best practice is to not manage passwords inside StarRocks. Instead, integrate StarRocks with your central identity provider like LDAP or Active Directory. * Why: Password rotation, complexity rules, and expiration are managed once in LDAP. When a user’s password expires or changes there, it automatically applies to StarRocks. * How: Create users with the LDAP authentication method:

sql
    CREATE USER 'username' IDENTIFIED WITH authentication_ldap_simple AS 'uid=username,ou=users,dc=example,dc=com';

Note: You will also need to configure the LDAP server settings in your

fe.conf

. 2. The Automated Way: Secrets Management Tools (Vault/AWS/GCP) For application users or automated processes, use a secrets manager like HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager. * Why: These tools can automatically rotate passwords and update the application’s configuration without downtime. * How: Since StarRocks is MySQL-compatible, you can use the standard MySQL database engine/plugin in these tools. The tool will log in to StarRocks and execute the rotation command for you:

sql
    ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_secure_password';

3. The Native/Scripted Way (Manual) If you prefer to keep authentication native to StarRocks, you must set up an external process (e.g., a Jenkins job, Crontab, or Python script) to rotate passwords. * Execution: Use the

ALTER USER

or

SET PASSWORD

command.

sql
    -- For another user (requires user_admin role)
    ALTER USER 'jack'@'172.10.1.10' IDENTIFIED BY 'new_password_123';

    -- For yourself
    SET PASSWORD = PASSWORD('my_new_password_456');

* Tip: You can check the current authentication properties for users using:

sql
    SHOW AUTHENTICATION;

Summary Recommendation * For Team Members: Use LDAP/AD integration. * For Applications: Use HashiCorp Vault or a Cloud Secret Manager (via MySQL protocol). * For Kubernetes: If you use the StarRocks Operator, you can manage the

root

password and other credentials via Kubernetes Secrets. References • sql-reference/System_variable.md • administration/management/FE_configuration.md

@Rocky How is this done? For Kubernetes: If you use the StarRocks Operator, you can manage the

root

password and other credentials via Kubernetes Secrets.

To manage the

root

password and other credentials in a Kubernetes environment using the StarRocks Operator, you primarily use Kubernetes Secrets coupled with the Operator's configuration fields. There are two distinct scenarios: Initial Setup and Ongoing Management (Rotation). 1. Initial Setup (Fresh Deployment) If you are deploying a new cluster using the Helm chart (

kube-starrocks

), you can define the root password so that the Operator initializes it immediately. * Step 1: Create the Secret

bash
    kubectl create secret generic starrocks-root-pass --from-literal=password='your_secure_password'

* Step 2: Update

values.yaml

In your Helm values, enable the initialization and point it to the secret:

yaml
    starrocks:
      initPassword:
        enabled: true
        passwordSecret: starrocks-root-pass  # The name of the secret

Note: The Operator expects the secret to have a key named

password

. ────────── 2. Ongoing Management & Rotation The

initPassword

setting only works during the first installation. If you change the secret later and run

helm upgrade

, the password inside the database will not change. To rotate the password for an existing cluster so the Operator can still manage it (e.g., for scaling or upgrades), follow these steps: Step A: Update the Password in StarRocks Connect to the cluster via MySQL client and run:

sql
SET PASSWORD FOR 'root' = PASSWORD('new_secure_password');

Step B: Update the Kubernetes Secret Update your existing secret with the new password:

bash
kubectl create secret generic starrocks-root-pass \
  --from-literal=password='new_secure_password' \
  --dry-run=client -o yaml | kubectl apply -f -

Step C: Inject the Password into the Operator/Pods The Operator needs this password to perform management tasks. You must inject it as an environment variable (

MYSQL_PWD

) into the FE and BE specs. In your

StarRocksCluster

CRD or Helm `values.yaml`:

yaml
starrocks:
  starrocksFESpec:
    feEnvVars:
      - name: "MYSQL_PWD"
        valueFrom:
          secretKeyRef:
            name: starrocks-root-pass
            key: password
  starrocksBeSpec:
    beEnvVars:
      - name: "MYSQL_PWD"
        valueFrom:
          secretKeyRef:
            name: starrocks-root-pass
            key: password

Once you apply this, the Operator will trigger a rolling restart of the pods. The pods will then pick up the new password from the environment variable. ────────── 3. Managing "Other" Users The StarRocks Operator does not currently have a "User CRD" to automatically sync Kubernetes Secrets into the database's internal user tables for non-root users. For other application users, the recommended pattern is: 1. Creation: Create the user manually (or via a startup script/Job) in StarRocks. 2. Application Access: Store that user's credentials in a Kubernetes Secret. 3. Consumption: Mount that secret into your Application Pods (not the StarRocks pods) as environment variables or files so the app can connect to StarRocks. Summary Tip If you want to automate this entire flow (updating the DB password + updating the K8s secret + restarting pods), consider using: * External Secrets Operator (ESO): To sync passwords from Vault/AWS Secrets Manager into K8s Secrets. * Reloader: A Kubernetes controller that can watch your Secrets and automatically trigger a rolling upgrade of your StarRocks cluster whenever the secret changes. References • deployment/sr_operator.md • quick_start/helm.md • administration/user_privs/authentication/native_authentication.md References • quick_start/helm.md