Beginning in MariaDB 10.1, Galera Cluster ships with the MariaDB Server. Upgrading a Galera Cluster node is very similar to upgrading a server from MariaDB 10.1 to MariaDB 10.2. For more information on that process as well as incompatibilities between versions, see the Upgrade Guide.

Performing a Rolling Upgrade

The following steps can be used to perform a rolling upgrade from MariaDB 10.1 to MariaDB 10.2 when using Galera Cluster. In a rolling upgrade, each node is upgraded individually, so the cluster is always operational. There is no downtime from the application's perspective.

First, before you get started:

1. First, take a look at Upgrading from MariaDB 10.1 to MariaDB 10.2 to see what has changed between the major versions.
   1. Check whether any system variables or options have been changed or removed. Make sure that your server's configuration is compatible with the new MariaDB version before upgrading.
   2. Check whether replication has changed in the new MariaDB version in any way that could cause issues while the cluster contains upgraded and non-upgraded nodes.
   3. Check whether any new features have been added to the new MariaDB version. If a new feature in the new MariaDB version cannot be replicated to the old MariaDB version, then do not use that feature until all cluster nodes have been upgrades to the new MariaDB version.
2. Next, make sure that the Galera version numbers are compatible.
   1. If you are upgrading from the most recent MariaDB 10.1 release to MariaDB 10.2, then the versions will be compatible. Both MariaDB 10.1 and MariaDB 10.2 use Galera 3 (i.e. Galera wsrep provider versions 25.3.x), so they should be compatible.
   2. See What is MariaDB Galera Cluster?: Galera wsrep provider Versions for information on which MariaDB releases uses which Galera wsrep provider versions.
3. Ideally, you want to have a large enough gcache to avoid a State Snapshot Transfer (SST) during the rolling upgrade. The gcache size can be configured by setting gcache.size For example:
   wsrep_provider_options="gcache.size=2G"

Then, for each node, perform the following steps:

1. Modify the repository configuration, so the system's package manager installs MariaDB 10.2. For example,
   • On Debian, Ubuntu, and other similar Linux distributions, see Updating the MariaDB APT repository to a New Major Release for more information.
   • On RHEL, CentOS, Fedora, and other similar Linux distributions, see Updating the MariaDB YUM repository to a New Major Release for more information.
   • On SLES, OpenSUSE, and other similar Linux distributions, see Updating the MariaDB ZYpp repository to a New Major Release for more information.
2. If you use a load balancing proxy such as MaxScale or HAProxy, make sure to drain the server from the pool so it does not receive any new connections.
3. Set innodb_fast_shutdown to 0. It can be changed dynamically with SET GLOBAL. For example:
   SET GLOBAL innodb_fast_shutdown=0;
   • This step is not necessary when upgrading to MariaDB 10.2.5 or later. Omitting it can make the upgrade process far faster. See MDEV-12289 for more information.
4. Stop MariaDB.
5. Uninstall the old version of MariaDB and the Galera wsrep provider.
   • On Debian, Ubuntu, and other similar Linux distributions, execute the following:
     sudo apt-get remove mariadb-server galera
   • On RHEL, CentOS, Fedora, and other similar Linux distributions, execute the following:
     sudo yum remove MariaDB-server galera
   • On SLES, OpenSUSE, and other similar Linux distributions, execute the following:
     sudo zypper remove MariaDB-server galera
6. Install the new version of MariaDB and the Galera wsrep provider.
   • On Debian, Ubuntu, and other similar Linux distributions, see Installing MariaDB Packages with APT for more information.
   • On RHEL, CentOS, Fedora, and other similar Linux distributions, see Installing MariaDB Packages with YUM for more information.
   • On SLES, OpenSUSE, and other similar Linux distributions, see Installing MariaDB Packages with ZYpp for more information.
7. Make any desired changes to configuration options in option files, such as my.cnf. This includes removing any system variables or options that are no longer supported.
   • In order to use Galera Cluster without problems in MariaDB 10.2, the innodb_lock_schedule_algorithm system variable must be set to FCFS. In MariaDB 10.2.12 and later, this system variable is automatically set to this value when Galera Cluster is enabled. In MariaDB 10.2.11 and before, this system variable must be set to this value manually. See MDEV-12837 for more information.
8. On Linux distributions that use systemd you may need to increase the service startup timeout as the default timeout of 90 seconds may not be sufficient. See Systemd: Configuring the Systemd Service Timeout for more information.
9. Start MariaDB.
10. Run mysql_upgrade with the --skip-write-binlog option.
    • mysql_upgrade does two things:
      1. Ensures that the system tables in the mysql database are fully compatible with the new version.
      2. Does a very quick check of all tables and marks them as compatible with the new version of MariaDB .

When this process is done for one node, move onto the next node.

Additional details

Checking Status of the State Transfer

When a node rejoins the cluster after being upgraded, it may have to perform a state transfer, such as an Incremental State Transfer (IST) or a State Snapshot Transfer(SST). It is recommended to ensure that the node's state transfer is complete before upgrading the next node in the cluster.

State Transfers that Provide Access to the Server

If the node is synchronizing with the cluster by performing a state transfer that allows access to the server, such as an Incremental State Transfer (IST) or a State Snapshot Transfer(SST) that uses the mysqldump SST method, then you can check the status of the state transfer by connecting to the server through the mysql client, then checking the wsrep_local_state_uuid and wsrep_cluster_state_uuid status variables. When they equal each other, the node is in sync with the cluster.

SELECT IF(cluster.uuid = local.uuid, "Synced", "Not Synced") AS "Cluster Status"
FROM (SELECT VARIABLE_VALUE AS "uuid"
   FROM information_schema.GLOBAL_STATUS
   WHERE VARIABLE_NAME = "wsrep_cluster_state_uuid")
   AS "cluster"
INNER JOIN (SELECT VARIABLE_VALUE AS "uuid"
   FROM information_schema.GLOBAL_STATUS
   WHERE VARIABLE_NAME = "wsrep_local_state_uuid")
   AS "local";

+----------------+
| Cluster Status |
+----------------+
| Synced         |
+----------------+

When the local and cluster UUID's come into sync, the node is again online and functioning as a part of the cluster.

State Transfers that Require the Server to be Down

Some state transfers require the server to be unavailable, such as all State Snapshot Transfer(SST) methods other than mysqldump, so mysql client access is unavailable while the state transfer is happening. In those cases, you may have to monitor the progress of the state transfer in the error log. You'll know when the SST is complete when the joiner node changes its state to SYNCED. For example:

2018-08-30 14:44:15 140694729484032 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 210248566)