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
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.
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
unlessspec.router.version
is also explicitly set in the patchThe 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.