|
| 1 | +# v0.1.* Upgrade |
| 2 | + |
| 3 | +The v0.1.* release series is the *only* release series of the MySQL Operator |
| 4 | +which supports MySQL 5.7. InnoDB Group replication and associated tooling has |
| 5 | +been dramatically improved with the GA release of MySQL 8 (8.0.11). As a result |
| 6 | +from the v0.2.0 MySQL Operator release onwards MySQL 8.0.11 is the __minimum |
| 7 | +supported version__. |
| 8 | + |
| 9 | +Due to the complexities of the upgrade path between MySQL 5.7 and MySQL 8 we |
| 10 | +aren't implementing an upgrade path between the v0.1.* and v0.2.* MySQL Operator |
| 11 | +release series. |
| 12 | + |
| 13 | +Instead users need to: |
| 14 | + |
| 15 | + 1) Backup all MySQL Clusters deployed by the MySQL Operator. NOTE: If you |
| 16 | + choose to use the inbuilt backup functionality of the MySQL Operator for |
| 17 | + this you will need to ensure you save the associated MySQLBackup resources |
| 18 | + locally, update them in line with the v0.2.0 API changes, and the recreate |
| 19 | + them after installing v0.2.0. |
| 20 | + 3) Delete the MySQL Operator release |
| 21 | + |
| 22 | + ```console |
| 23 | + $ helm delete mysql-operator |
| 24 | + ``` |
| 25 | + NOTE: You may have named the installed MySQL Operator release something |
| 26 | + different during installation (see `helm list`). |
| 27 | + 4) Follow the installation instructions to install v0.2.0 of the MySQL |
| 28 | + Operator. |
| 29 | + 5) Create replacement MySQL Clusters using the updated API and restore the |
| 30 | + backups created in step #1. |
| 31 | + |
| 32 | +## Other Breaking Changes |
| 33 | + |
| 34 | +Additionally, we have taken this opportunity to make a number of breaking |
| 35 | +changes to the MySQL Operator API to improve its usability. |
| 36 | + |
| 37 | +### API Version Downgrade |
| 38 | + |
| 39 | +We have downgraded the API Version from `v1` to `v1alpha1` to enable future |
| 40 | +iteration on the API design (taking advantage of the fact that [Custom Resource |
| 41 | +Definitions can now define multiple versions][1]) and to better reflect the |
| 42 | +stability of the MySQL Operator API. |
| 43 | + |
| 44 | +### Resource Kinds Renamed |
| 45 | + |
| 46 | +Previously the MySQL Operator Custom Resource Kinds were prefixed with MySQL |
| 47 | +(e.g. `MySQLCluster`). This prefix has been removed, however, the prefix has |
| 48 | +been maintained in the singular/plural names used when interacting via |
| 49 | +`kubectl` (e.g. `kubectl get mysqlclusters`). |
| 50 | + |
| 51 | +### API changes |
| 52 | + |
| 53 | +Numerous fields on all MySQL Operator Custom Resources have been renamed and |
| 54 | +some field types changed. Please review [`pkg/apis/mysql/v1alpha1/types.go`][2] |
| 55 | +as the definitive source of truth and see the updated [`examples/`][3]. |
| 56 | + |
| 57 | +[1]: https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/#custom-resource-definitions-can-now-define-multiple-versions |
| 58 | +[2]: https://github.com/oracle/mysql-operator/blob/master/pkg/apis/mysql/v1alpha1/types.go |
| 59 | +[3]: https://github.com/oracle/mysql-operator/tree/master/examples |
0 commit comments