Configuring MetaService

What you will learn in this chapter

• Configure the connection information that MetaService uses to access FoundationDB
• Customize the MetaService image version
• Allocate appropriate compute resources to MetaService
• Customize MetaService startup parameters through a ConfigMap
• Configure the liveness probe timeout and startup timeout for MetaService

Overview

MetaService is the metadata management component of a Doris storage-compute decoupled cluster. It is used only inside the cluster and is not exposed externally. It is a stateless service and is typically deployed in an active-standby mode. This chapter describes how to configure MetaService in the DorisDisaggregatedCluster resource.

The full set of configuration items is summarized below:

Configuration scenario	Configuration field	Required	Applicable scenario
Connect to FoundationDB	fdb.configMapNamespaceName or fdb.address	Required	All scenarios
Customize the image	image	Optional	When the image version in the deployment example does not meet your needs
Allocate compute resources	requests / limits	Optional	When you need to limit CPU and memory usage
Customize startup parameters	configMaps	Optional	When you need to modify the default startup parameters
Liveness probe timeout	liveTimeout	Optional	When the default 180 seconds does not meet your needs
Startup timeout	startTimeout	Optional	When the default 300 seconds does not meet your needs

1. Connect to FoundationDB

MetaService relies on FoundationDB to store metadata, so you must configure the access information for FoundationDB. There are two configuration methods, depending on how FoundationDB is deployed:

FoundationDB deployment method	Recommended configuration method	Configuration field
Deployed on Kubernetes through fdb-kubernetes-operator	Reference the ConfigMap automatically generated by the Operator	fdb.configMapNamespaceName
Deployed directly on physical machines	Specify the access address directly	fdb.address

Method 1: Configure access information through a ConfigMap

If the FoundationDB cluster is deployed through fdb-kubernetes-operator, you can directly use the ConfigMap that the Operator automatically generates, which contains the FoundationDB access address:

spec:
  metaService:
    fdb:
      configMapNamespaceName:
        name: ${foundationdbConfigMapName}
        namespace: ${namespace}

Parameter description:

• ${foundationdbConfigMapName}: the name of the ConfigMap
• ${namespace}: the namespace in which FoundationDB is deployed

To locate the ConfigMap generated by fdb-kubernetes-operator, see Get the ConfigMap that contains FoundationDB access information in the FoundationDB deployment chapter.

Method 2: Configure the access address directly

If FoundationDB is deployed on physical machines, you can specify the access address directly in the MetaService configuration:

spec:
  metaService:
    fdb:
      address: ${fdbEndpoint}

Parameter description:

• ${fdbEndpoint}: the address used to access FoundationDB

For physical machine deployments, to locate this address, see Introduction to obtaining fdb_cluster for MetaService deployment in the storage-compute decoupled chapter.

2. Customize the image

The image configured for MetaService in the deployment example may not be the latest version. To specify an image version, use the following format:

spec:
  metaService:
    image: ${msImage}

Parameter description:

• ${msImage}: the MetaService image to deploy. Use an official Doris MetaService image (the image tag includes the ms prefix).

3. Allocate compute resources

Use Kubernetes resource limits to allocate appropriate CPU and memory to MetaService. For example, the following configuration limits MetaService to 4 CPU cores and 4Gi of memory:

spec:
  metaService:
    requests:
      cpu: 4
      memory: 4Gi
    limits:
      cpu: 4
      memory: 4Gi

Apply the above configuration to the DorisDisaggregatedCluster resource you want to deploy.

4. Customize startup configuration

If the default startup parameters do not meet your needs, you can mount a custom startup configuration file through a ConfigMap. Doris-Operator implements customization by mounting the startup configuration file of each component through a ConfigMap.

The overall flow is as follows:

Stage	Description
Input	A custom doris_cloud.conf configuration file
Operation	Create a ConfigMap and mount it to the /etc/doris directory
Output	MetaService starts with the custom configuration

Tip

Doris-Operator automatically populates the FoundationDB-related settings in the MetaService startup configuration, so you do not need to (and should not) set fdb_cluster when customizing the startup configuration.

Step 1: Create a custom ConfigMap

The startup configuration file must be named doris_cloud.conf. An example is shown below:

apiVersion: v1
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
kind: ConfigMap
metadata:
  name: doris-metaservice
  namespace: default

Step 2: Mount the custom startup configuration

In the DorisDisaggregatedCluster resource, mount the ConfigMap above through metaService.configMaps:

spec:
  metaService:
    configMaps:
    - name: ${msConfigMapName}
      mountPath: /etc/doris

Parameter description:

• ${msConfigMapName}: the name of the ConfigMap that contains the MetaService startup configuration
• mountPath: the mount point must be /etc/doris

Apply the above configuration to the DorisDisaggregatedCluster resource you want to deploy.

5. Configure service probe timeouts

Doris Operator provides two timeout parameters for storage-compute decoupled cluster services:

Probe type	Configuration field	Default value	Stage	Trigger condition
Liveness probe (LivenessProbe)	liveTimeout	180 seconds	While the service is running	When the probe fails for longer than the threshold, the service is forcibly restarted
Startup timeout	startTimeout	300 seconds	During service startup	When the startup time exceeds the threshold, the service is forcibly restarted

Liveness probe timeout configuration

The liveness probe monitors the running state of the service. For example, to set the liveness probe timeout to 30 seconds:

spec:
  metaService:
    liveTimeout: 30

Startup timeout configuration

The startup timeout handles cases where the service takes too long to start. For example, to set the startup timeout to 120 seconds:

spec:
  metaService:
    startTimeout: 120