Skip to main content

FE Configuration

FE parameters are classified into dynamic parameters and static parameters.

  • Dynamic parameters can be configured and adjusted by running SQL commands, which is convenient and takes effect immediately. The change does not survive an FE restart, though — and on Kubernetes an FE pod restarts for reasons you did not ask for, such as a rolling upgrade, a node drain or a rescheduled pod. Treat a SQL change as temporary, and make anything permanent in the FE ConfigMap as well.

  • Static parameters can only be set in the FE configuration file fe.conf, and the FE must restart before a change takes effect. On Kubernetes you do not edit that file: it is projected into the pod from a ConfigMap, and an edit made inside the pod is discarded by the very restart that was supposed to apply it. See Configure FE static parameters below.

Whether a parameter is a dynamic parameter is indicated by the IsMutable column in the output of ADMIN SHOW CONFIG. TRUE indicates a dynamic parameter.

Note that both dynamic and static FE parameters can be set in the ConfigMap that supplies fe.conf.

View FE configuration items​

After your FE is started, you can run the ADMIN SHOW FRONTEND CONFIG command on your MySQL client to check the parameter configurations. If you want to query the configuration of a specific parameter, run the following command:

ADMIN SHOW FRONTEND CONFIG [LIKE "pattern"];

For detailed description of the returned fields, see ADMIN SHOW CONFIG.

note

You must have administrator privileges to run cluster administration-related commands.

Configure FE parameters​

Configure FE dynamic parameters​

You can configure or modify the settings of FE dynamic parameters using ADMIN SET FRONTEND CONFIG.

ADMIN SET FRONTEND CONFIG ("key" = "value");
note

A change made with ADMIN SET FRONTEND CONFIG lives in the running FE only. When the FE restarts, the value from fe.conf takes over again and the change is lost. On Kubernetes that matters more than it does on a host, because FE pods restart on their own — a rolling upgrade, a node drain, an evicted or rescheduled pod. If the change is meant to be permanent, set it in the FE ConfigMap too, as described under Configure FE static parameters below.

Configure FE static parameters​

Change the ConfigMap that supplies fe.conf, then restart the FEs. There are two routes, depending on how the cluster was deployed.

With Helm, add the parameter to phoenixai.phoenixAIFeSpec.config in your values file and run helm upgrade:

phoenixai:
  phoenixAIFeSpec:
    config: |
      # ... the rest of fe.conf, unchanged ...
      audit_log_delete_age = 7d

The chart hashes the rendered configuration into a pod annotation, so helm upgrade rolls the FE StatefulSet on its own and the new value takes effect.

warning

config replaces fe.conf in full — it is not merged with the chart's default. Copy the whole block out of the chart's values.yaml and add your parameter to it, or the FEs start without http_port, query_port, JAVA_OPTS and everything else the default sets. configyaml, the map form of the same setting, behaves the same way and additionally discards config when it is set.

With the operator alone, edit the ConfigMap named by phoenixAIFeSpec.configMapInfo on the PhoenixAICluster, then restart the FEs yourself. The operator does not watch that ConfigMap, and the configuration hash above is a chart feature rather than an operator one, so nothing rolls the pods for you:

kubectl -n <namespace> rollout restart statefulset <cluster-name>-fe
kubectl -n <namespace> rollout status  statefulset <cluster-name>-fe

The StatefulSet replaces one FE at a time; let each one rejoin the cluster before the next is restarted.

See Deploy with Operator or Deploy with Helm for creating the ConfigMap in the first place.

Parameter groups​

The parameters are grouped in these categories: