This chapter describes three different ways to upgrade Galera Cluster.
You can carry out a rolling upgrade on a Galera Cluster by applying the following steps on each cluster node:
Note
Transfer all clients connections from the node to be upgraded to the other nodes for the time of migration.
Tip
If the upgraded node has been or will be part of a weighted quorum, set the initial node weight to zero. In this way, it can be guaranteed that if the joining node fails before it gets synchronized, it does not have effect in the quorum computation that follows.
The main advantage of a rolling upgrade is that if something goes wrong with the upgrade, the other nodes are still operational and you have time to troubleshoot the problem.
However, rolling upgrade has some issues which deserve consideration:
A bulk upgrade upgrades all nodes in an idle cluster to avoid time-consuming state transfers. Bulk upgrade produces a short but complete service outage. You can carry out a bulk upgrade on a Galera Cluster as follows:
Note
You can carry out steps 2-3-4 on all nodes in parallel, therefore reducing the service outage time to virtually the time needed for a single server restart.
Warning
Always use this method for a two-node cluster upgrade, as the rolling upgrade would result in a much longer service outage.
The main advantage of the bulk upgrade is that, for huge databases, it is faster and results in better availability than the rolling upgrade. The main drawback of the bulk upgrade is that it relies on the upgrade and the restart will be quick. However shutting down an InnoDB may take up a few minutes (as it flushes dirty pages), and if something goes wrong during the upgrade, there is hardly any time to troubleshoot and fix the problem. Therefore, do not upgrade all nodes at once, but try it first on a single node.
If only a Galera provider upgrade is required, the bulk upgrade can be further optimized to only take a few seconds. The following is an example for a 64-bit CentOS (or RHEL):
# rpm -e galera
# rpm -i <new galera rpm>
mysql> SET GLOBAL wsrep_provider='none';
mysql> SET GLOBAL wsrep_provider='/usr/lib64/galera/libgalera_smm.so';
mysql> SET GLOBAL wsrep_cluster_address='gcomm://'
mysql> SET GLOBAL wsrep_cluster_address='gcomm://node1'
Reloading the provider and connecting to the cluster takes typically less than 10 seconds; there is virtually no service outage.
Important
In the provider-only upgrade, the warmed up InnoDB buffer pool is fully preserved and the cluster will continue to operate at full speed as soon as the load is resumed.