Chapter 4 Upgrading MySQL Operator

Upgrading MySQL Operator

Apply MySQL Operator's latest released CRDs to create a new MySQL Operator deployment that replaces the old. The old operator is terminated after the new operator is started and ready, which should not cause downtime.

kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/trunk/deploy/deploy-crds.yaml
kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/trunk/deploy/deploy-operator.yaml

Note

This only updates MySQL Operator and not the associated MySQL InnoDB Cluster.

Using trunk in the URL references the latest MySQL Operator for Kubernetes release because Github is updated at release time. Alternatively, replace trunk in the URL with a specific tagged released version.

Upgrading MySQL InnoDB Cluster

This assumes you already upgraded MySQL Operator.

A common upgrade method is to patch the MySQL server version. For example, this updates the MySQL Server version to 8.0.34 for a MySQL InnoDB Cluster named mycluster:

kubectl patch ic mycluster -p '{"spec": { "version": "8.0.34" } }' --type=merge

An update to spec.version for a MySQL InnoDB Cluster updates the following:

• Each MySQL server, in a rolling update

  Updating a MySQL InnoDB Cluster initiates a rolling restart of the MySQL servers; the upgrade replaces MySQL servers in order, by highest value in the name to lowest. This can cause multiple failovers of the primary, depending on the current and assigned primaries.

• MySQL Router to the specified spec.version unless spec.router.version is also explicitly set in the patch

• The MySQL sidecar container for each server to the installed MySQL Operator version

• MySQL Shell to the specified spec.version

The MySQL InnoDB Cluster remains available during the upgrade process but the associated restarts may interrupt existing connections.