Update Percona Server for MongoDB Operator

Starting from the version 1.1.0 the Percona Kubernetes Operator for MongoDB allows upgrades to newer versions. This includes upgrades of the Operator itself, and upgrades of the Percona Server for MongoDB.

Upgrading the Operator

This upgrade can be done either in semi-automatic or in manual mode.

Note

Manual update mode is the recommended way for a production cluster.

Semi-automatic upgrade

Note

Only the incremental update to a nearest minor version is supported (for example, update from 1.5.0 to 1.6.0). To update to a newer version, which differs from the current version by more than one, make several incremental updates sequentially.

  1. Update the Custom Resource Definition file for the Operator, taking it from the official repository on Github, and do the same for the Role-based access control:

    kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.6.0/deploy/crd.yaml
    kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.6.0/deploy/rbac.yaml
    
  2. Edit the deploy/cr.yaml file, setting updateStrategy key to RollingUpdate.

  3. Now you should apply a patch to your deployment, supplying necessary image names with a newer version tag. This is done with the kubectl patch deployment command. For example, updating to the 1.6.0 version should look as follows:

    kubectl patch deployment percona-server-mongodb-operator \
       -p'{"spec":{"template":{"spec":{"containers":[{"name":"percona-server-mongodb-operator","image":"percona/percona-server-mongodb-operator:1.6.0"}]}}}}'
    
    kubectl patch psmdb my-cluster-name --type=merge --patch '{
       "spec": {
           "crVersion":"1.6.0",
           "image": "percona/percona-server-mongodb:4.4.2-4",
           "backup": { "image": "percona/percona-server-mongodb-operator:1.6.0-backup" },
           "pmm": { "image": "percona/pmm-client:2.12.0" }
       }}'
    
  4. The deployment rollout will be automatically triggered by the applied patch. You can track the rollout process in real time using the kubectl rollout status command with the name of your cluster:

    kubectl rollout status sts my-cluster-name-rs0
    

Manual upgrade

Note

Only the incremental update to a nearest minor version of the Operator is supported (for example, update from 1.5.0 to 1.6.0). To update to a newer version, which differs from the current version by more than one, make several incremental updates sequentially.

  1. Update the Custom Resource Definition file for the Operator, taking it from the official repository on Github, and do the same for the Role-based access control:

    kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.6.0/deploy/crd.yaml
    kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.6.0/deploy/rbac.yaml
    
  2. Edit the deploy/cr.yaml file, setting updateStrategy key to OnDelete.

  3. Now you should apply a patch to your deployment, supplying necessary image names with a newer version tag. This is done with the kubectl patch deployment command. For example, updating to the 1.6.0 version should look as follows:

    kubectl patch deployment percona-server-mongodb-operator \
       -p'{"spec":{"template":{"spec":{"containers":[{"name":"percona-server-mongodb-operator","image":"percona/percona-server-mongodb-operator:1.6.0"}]}}}}'
    
    kubectl patch psmdb my-cluster-name --type=merge --patch '{
       "spec": {
           "crVersion":"1.6.0",
           "image": "percona/percona-server-mongodb:4.4.2-4",
           "backup": { "image": "percona/percona-server-mongodb-operator:1.6.0-backup" },
           "pmm": { "image": "percona/pmm-client:2.12.0" }
       }}'
    
  4. Pod with the newer Percona Server for MongoDB image will start after you delete it. Delete targeted Pods manually one by one to make them restart in the desired order:

    1. Delete the Pod using its name with the command like the following one:

      kubectl delete pod my-cluster-name-rs0-2
      
    2. Wait until Pod becomes ready:

      kubectl get pod my-cluster-name-rs0-2
      

      The output should be like this:

      NAME                    READY   STATUS    RESTARTS   AGE
      my-cluster-name-rs0-2   1/1     Running   0          3m33s
      
  5. The update process is successfully finished when all Pods have been restarted.

Upgrading Percona Server for MongoDB

Starting from version 1.5.0, the Operator can do fully automatic upgrades to the newer versions of Percona Server for MongoDB within the method named Smart Updates.

To have this upgrade method enabled, make sure that the updateStrategy key in the deploy/cr.yaml configuration file is set to SmartUpdate.

When automatic updates are enabled, the Operator will carry on upgrades according to the following algorithm. It will query a special Version Service server at scheduled times to obtain fresh information about version numbers and valid image paths needed for the upgrade. If the current version should be upgraded, the Operator updates the CR to reflect the new image paths and carries on sequential Pods deletion in a safe order, allowing StatefulSet to redeploy the cluster Pods with the new image.

The upgrade details are set in the upgradeOptions section of the deploy/cr.yaml configuration file. Make the following edits to configure updates:

  1. Set the apply option to one of the following values:

    • Recommended - automatic upgrades will choose the most recent version of software flagged as Recommended (for clusters created from scratch, the Percona Server for MongoDB 4.4 version will be selected instead of the Percona Server for MongoDB 4.2 or 4.0 version regardless of the image path; for already existing clusters, the 4.4 vs. 4.2 or 4.0 branch choice will be preserved),

    • Latest - automatic upgrades will choose the most recent version of the software available (for clusters created from scratch, the Percona Server for MongoDB 4.4 version will be selected instead of the Percona Server for MongoDB 4.2 or 4.0 version regardless of the image path; for already existing clusters, the 4.4 vs. 4.2 or 4.0 branch choice will be preserved),

    • specific version number - will apply an upgrade if the running Percona Server for MongoDB version doesn’t match the explicit version number with no future upgrades (version numbers are specified as 4.4.2-4, 4.2.11-12, etc.),

    • Never or Disabled - disable automatic upgrades

      Note

      When automatic upgrades are disabled by the apply option, Smart Update functionality will continue working for changes triggered by other events, such as rotating a password, or changing resource values.

  2. Make sure the versionServiceEndpoint key is set to a valid Version Server URL (otherwise Smart Updates will not occur).

    1. You can use the URL of the official Percona’s Version Service (default). Set versionServiceEndpoint to https://check.percona.com.

    2. Alternatively, you can run Version Service inside your cluster. This can be done with the kubectl command as follows:

      kubectl run version-service --image=perconalab/version-service --env="SERVE_HTTP=true" --port 11000 --expose
      

    Note

    Version Service is never checked if automatic updates are disabled. If automatic updates are enabled, but Version Service URL can not be reached, upgrades will not occur.

  3. Use the schedule option to specify the update checks time in CRON format.

The following example sets the midnight update checks with the official Percona’s Version Service:

spec:
  updateStrategy: SmartUpdate
  upgradeOptions:
    apply: Recommended
    versionServiceEndpoint: https://check.percona.com
    schedule: "0 0 * * *"
...

Contact Us

For free technical help, visit the Percona Community Forum.
To report bugs or submit feature requests, open a JIRA ticket.
For paid support and managed or professional services, contact Percona Sales.