MariaDB Upgrade with Galera

Updated 18 September 2025

Introduction

We have the cluster of 5 nodes. We need to upgrade the MariaDB version from 10.5 to 10.6

Galera Cluster

The best way to know about the Galera Cluster details is to view the /etc/my.cnf

It shows as follows:

bash

wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_provider_options="gcache.size = 8G; gcache.page_size = 256M; gcache.name = /dbase/mysql/galera.cache; gmcast.segment=0"
wsrep_cluster_address="gcomm://10.8.80.167,10.8.80.168,10.8.80.177,10.68.3.104,10.68.3.105"
wsrep_cluster_name="vfo"
wsrep_node_address="10.8.80.167"
wsrep_node_name="ersedb01d"
wsrep_sst_donor="ersedb01e,sfodb01e,ersedb02d,ersedb02e"
wsrep_sst_method="rsync"
wsrep_sst_auth="sstuser:s3cret"
wsrep_slave_threads=74

From the above information, we can get the nodes which are part of the cluster and the most important thing is “gcache.size = 8G”. It basically shows the size which can be stored without the node being in sync state with the other nodes.

The node details can be found using the following command:

Cluster Size:

sql

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 5     |
+--------------------+-------+

Galera Cluster UUID:

sql

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid';
+--------------------------+--------------------------------------+
| Variable_name            | Value                                |
+--------------------------+--------------------------------------+
| wsrep_cluster_state_uuid | 9fbcdb14-006e-11ee-88a8-0bb996970197 |
+--------------------------+--------------------------------------+

Included IP Addresses in Galera:

sql

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_incoming_addresses';
+--------------------------+-----------------------------------------------------------------------+
| Variable_name            | Value                                                                 |
+--------------------------+-----------------------------------------------------------------------+
| wsrep_incoming_addresses | 10.68.3.104:0,10.8.80.167:0,10.68.3.105:0,10.8.80.168:0,10.8.80.177:0 |
+--------------------------+-----------------------------------------------------------------------+

The important DB commands with explanation for Galera are as follows:

bash

-> Number of Nodes in cluster:
SHOW STATUS LIKE 'wsrep_cluster_size';

-> Confirms this node is ready to accept queries. OFF means it's still syncing or has an issue.
SHOW GLOBAL STATUS LIKE 'wsrep_ready';

-> Confirms the cluster component this node is part of is active and healthy. If it shows non-Primary, you may have a split-brain situation where nodes can't form a majority.
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';

-> Confirms that this specific node is connected to the cluster's communication channel. OFF means it's isolated.
SHOW STATUS LIKE 'wsrep_connected';

-> Shows the network addresses of all the other nodes in the cluster. A missing IP means a node isn't connected.
SHOW GLOBAL STATUS LIKE 'wsrep_incoming_addresses';

-> This is a unique identifier for the database state. It must be identical on all nodes in the cluster. If it's different on one node, that node is out of sync.
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid';

DB Backups

We can take the complete backup of all DBs by the use of following commands:

sql

mysqldump --single-transaction --routines --events --all-databases > /backup/mariadb_all_$(date +%F).sql

To check the size of Each of the DB:

sql

SELECT table_schema AS "Databases", ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024 , 2) AS "Size (GB)" FROM information_schema.TABLES GROUP BY table_schema;

IST or SST

IST stands for “Incremental State Transfer” and SST stands for “State Snapshot Transfer”.

IST works only if the donor node still has the needed write-sets in its gcache. If gcache does not contain the required writesets for the joining node, a full SST occurs.

To check the gcache size:

sql

mysql -e "SHOW VARIABLES LIKE 'wsrep_provider_options';" | grep -i gcache

We can make use of the bash script also through which we can find that how much time it will take. We are assuming here the “gcache=8GB”,

sql

#!/bin/bash
# Estimate Galera gcache retention window based on current traffic

MYSQL="mysql -u root -pPassword -sN"   # <-- change user/password OR use ~/.my.cnf

