xtrabackup-v2 SST method
Contents
The xtrabackup-v2
SST method uses the Percona XtraBackup utility for performing SSTs. It is one of the two non-locking methods. Note that if you use the xtrabackup-v2
SST method, you also need to have socat installed on the server. However, since it is a third party product, it requires an additional installation some additional configuration. Please refer to Percona's xtrabackup SST documentation for information from the vendor.
In MariaDB 10.1 and later, Mariabackup is the recommended backup method to use instead of Percona XtraBackup.
In MariaDB 10.3, Percona XtraBackup is not supported. See Percona XtraBackup Overview: Compatibility with MariaDB for more information.
In MariaDB 10.2 and MariaDB 10.1, Percona XtraBackup is only partially supported. See Percona XtraBackup Overview: Compatibility with MariaDB for more information.
Choosing Percona XtraBackup for SSTs
To use the xtrabackup-v2
SST method, you must set the wsrep_sst_method=xtrabackup-v2
on both the donor and joiner node. For example:
[mysqld] ... wsrep_sst_method = xtrabackup-v2
Authentication and Privileges
In order for the xtrabackup-v2
SST method, Percona XtraBackup needs to be able to authenticate locally on the donor node, so that it can create a backup to stream to the joiner. You can tell the client what username and password to use by setting the wsrep_sst_auth
system variable. For example:
[mysqld] ... wsrep_sst_method = xtrabackup wsrep_sst_auth = user:password
This user need to have the RELOAD
, PROCESS
, LOCK TABLES
and REPLICATION CLIENT
privileges. To be safe, you should ensure that these privileges are set on each node in your cluster. Percona XtraBackup connects locally on the donor node to perform the backup, so the following user should be sufficient:
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';
Socat Dependency
During the SST process, the donor node uses socat to stream the backup to the joiner node. Then the joiner node prepares the backup before restoring it. The socat utility must be installed on both the donor and the joiner in order for this to work. Otherwise, the MariaDB error log will contain an error like:
WSREP_SST: [ERROR] socat not found in path: /usr/sbin:/sbin:/usr//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin (20180122 14:55:32.993)
TLS
To secure the SST transfer using TLS, see
Logs
The xtrabackup-v2
SST method has its own logging outside of the MariaDB Server logging.
By default, on the donor node, it logs to innobackup.backup.log
. This log file is located in the datadir
.
By default, on the joiner node, it logs to innobackup.prepare.log
and innobackup.move.log
. These log files are located in the .sst
directory, which is a hidden directory inside the datadir
.
These log files are overwritten by each subsequent SST, so if an SST fails, it is best to copy them somewhere safe before starting another SST, so that the log files can be analyzed. See MDEV-17973 about that.
You can redirect the SST logs to the syslog instead by setting the following in your MariaDB configuration file:
[sst] sst-syslog=1
Manual SST with Percona XtraBackup
In some cases, if Galera Cluster's automatic SSTs repeatedly fail, then it can be helpful to perform a "manual SST". See the following page on how to do that: