Modify MongoDB Parameters

Database reconfiguration involves modifying parameters, settings, or configurations to optimize performance, security, or availability. Parameter changes fall into two categories:

For static parameters, KubeBlocks minimizes downtime by:

1. Modifying and restarting replica nodes first
2. Performing a switchover to promote the updated replica as primary (typically completes in milliseconds)
3. Restarting the original primary node

This guide demonstrates how to modify both dynamic and static parameters of a MongoDB cluster managed by KubeBlocks using a Reconfiguring OpsRequest.

Prerequisites

Before proceeding, ensure the following:

• Environment Setup:
  • A Kubernetes cluster is up and running.
  • The kubectl CLI tool is configured to communicate with your cluster.
  • KubeBlocks CLI and KubeBlocks Operator are installed. Follow the installation instructions here.
• Namespace Preparation: To keep resources isolated, create a dedicated namespace for this tutorial:

kubectl create ns demo
namespace/demo created

Deploy a MongoDB Cluster

KubeBlocks uses a declarative approach for managing MongoDB Replication Clusters. Below is an example configuration for deploying a MongoDB ReplicaSet Cluster with one primary replica and two secondary replicas.

Apply the following YAML configuration to deploy the cluster:

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: mongo-cluster
  namespace: demo
spec:
  terminationPolicy: Delete
  clusterDef: mongodb
  topology: replicaset
  componentSpecs:
    - name: mongodb
      serviceVersion: "6.0.21"
      replicas: 3
      resources:
        limits:
          cpu: '0.5'
          memory: 0.5Gi
        requests:
          cpu: '0.5'
          memory: 0.5Gi
      volumeClaimTemplates:
        - name: data
          spec:
            storageClassName: ""
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi

Verifying the Deployment

Monitor the cluster status until it transitions to the Running state:

kubectl get cluster mongo-cluster -n demo -w

Expected Output:

kubectl get cluster mongo-cluster -n demo
NAME            CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
mongo-cluster   mongodb              Delete               Creating   49s
mongo-cluster   mongodb              Delete               Running    62s

Check the pod status and roles:

kubectl get pods -l app.kubernetes.io/instance=mongo-cluster -L  kubeblocks.io/role -n demo

Expected Output:

NAME                      READY   STATUS    RESTARTS   AGE   ROLE
mongo-cluster-mongodb-0   2/2     Running   0          78s   primary
mongo-cluster-mongodb-1   2/2     Running   0          63s   secondary
mongo-cluster-mongodb-2   2/2     Running   0          48s   secondary

Once the cluster status becomes Running, your MongoDB cluster is ready for use.

Check Parameter Values

Retrieve Credentials

KubeBlocks automatically creates a secret containing the MongoDB root credentials. Retrieve the credentials with the following commands:

NAME=`kubectl get secrets -n demo mongo-cluster-mongodb-account-root -o jsonpath='{.data.username}' | base64 -d`
PASSWD=`kubectl get secrets -n demo mongo-cluster-mongodb-account-root -o jsonpath='{.data.password}' | base64 -d`

Access MongoDB Cluster

To connect to the cluster's primary node, use the MongoDB client:

kubectl exec -it -n demo mongo-cluster-mongodb-0 -c mongodb --  mongosh "mongodb://${NAME}:${PASSWD}@mongo-cluster-mongodb-mongodb.demo.svc.cluster.local:27017/admin"

Query Parameter Values

Once connected, you can query current comand line options:

admin>  db.adminCommand('getCmdLineOpts')
{
  "systemLog" : {
    "verbosity" : 0,
    "quiet" : false
  },
  ...
}

Static Parameter Example: Modifying shared_buffers

Change parameters like systemLog.verbosity require a restart. This example increases the verbosity to 1 and set the quiet option to true.

Create a Reconfigure OpsRequest. Apply the following OpsRequest YAML to update the options.

apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: mongo-reconfiguring
  namespace: demo
spec:
  clusterName: mongo-cluster
  reconfigures:
  - componentName: mongodb
    parameters:
    - key: systemLog.verbosity
      value: "1"
    - key: systemLog.quiet
      value: "true"
  type: Reconfiguring

Check the status of the OpsRequest until it completes:

kubectl get ops mongo-reconfiguring -n demo -w

Example Output:

NAME                  TYPE            CLUSTER         STATUS    PROGRESS   AGE
mongo-reconfiguring   Reconfiguring   mongo-cluster   Running   -/-        13s
mongo-reconfiguring   Reconfiguring   mongo-cluster   Succeed   -/-        82s
mongo-reconfiguring   Reconfiguring   mongo-cluster   Succeed   -/-        82s

Secondary replicas will be restarted first, then the primary replica will be restarted. When restarting the primary replica, a switchover will be performed to promote the updated replica as primary to reduce downtime.

Verify the Configuration Change

Log into the MongoDB instance and confirm that the systemLog.verbosity and systemLog.quiet options have been updated:

admin> db.adminCommand('getCmdLineOpts')
{
  "systemLog" : {
    "verbosity" : 1,
    "quiet" : true
  },
  ...
}

Cleanup

To remove all created resources, delete the MongoDB cluster along with its namespace:

kubectl delete cluster mongo-cluster -n demo
kubectl delete ns demo

Summary

This guide covered modifying MongoDB parameters through KubeBlocks:

• Static changes (e.g., systemLog.verbosity) require restart but with minimal downtime
• All changes are validated before application
• Configuration follows declarative management principles