Minor version upgrade of a Galera Cluster for MySQL

Mysql

Recently we got a question about how one can perform a minor version upgrade of a Galera Cluster, and today we just want to say that it is reasonably straightforward. While upgrades are a feature of Galera Manager that we are most excited to see come soon, today, doing it manually on the command line is quite simple! In this post, we will go through upgrading a 9-node geographically spread cluster, from MySQL 8.0.23 to 8.0.26. We also have extensive documentation: Upgrading Galera Cluster.

We have 3 nodes each in Singapore, London and San Francisco, making the cluster comprise of a total of 9 nodes, as we can confirm by executing: show status like ‘wsrep_cluster_size’;.

Since we installed all this via the RPM package manager on CentOS 7 by adding the YUM repository to the configuration, it was really just a case of executing: yum -y update. Of course, we planned this update for the 3 nodes in San Francisco first, node by node (i.e. a rolling upgrade), as to not take down multiple nodes at the same time. Then we repeated the process in London, and finally we did so in Singapore. The order does not matter, as long as the upgrades happen with a plan. This was an upgrade that did not stop transactions during the time either – the database continued serving.

What yum update does is that it does install MySQL and the Galera wsrep provider for us, and as we weren’t planning to make any changes to the configuration files, we just let the process run automatically. There are hooks in the RPM package to also ensure that mysql_upgrade is run automatically.

Naturally, during the upgrade, we would see that the cluster size would reduce from 9 nodes to 8 nodes temporarily, but this is expected. Configuration of the gcache was large enough to ensure that during the upgrade process, there would still be an IST.

Some select text below to verify that all nodes are updated:

mysql> select version();
+———–+
| version() |
+———–+
| 8.0.23 |
+———–+
1 row in set (0.00 sec)

mysql> show status like ‘wsrep_cluster_size’;
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 9 |
+——————–+——-+
1 row in set (0.00 sec)

Updating : mysql-wsrep-server-8.0.26- [###################### ] 67/258
Cleanup : mysql-wsrep-common-8.0.23-26.6.el7.x86_64 240/258

mysql> show status like ‘wsrep_cluster_size’;
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 8 |
+——————–+——-+
1 row in set (0.01 sec)

mysql> select * from mysql.wsrep_cluster_members;
+————————————–+————————————–+————–+———————–+
| node_uuid | cluster_uuid | node_name | node_incoming_address |
+————————————–+————————————–+————–+———————–+
| 10ff4e95-dfd8-11eb-9cd8-7ed190657de9 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galerasf-03 | AUTO |
| 113a4bb9-8010-11ec-bbe1-c38d9738c824 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galerasf-02 | AUTO |
| 4d13b29e-dfcd-11eb-8108-133e852022df | d04a1319-d89d-11eb-86c2-3fe756007e90 | galera-03 | AUTO |
| 4ec352d5-e00a-11eb-93c3-4746e95e5d89 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galerasf | AUTO |
| 6644b74f-dfcd-11eb-82cf-ca20c5363b91 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galera-02 | AUTO |
| 7a7edaa1-dfcd-11eb-b5e1-23b77330d3d5 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galera | AUTO |
| a5cc9925-dfd7-11eb-9831-b76bc19aa3a4 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galeralon-02 | AUTO |
| c0078cbd-dfd7-11eb-8877-7e671c4d3a89 | d04a1319-d89d-11eb-86c2-3fe756007e90 | galeralon-03 | AUTO |
| e7fe42fd-dfce-11eb-9675-36d358e01b8d | d04a1319-d89d-11eb-86c2-3fe756007e90 | galeralon | AUTO |
+————————————–+————————————–+————–+———————–+
9 rows in set (0.00 sec)

There you have it, upgrading a minor version is truly quite simple, as long as you’re using package management. There needs to be no downtime during such an upgrade.