For the complete documentation index, see llms.txt. This page is also available as Markdown.

Manual SST of Galera Cluster Node With mariadb-backup

Perform a manual node provision. This guide details the steps to manually backup a donor and restore it to a joiner node in a Galera Cluster.

Sometimes it can be helpful to perform a "manual SST" when Galera's normal SSTs fail. This can be especially useful when the cluster's datadir is very large, since a normal SST can take a long time, keeping the donor in a not fully synced state for the duration of the transfer.

A manual SST essentially consists of taking a backup of the donor, loading the backup on the joiner, and then manually editing the cluster state on the joiner node. This page will show how to perform this process with mariadb-backup.

Process

1

Check the nodes

Ensure you understand the version compatibility between your nodes. For a standard manual SST, the donor and joiner should run the same mariadb-backup version.

For major version upgrades (e.g., 10.6 to 11.4)

The versions will differ. In this scenario, you must use Method B in the next step because a newer mariadb-backup binary cannot prepare a raw backup generated by an older major version.

mariadb-backup --version
2

Prepare and Transfer the Backup (Choose ONE Method)

Select the strategy below that best matches your environment's resource constraints and upgrade requirements.

Method A: Prepare on the Joiner Node (Standard / Resource-Saving)

Use this if both nodes are on the same major MariaDB version. This offloads RAM and CPU overhead from the active donor to the joiner.

  1. On the donor node, create the backup directory and take the backup:

BACKUP_DIR=/mariadb_backup
mkdir -p $BACKUP_DIR

DB_USER=sstuser
DB_USER_PASS=password
mariadb-backup --backup --galera-info \
   --target-dir=$BACKUP_DIR \
   --user=$DB_USER \
   --password=$DB_USER_PASS
  1. On the joiner node, stop MariaDB, create the backup directory:

systemctl stop mariadb

BACKUP_DIR=/mariadb_backup
mkdir -p $BACKUP_DIR
  1. From the donor node, transfer the contents of the backup directory to the joiner node. You may use rsync, scp, or your preferred file transfer method.

  2. On the joiner node, prepare the backup:

mariadb-backup --prepare --target-dir=$BACKUP_DIR

Method B: Prepare on the Donor Node (Required for Major Upgrades)

Use this for cross-version upgrades (e.g., 10.6 to 11.4). The donor's native binary must apply the redo logs before transit, ensuring compatibility.

1. On the donor node, create the directory, take the backup, and prepare it:

BACKUP_DIR=/mariadb_backup
mkdir -p $BACKUP_DIR

DB_USER=sstuser
DB_USER_PASS=password
mariadb-backup --backup --galera-info \
   --target-dir=$BACKUP_DIR \
   --user=$DB_USER \
   --password=$DB_USER_PASS

mariadb-backup --prepare --target-dir=$BACKUP_DIR

2. On the joiner node, make sure MariaDB is stopped, create the directory:

systemctl stop mariadb

BACKUP_DIR=/mariadb_backup
mkdir -p $BACKUP_DIR
  1. From the donor node, transfer the contents of the backup directory to the joiner node. You may use rsync, scp, or your preferred file transfer method.

Method C: Streaming Backup (Zero Donor Disk Overhead)

Use this to avoid using local staging disk space on the donor node, especially when the cluster's datadir is very large. A standard manual backup requires enough free disk space on the donor node to hold a complete secondary copy of the data. Streaming avoids this local disk overhead entirely by piping the data directly over SSH

Prerequisites for Streaming:

The streaming command on the donor must be executed by root or a user in the mysql group to be able to read the data directory.

The OS_USER on the joiner node must have the executing user's public SSH key added to their $HOME/.ssh/authorized_keys file to allow the stream to pipe without a password prompt.

  1. On the joiner node, make sure MariaDB is stopped and create the target directory:

systemctl stop mariadb

BACKUP_DIR=/mariadb_backup
mkdir -p $BACKUP_DIR

2. On the donor node, stream the backup directly to the joiner:

DB_USER=sstuser
DB_USER_PASS=password
OS_USER=dba
JOINER_HOST=dbserver2.mariadb.com
BACKUP_DIR=/mariadb_backup

mariadb-backup --backup --galera-info --stream=mbstream \
   --user=$DB_USER --password=$DB_USER_PASS | \
   ssh ${OS_USER}@${JOINER_HOST} "mbstream -x -C $BACKUP_DIR"

3. On the joiner node, prepare the backup:

mariadb-backup --prepare --target-dir=$BACKUP_DIR
3

Get the ID

Get the Galera Cluster version ID from the donor node's grastate.dat file.

DATADIR=/var/lib/mysql
cat $DATADIR/grastate.dat | grep version

For example, a very common version number is "2.1".

1

Get the node's cluster state

Get the state from the Galera info file in the backup that was copied to the joiner node.

The name of this file depends on the MariaDB version:

  • MariaDB 11.4 and later: mariadb_backup_galera_info

  • MariaDB 11.3 and earlier: xtrabackup_galera_info

For MariaDB 11.4 and later:

cat $BACKUP_DIR/mariadb_backup_galera_info

For MariaDB 11.3 and earlier:

cat $BACKUP_DIR/xtrabackup_galera_info

The file contains the values of the wsrep_local_state_uuid and wsrep_last_committed status variables. The values are written in the following format:

wsrep_local_state_uuid:wsrep_last_committed

For example:

d38587ce-246c-11e5-bcce-6bbd0831cc0f:1352215
2

Create a grastate.dat file

Create the file in the backup directory of the joiner node. The Galera Cluster version ID, the cluster uuid, and the seqno from previous steps will be used to fill in the relevant fields.

For example, with the example values from the last two steps, we could do:

sudo tee $BACKUP_DIR/grastate.dat <<EOF
# GALERA saved state
version: 2.1
uuid:    d38587ce-246c-11e5-bcce-6bbd0831cc0f
seqno:   1352215
safe_to_bootstrap: 0
EOF
3

Remove contents

Remove the existing contents of the datadir on the joiner node.

DATADIR=/var/lib/mysql
rm -Rf $DATADIR/*
4

Copy contents

Copy the contents of the backup directory to the datadir the on joiner node.

mariadb-backup --copy-back \
   --target-dir=$BACKUP_DIR
5

Check datadir permissions

Make sure the permissions of the datadir are correct on the joiner node.

chown -R mysql:mysql $DATADIR/
6

Start the MariaDB Server process on the joiner node.

This will depend on your service manager. For example, on systemd systems, you may execute::

systemctl start mariadb
7

Watch the MariaDB error log

On the joiner node, verify that the node does not need to perform a normal SSTs due to the manual SST.

tail -f /var/log/mysql/mysqld.log

Last updated

Was this helpful?