How to carry on low-level manual upgrades of Percona Server for MongoDB¶

Percona Operator for MongoDB supports upgrades of the database management system (Percona Server for MongoDB) starting from the Operator version 1.1.0. The Operator 1.5.0 had automated such upgrades with a new upgrade strategy called Smart Update. Smart Update automates the upgrade process while giving the user full control over updates, so it is the most convenient upgrade strategy.

Still there may be use cases when automatic upgrade of Percona Server for MongoDB is not an option (for example, you may be using Percona Server for MongoDB with the Operator version 1.5.0 or earlier), and you have to carry on upgrades manually.

Percona Server for MongoDB can be upgraded manually using one of the following upgrade strategies:

Rolling Update, initiated manually and controlled by Kubernetes,
On Delete, done by Kubernetes on per-Pod basis when Pods are manually deleted.

Warning

In case of Smart Updates, the Operator can either detect the availability of the Percona Server for MongoDB version or rely on the user’s choice of the version. In both cases Pods are restarted by the Operator automatically in the order, which assures the primary instance to be updated last, preventing possible connection issues until the whole cluster is updated to the new settings. Kubernetes-controlled Rolling Update can’t guarantee that Pods update order is optimal from the Percona Server for MongoDB point of view.

Rolling Update strategy and semi-automatic updates¶

Semi-automatic update of Percona Server for MongoDB can be done as follows:

Edit the deploy/cr.yaml file, setting updateStrategy key to RollingUpdate.
Now you should apply a patch to your Custom Resource, setting necessary image names with a newer version tag.

Note

Check the version of the Operator you have in your Kubernetes environment. Please refer to the Operator upgrade guide to upgrade the Operator and CRD, if needed.

Patching Custom Resource is done with the kubectl patch psmdb command. Actual image names can be found in the list of certified images. For example, updating to the 1.14.0 version should look as follows:
```
$ kubectl patch psmdb my-cluster-name --type=merge --patch '{
   "spec": {
      "crVersion":"1.14.0",
      "image": "percona/percona-server-mongodb:4.4.18-18",
      "backup": { "image": "percona/percona-backup-mongodb:2.0.4" },
      "pmm": { "image": "percona/pmm-client:2.35.0" }
   }}'
```
Warning

The above command upgrades various components of the cluster including PMM Client. It is highly recommended to upgrade PMM Server before upgrading PMM Client. If it wasn’t done and you would like to avoid PMM Client upgrade, remove it from the list of images, reducing the last of two patch commands as follows:
```
$ kubectl patch psmdb my-cluster-name --type=merge --patch '{
   "spec": {
      "crVersion":"1.14.0",
      "image": "percona/percona-server-mongodb:4.4.18-18",
      "backup": { "image": "percona/percona-backup-mongodb:2.0.4" }
   }}'
```
The deployment rollout will be automatically triggered by the applied patch. You can track the rollout process in real time with the kubectl rollout status command with the name of your cluster:
```
$ kubectl rollout status sts my-cluster-name-rs0
```

Manual upgrade (the On Delete strategy)¶

Manual update of Percona Server for MongoDB can be done as follows:

Edit the deploy/cr.yaml file, setting updateStrategy key to OnDelete.
Now you should apply a patch to your Custom Resource, setting necessary image names with a newer version tag.

Note

Check the version of the Operator you have in your Kubernetes environment. Please refer to the Operator upgrade guide to upgrade the Operator and CRD, if needed.

Patching Custom Resource is done with the kubectl patch psmdb command. Actual image names can be found in the list of certified images. For example, updating to the 1.14.0 version should look as follows.
```
$ kubectl patch psmdb my-cluster-name --type=merge --patch '{
   "spec": {
      "crVersion":"1.14.0",
      "image": "percona/percona-server-mongodb:4.4.18-18",
      "backup": { "image": "percona/percona-backup-mongodb:2.0.4" },
      "pmm": { "image": "percona/pmm-client:2.35.0" }
   }}'
```
Warning

The above command upgrades various components of the cluster including PMM Client. It is highly recommended to upgrade PMM Server before upgrading PMM Client. If it wasn’t done and you would like to avoid PMM Client upgrade, remove it from the list of images, reducing the last of two patch commands as follows:
```
$ kubectl patch psmdb my-cluster-name --type=merge --patch '{
   "spec": {
      "crVersion":"1.14.0",
      "image": "percona/percona-server-mongodb:4.4.18-18",
      "backup": { "image": "percona/percona-backup-mongodb:2.0.4" }
   }}'
```
The 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
```
The update process is successfully finished when all Pods have been restarted (including the mongos and Config Server nodes, if Percona Server for MongoDB Sharding is on).

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 consulting services , contact Percona Sales.

Last update: 2023-09-11