Since MariaDB 10.1, the MySQL-wsrep patch has been merged into MariaDB Server. Therefore, in MariaDB 10.1 and above, the functionality of MariaDB Galera Cluster can be obtained by installing the standard MariaDB Server packages and the Galera wsrep provider library package.
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.
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:
Before you upgrade, it would be best to take a backup of your database. This is always a good idea to do before an upgrade. We would recommend Mariabackup.
Then, for each node, perform the following steps:
0. It can be changed dynamically with
SET GLOBAL. For example:
SET GLOBAL innodb_fast_shutdown=0;
sudo apt-get remove mariadb-server galera
sudo yum remove MariaDB-server galera
sudo zypper remove MariaDB-server galera
my.cnf. This includes removing any system variables or options that are no longer supported.
innodb_lock_schedule_algorithmsystem 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.
systemdyou 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.
mysql_upgradedoes two things:
mysqldatabase are fully compatible with the new version.
When this process is done for one node, move onto the next node.
Note that when upgrading the Galera wsrep provider, sometimes the Galera protocol version can change. The Galera wsrep provider should not start using the new protocol version until all cluster nodes have been upgraded to the new version, so this is not generally an issue during a rolling upgrade. However, this can cause issues if you restart a non-upgraded node in a cluster where the rest of the nodes have been upgraded.
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.
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_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.
Some state transfers require the server to be unavailable, such as all State Snapshot Transfer(SST) methods other than
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)
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.