Skip to content
logo
Percona Operator for MongoDB
Upgrading Percona Server for MongoDB manually
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
        • Rolling Update strategy and semi-automatic updates
        • Manual upgrade (the On Delete strategy)
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Rolling Update strategy and semi-automatic updates
    • Manual upgrade (the On Delete strategy)

    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:

    1. Edit the deploy/cr.yaml file, setting updateStrategy key to RollingUpdate.

    2. 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" }
         }}'
      
    3. 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:

    1. Edit the deploy/cr.yaml file, setting updateStrategy key to OnDelete.

    2. 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" }
         }}'
      
    3. 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
        
    4. 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-03-30
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.