xtrabackup-v2 SST method

You are viewing an old version of this article. View the current version here.

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:

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.