# Size of gcache in bytes (from wsrep_provider_options)
GCACHE_SIZE=$((8*1024*1024*1024))   # 8 GB

# Sampling interval in seconds
INTERVAL=60

echo "Measuring Galera replication rate over $INTERVAL seconds..."
echo

# Initial sample
T0=$(date +%s)
B0=$($MYSQL -e "SHOW GLOBAL STATUS LIKE 'wsrep_replicated_bytes';" | awk '{print $2}')

sleep $INTERVAL

# Second sample
T1=$(date +%s)
B1=$($MYSQL -e "SHOW GLOBAL STATUS LIKE 'wsrep_replicated_bytes';" | awk '{print $2}')

# Calculations
dt=$((T1 - T0))
db=$((B1 - B0))
bytes_per_sec=$(awk -v d=$db -v t=$dt 'BEGIN { if(t>0) printf "%.2f", d/t; else print 0 }')
ret_sec=$(awk -v g=$GCACHE_SIZE -v r=$bytes_per_sec 'BEGIN { if(r>0) printf "%.0f", g/r; else print 0 }')
ret_hours=$(awk -v s=$ret_sec 'BEGIN { printf "%.2f", s/3600 }')

# Output
echo "Interval seconds: $dt"
echo "wsrep_replicated_bytes delta: $db bytes"
echo "Average replication rate: $bytes_per_sec bytes/sec"
echo
if [ "$ret_sec" -eq 0 ]; then
    echo "Replication traffic is negligible. gcache will easily be sufficient."
else
    echo "Estimated gcache retention: $ret_sec seconds (~$ret_hours hours)"
fi

The calculated time shows the time according to which you need to plan your activity. If it is 2 hours, then you must complete your activity before the 2 hours so that the donor nodes should be able to perform the IST or SST.

When a node leaves and rejoins the cluster, Galera decides automatically whether IST (Incremental State Transfer) or SST (State Snapshot Transfer) is needed.
Which one happens depends on whether the missing data is still available in the gcache of the donor node.

How IST and SST Work

IST (Incremental State Transfer)
- Fast, minimal downtime.
- Happens if the joining node’s last committed transaction is still present in the donor’s gcache.
- Node only replays the “diff” of missing transactions.
SST (State Snapshot Transfer)
- Heavy, slower.
- Full copy of the entire dataset (from donor to joiner).
- Happens if the joiner is too far behind or has no data.
- Method depends on wsrep_sst_method (in your config it’s rsync).

To check whether IST or SST was happened on the re-joined node, you need to run the following commands:

sql

SHOW GLOBAL STATUS LIKE 'wsrep_last_received';
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';

Or check logs (/var/log/mariadb/mariadb.log):

If you see IST received: X transactions → it was IST.
If you see Starting state transfer from ... using rsync → it was SST.

MariaDB Rep

The repo file for the Debian or RedHat OS is as follows:

bash

[mariadb-main]
name = MariaDB Server
baseurl = https://dlm.mariadb.com/repo/mariadb-server/10.6/yum/rhel/8/x86_64
gpgkey = file:///etc/pki/rpm-gpg/MariaDB-Server-GPG-KEY
gpgcheck = 1
enabled = 1
module_hotfixes = 1

[mariadb-tools]
name = MariaDB Tools
baseurl = https://downloads.mariadb.com/Tools/rhel/8/x86_64
gpgkey = file:///etc/pki/rpm-gpg/MariaDB-Enterprise-GPG-KEY
gpgcheck = 1
enabled = 1

Upgrade

The upgrade can be done using the following commands:

First of all stop the service

bash

systemctl stop mariadb

Then do the installation:

bash

yum upgrade MariaDB-server MariaDB-client MariaDB-common MariaDB-shared

Then start the service:

bash

systemctl start mariadb

Then run the following command for the upgrade:

bash

mysql_upgrade -u root -p

Spotted a mistake or want something added? Send me a note.

📄MariaDB Upgrade with Galera

MariaDB Upgrade with Galera