Config MetaService
MetaService is the metadata management component for Doris decoupled storage and compute clusters. It is not exposed externally and is used solely for internal purposes. MetaService is a stateless service that is typically deployed in a primary-secondary configuration. The following document describes how to configure MetaService within the DorisDisaggregatedCluster
resource.
Configuring FoundationDB Access
The method for configuring FoundationDB access varies depending on the deployment environment:
-
Using a ConfigMap to Configure FoundationDB Access
If the FoundationDB cluster is deployed with the fdb-kubernetes-operator, you can directly use the ConfigMap generated by the operator that contains the accessible FoundationDB addresses. For example:spec:
metaService:
fdb:
configMapNamespaceName:
name: ${foundationdbConfigMapName}
namespace: ${namespace}Here,
${foundationdbConfigMapName}
is the name of the ConfigMap, and${namespace}
is the namespace in which FoundationDB is deployed. For details on locating the ConfigMap generated by the fdb-kubernetes-operator, please refer to the "Deploying FoundationDB" section in Obtain the ConfigMap containing FoundationDB access information. -
Directly Configuring the FoundationDB Access Address
If FoundationDB is deployed directly on physical machines, you can specify the access address in the MetaService configuration:spec:
metaService:
fdb:
address: ${fdbEndpoint}Here,
${fdbEndpoint}
represents the accessible address information for FoundationDB. For physical machine deployments, please refer to the section on MetaService deployment for obtaining fdb_cluster details.
Configuring the Image
In the deployment sample, the MetaService image may not be the latest version. When customizing the image, please configure it as follows:
spec:
metaService:
image: ${msImage}
Here, ${msImage}
is the image you wish to deploy for MetaService. It is recommended to use the official MetaService image provided by Doris (the image tag should include the prefix "ms").
Configuring Resources
You can allocate appropriate computing resources for MetaService using Kubernetes resource limits. For example, to limit MetaService to 4 CPU cores and 4Gi of memory, configure as follows:
spec:
metaService:
requests:
cpu: 4
memory: 4Gi
limits:
cpu: 4
memory: 4Gi
Update this configuration in the corresponding DorisDisaggregatedCluster resource.
Customizing Startup Configuration
Doris-Operator uses a ConfigMap to mount the startup configuration file for components. The operator automatically populates the MetaService startup configuration with the relevant FoundationDB information, so you do not need to include these details when customizing the configuration.
- Create a Custom ConfigMap
Create a ConfigMap containing the startup configuration. The startup configuration file must be named doris_cloud.conf. For example:
apiVersion: v1
kind: ConfigMap
metadata:
name: doris-metaservice
namespace: default
data:
doris_cloud.conf: |
# // meta_service
brpc_listen_port = 5000
brpc_num_threads = -1
brpc_idle_timeout_sec = 30
http_token = greedisgood9999
# // doris txn config
label_keep_max_second = 259200
expired_txn_scan_key_nums = 1000
# // logging
log_dir = ./log/
# info, warn, error
log_level = info
log_size_mb = 1024
log_filenum_quota = 10
log_immediate_flush = false
# log_verbose_modules = *
# // max stage num
max_num_stages = 40 - Mount the Custom Startup Configuration
In the DorisDisaggregatedCluster resource, mount the ConfigMap via
metaService.configMaps
as follows:Here,spec:
metaService:
configMaps:
- name: ${msConfigMapName}
mountPath: /etc/doris${msConfigMapName}
is the name of the ConfigMap containing the MetaService startup configuration. Update this configuration in the DorisDisaggregatedCluster resource that you intend to deploy. The mount path must be/etc/doris
.
When customizing the MetaService startup configuration in a Kubernetes deployment, do not include the fdb_cluster configuration; Doris Operator will handle that automatically.
Configuring Service Probe Timeouts
Doris Operator provides two timeout parameters for decoupled storage and compute services: liveness probe timeout and startup timeout.
Liveness Probe Timeout Configuration
The liveness probe monitors the operational status of the service. If the probe fails beyond the specified threshold, the service will be forcibly restarted. The default timeout is 180 seconds. To set it to 30 seconds, use the following configuration:
spec:
metaService:
liveTimeout: 30
Startup Timeout Configuration
The startup timeout addresses scenarios where the service takes too long to start. If the service startup time exceeds the specified threshold, the service will be forcibly restarted. The default startup timeout is 300 seconds. To set it to 120 seconds, use the following configuration:
spec:
metaService:
startTimeout: 120