[DPE-7242] Add multi-cluster refresh docs #690
Conversation
a-velasco
changed the title
a-velasco
added
documentation
|
|
||
| When a primary cluster gets refreshed, it triggers a potentially costly re-election process. To minimise this cost, all standby clusters should be refreshed before the primary. | ||
|
|
||
| <!--TODO: Mention how to identify primary cluster--> |
There was a problem hiding this comment.
juju run mysql/<n> get-cluster-status cluster-set=true
|
|
||
| **The primary cluster must be the last one to get refreshed.** | ||
|
|
||
| When a primary cluster gets refreshed, it triggers a potentially costly re-election process. To minimise this cost, all standby clusters should be refreshed before the primary. |
There was a problem hiding this comment.
While this is true, the bigger value to start on standby is, if there are issues with the upgrade, availability is not affected at all. The standby acts as a testbed in a way, ensuring that the refresh is/isn't viable in a safe fashion.
| @@ -0,0 +1,38 @@ | |||
| # How to refresh a multi-cluster deployment | |||
|
|
|||
| A MySQL multi-cluster deployment (also known as a multi-node cluster or cluster set) can be upgraded by performing a refresh of each cluster individually. | |||
There was a problem hiding this comment.
I don't recall reading multi-node cluster. Do you have a reference for that?
There was a problem hiding this comment.
I think multi-node cluster is a terminology used by MongoDB docs.
However, I agree with Paulo here: MySQL and PostgreSQL docs should only talk about multi-cluster, with the occasional exception of the cluster-set term in MySQL's case.
|
|
||
| Use the [`get-cluster-status`](https://charmhub.io/mysql/actions#get-cluster-status) Juju action to check that everything is healthy after refreshing a cluster. | ||
|
|
||
| <!---TODO: example of running get-cluster-status (and making sure the cluster-set param is True?) |
There was a problem hiding this comment.
For each cluster, it makes more sense to run with cluster-set=false (or no parameter, as this is default), since we want to evaluate the updated cluster health, i.e. if all units are online
| +------------+------------+----------+------------+ | ||
| ``` | ||
|
|
||
| Due to an upstream issue with MySQL Server version `8.0.35`, Charmed MySQL versions below [Revision 240](https://github.com/canonical/mysql-operator/releases/tag/rev240) **cannot** be refreshed beyond [Revision 196](https://github.com/canonical/mysql-operator/releases/tag/rev196). |
There was a problem hiding this comment.
We can probably simplify this by stating the following:
| Due to an upstream issue with MySQL Server version `8.0.35`, Charmed MySQL versions below [Revision 240](https://github.com/canonical/mysql-operator/releases/tag/rev240) **cannot** be refreshed beyond [Revision 196](https://github.com/canonical/mysql-operator/releases/tag/rev196). | |
| Due to an upstream issue with MySQL Server version `8.0.35`, Charmed MySQL versions below [Revision 240](https://github.com/canonical/mysql-operator/releases/tag/rev240) **cannot** be upgraded using Juju's `refresh`. |
|
|
||
| ```shell | ||
| juju refresh mysql --path=./mysql_ubuntu-22.04-amd64.charm | ||
| juju refresh mysql --path=./mysql_ubuntu-24.04-amd64.charm |
There was a problem hiding this comment.
We are still not building the charm for Ubuntu 24.04 (see charmcraft.yaml).
| ``` | ||
| > where `mysql_ubuntu-22.04-amd64.charm` is the previous revision charm file. | ||
|
|
||
| where `mysql_ubuntu-24.04-amd64.charm` is the previous revision charm file. |
There was a problem hiding this comment.
We are still not building the charm for Ubuntu 24.04 (see charmcraft.yaml).
Co-authored-by: Sinclert Pérez <sinclert.perez@canonical.com>
|
Just chatted with Alex about the single/multi-cluster structure of docs. Apologies for the back-and-forth @a-velasco He seems happy about dropping the minor upgrades terminology, as that is not something applicable to MySQL, however, he will rather have the upgrade and rollback pages within their respective collapsible sections. Reason being: whenever users face a rollback situation, they may be anxious about the state of their cluster, and follow the instructions from the wrong page. Indenting the pages within their respective folders is more error-proof.
We can chat about it on Tuesday meeting. |
Issue
Multi-cluster deployment upgrades require some special considerations that are not documented.
Solution
Updated the "Upgrades" section of the documentation to include information about multi-cluster upgrades:
Additional changes:
TODO:
Checklist