Operator Upgrades

In this section you can find the migration path when upgrading to a newer version of the MySQL operator.

Regarding how a MySQL cluster is affected, we will try to keep it as follows when upgrading the operator:

• PATCH versions (e.g. v0.3.2 -> v0.3.3 or v0.3.4): no restart for the MySQL cluster
• MINOR versions (e.g. v0.3.2 -> v0.4.0): the MySQL cluster will get restarted
• MAJOR versions (e.g. v0.5.0 -> v1.0.0): the MySQL cluster will get restarted and it may required manual intervention.

v0.6.x upgrade

WARN

Helm version upgrade, as well as parameter changes.

Breaking changes are included in this release. Helm 2 is not supported anymore and is replaced by Helm 3. The Kubernetes standards in label naming are also followed and this results in chart config parameters being renamed. This means you should check if you are using them and replace manually, accordingly. The list of old parameters to review is:replicas,rbac.serviceAccountName, image, sidecarImage, sidecarMysql8Image, orchestrator.image, mysqlClustersGlobalServiceMonitor.enabled, serviceMonitor, serviceMonitor.enabled, nodeAffinity, podAntiAffinity, installCRDs. Please use the parameter detailed list available in the Github repo readme .

After reviewing your parameters, consider doing the upgrade by deleting the old version and installing the new 0.6.0 version. This operation is safe and is preferrable in order to avoid failures due to change of pod labels. Services have also undergone changes in names. Database content should not be affected by this operation.

v0.5.x upgrade

This release does not require any manual interaction, but as with all major releases it should be first tested in a testing/staging environment. For actual changes you should consult the changelog .

v0.4.x upgrade

This release does not require any manual interaction, but as with all major releases it should be first tested in a testing/staging environment. For actual changes you should consult the changelog .

v0.3.x upgrade

This version requires at least Kubernetes 1.11. The upgrade should be tried on staging environment first because it’s with downtime. It requires the deletion of the statefulset and recreation of it. The reason behind is that we changed the headless service name (which is an immutable statefulset field) to make it smaller that will prevent you from hitting this bug .

The operator should do all the work for you but you have to make sure that you have the latest 0.2.x version of the operator. For a smooth upgrade, it’s recommended to have clusters with only one node or the master node to be node 0. Doing so will prevent the operator to wait for a failover.

This release drops support for emptyDir volume source.

v0.2.x upgrade

Here are described the steps that you should follow when migrating from version 0.1.x to 0.2.x of the operator.

This upgrade requires a Kubernetes cluster upgrade because the v0.2.x works only with a Kubernetes version greater or equal to 1.11.

1. Scale the current operator deployment to 0. This won’t affect your running databases.
2. Upgrade your cluster control plane to 1.11.
3. Update the installed CRDs: kubectl apply -f https://raw.githubusercontent.com/bitpoke/mysql-operator/master/hack/02x-crds.yaml
4. Upgrade the MySQL operator helm upgrade mysql-operator bitpoke/mysql-operator
5. Scale up the operator deployment
6. Now you can upgrade your nodes, as well.
7. Enjoy!