title | linktitle | description | keywords | menu | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
The MySQL Operator Upgrades |
Operator upgrades |
The steps to make in order to migrate the operator to a newer version of the MySQL operator. |
|
|
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:
v0.3.2
-> v0.3.3
or v0.3.4
): no restart for the MySQL clusterv0.3.2
-> v0.4.0
): the MySQL cluster will get restartedv0.5.0
-> v1.0.0
): the MySQL cluster will get restarted and it may
required manual intervention.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
.
kubectl apply -f https://raw.githubusercontent.com/presslabs/mysql-operator/master/hack/02x-crds.yaml
helm upgrade mysql-operator presslabs/mysql-operator
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 drop support for emptyDir
volume source.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。