Sign inTry Free

Perform an Upgrade

On this page

Upgrades include either upgrading the Operator, or upgrading the SingleStore YAML configuration files.

As new versions of the Kubernetes API are released, some of these object manifests will need to be updated to match the updates to the Kubernetes API. When upgrading the Kubernetes version and the Operator, SingleStore recommends updating all of these object definitions to ensure that they are utilizing the proper Kubernetes API version for these objects.

SingleStore recommends using the latest object definition files when performing an upgrade and upgrading one component at a time.

Upgrade the Operator

Note

Please confirm that the cluster is stable before performing the upgrade.

Typically, upgrading the Operator will cause the cluster to restart.

  1. Edit the sdb-operator.yaml file and update spec.template.spec.containers[0].image with a later version of Operator image.

    Note: When upgrading from Operator 1.2.5 or earlier, be sure to include the required --cluster-id field and a value to this file. Refer to the sdb-operator.yaml file for additional information.

  2. Apply the upgrade.

    kubectl apply -f sdb-operator.yaml

Upgrade the SingleStore Engine

Note

To upgrade to SingleStore version 8.1 and later, you must first upgrade the Operator to version 3.40.3 or later.

Please confirm that the cluster is stable before performing the upgrade. Reviewing the Operator log to confirm that there are no general Operator operations in progress is recommended.

  1. Edit the sdb-cluster.yaml file and replace spec.nodeImage.repository and spec.nodeImage.tag with a later version of the node image.

  2. Apply the upgrade.

    kubectl apply -f sdb-cluster.yaml

Should an upgrade to SingleStore version 8.1 either stall or fail:

  1. Update spec.template.spec.containers[0].image to singlestore/operator:3.40.3-d2c54262.

  2. Delete the leaf-ag1 StatefulSet.

Warning

It is only possible to upgrade to a later SingleStore engine image. The engine upgrade cannot be rolled back.

Note

Existing cluster monitoring instances can be configured to collect event traces after upgrading a cluster to SingleStore v8.5 or later. Refer to Query History for more information on how to fully enable this feature.

  1. Add --collect-event-traces to your existing start-monitoring-job.yaml file.

    HTTP Connections 

    [...]
            command: ["sdb-admin",
                      "start-monitoring-kube",
                      "--user=<database-user>",
                      "--password=<database-user-password>",
                      "--collect-event-traces",
                      "--exporter-host=<exporter-hostname>",
                      "--yes"
    		<other options…>
                      ]
    [...]

    HTTPS Connections 

    [...]
            command: ["sdb-admin",
                      "start-monitoring-kube",
                      "--user=<database-user>",
                      "--password=<database-user-password>",
                      "--collect-event-traces",
                      "--exporter-host=<exporter-hostname>",
                      "--ssl-ca=/etc/memsql/extra-secret/ssl-ca",
                      "--yes"
    		<other options…>
                      ]
    [...]

  2. Restart monitoring.

    kubectl apply -f start-monitoring-job.yaml

Last modified: November 8, 2023

Was this article helpful?

On this page

Was this article helpful?