This guide describes how to upgrade your Milvus standalone with Milvus operator.
Run the following command to upgrade the version of your Milvus operator to v0.9.6.
helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
helm repo update zilliztech-milvus-operator
helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
Once you have upgraded your Milvus operator to the latest version, you have the following choices:
- To upgrade Milvus from v2.2.3 or later releases to 2.3.9, you can conduct a rolling upgrade.
- To upgrade Milvus from a minor release before v2.2.3 to 2.3.9, you are advised to upgrade Milvus by changing its image version.
- To upgrade Milvus from v2.1.x to 2.3.9, you need to migrate the metadata before the actual upgrade.
Since Milvus 2.2.3, you can configure Milvus coordinators to work in active-standby mode and enable the rolling upgrade feature for them, so that Milvus can respond to incoming requests during the coordinator upgrades. In previous releases, coordinators are to be removed and then created during an upgrade, which may introduce certain downtime of the service.
Based on the rolling update capabilities provided by Kubernetes, the Milvus operator enforces an ordered update of the deployments according to their dependencies. In addition, Milvus implements a mechanism to ensure that its components remain compatible with those depending on them during the upgrade, significantly reducing potential service downtime.
The rolling upgrade feature is disabled by default. You need to explicitly enable it through a configuration file.
imageUpdateMode: rollingUpgrade # Default value, can be omitted
In this above configuration file, set
true and set
spec.components.image to the desired Milvus version.
By default, Milvus performs a rolling upgrade for coordinators in an ordered way, in which it replaces the coordinator pod images one after another. To reduce the upgrade time, consider setting
all so that Milvus replaces all pod images at the same time.
You can set
rollingDowngrade to have Milvus replace coordinator pod images with a lower version.
Then save your configuration as a YAML file (for example,
milvusupgrade.yml) and apply this configuration file to your Milvus instance as follows:
kubectl apply -f milvusupgrade.yml
In normal cases, you can simply update your Milvus to the latest by changing its image. However, note that there will be a certain downtime when upgrading Milvus in this way.
Compose a configuration file as follows and save it as milvusupgrade.yaml:
# Omit other fields ...
Then run the following to perform the upgrade:
kubectl apply -f milvusupgrade.yaml
Since Milvus 2.2.0, the metadata is incompatible with that in previous releases. The following example snippets assume an upgrade from Milvus 2.1.4 to Milvus v2.3.9.
Create a metadata migration file. The following is an example. You need to specify the
targetVersion in the configuration file. The following example sets the
v2.3.9. This means that your Milvus instance will be upgraded from v2.1.4 to v2.3.9.
# below are some omit default values:
# targetImage: "milvusdb/milvus:v2.3.9"
# toolImage: "milvusdb/meta-migration:v2.2.0"
# operation: upgrade
# rollbackIfFailed: true
# backupPVC: ""
# maxRetry: 3
Run the following command to apply the new configuration.
$ kubectl apply -f https://github.com/zilliztech/milvus-operator/blob/main/config/samples/beta/milvusupgrade.yaml
Run the following command to check the status of your metadata migration.
kubectl describe milvus release-name
The status of
ready in the output means that the metadata migration is successful.
Or, you can also run
kubectl get pod to check all the pods. If all the pods are
ready, the metadata migration is successful.
When the upgrade is successful, delete
my-release-upgrade in the YAML file.