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.
The xtrabackup-v2 SST method uses the Percona XtraBackup utility for performing SSTs. It is one of the methods that does not block the donor node.
Note that if you use the xtrabackup-v2 SST method, then you also need to have socat installed on the server. This is needed to stream the backup from the donor node to the joiner node.
Since Percona XtraBackup is a third party product, it may require additional installation and additional configuration. Please refer to Percona's xtrabackup SST documentation for information from the vendor.
To use the xtrabackup-v2 SST method, you must set the wsrep_sst_method=xtrabackup-v2 on both the donor and joiner node. It can be changed dynamically with SET GLOBAL on the node that you intend to be a SST donor. For example:
SET GLOBAL wsrep_sst_method='xtrabackup-v2';
It can be set in a server option group in an option file prior to starting up a node:
[mariadb] ... wsrep_sst_method = xtrabackup-v2
To use 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 donor node what username and password to use by setting the wsrep_sst_auth system variable. It can be changed dynamically with SET GLOBAL on the node that you intend to be a SST donor. For example:
SET GLOBAL wsrep_sst_auth = 'xtrabackup:mypassword';
It can also be set in a server option group in an option file prior to starting up a node:
[mariadb] ... wsrep_sst_auth = xtrabackup:mypassword
Some authentication plugins do not require a password. For example, the unix_socket and gssapi authentication plugins do not require a password. If you are using a user account that does not require a password in order to log in, then you can just leave the password component of wsrep_sst_auth empty. For example:
[mariadb] ... wsrep_sst_auth = xtrabackup:
The user account that performs the backup for the SST needs to have the same privileges as Percona XtraBackup, which are the RELOAD , PROCESS, LOCK TABLES and REPLICATION CLIENT global 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:
CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'mypassword'; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';
It is possible to use the unix_socket authentication plugin for the user account that performs SSTs. This would provide the benefit of not needing to configure a plain-text password in wsrep_sst_auth.
The user account would have to have the same name as the operating system user account that is running the mysqld process. On many systems, this is the user account configured as the user option, and it tends to default to mysql.
For example, if the unix_socket authentication plugin is already installed, then you could execute the following to create the user account:
CREATE USER 'mysql'@'localhost' IDENTIFIED VIA unix_socket; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mysql'@'localhost';
And then to configure wsrep_sst_auth, you could set the following in a server option group in an option file prior to starting up a node:
[mariadb] ... wsrep_sst_auth = mysql:
It is possible to use the gssapi authentication plugin for the user account that performs SSTs. This would provide the benefit of not needing to configure a plain-text password in wsrep_sst_auth.
The following steps would need to be done beforehand:
gssapi authentication plugin. gssapi authentication plugin is available to use. gssapi authentication plugin, so that the user account can be used for SSTs. This user account will need to correspond with a user account that exists on the backend KDC. For example, you could execute the following to create the user account in MariaDB:
CREATE USER 'xtrabackup'@'localhost' IDENTIFIED VIA gssapi; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';
And then to configure wsrep_sst_auth, you could set the following in a server option group in an option file prior to starting up a node:
[mariadb] ... wsrep_sst_auth = xtrabackup:
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 node and the joiner node 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)
On RHEL/CentOS, socat can be installed from the Extra Packages for Enterprise Linux (EPEL) repository.
This SST method supports three different TLS methods. The specific method can be selected by setting the encrypt option in the [sst] section of the MariaDB configuration file. The options are:
socat (encrypt=2) encrypt=3) encrypt=4) Note that encrypt=1 refers to a TLS encryption method that has been deprecated and removed.
To generate keys compatible with this encryption method, you can follow these directions.
For example:
FILENAME=sst openssl genrsa -out $FILENAME.key 1024 openssl req -new -key $FILENAME.key -x509 -days 3653 -out $FILENAME.crt cat $FILENAME.key $FILENAME.crt >$FILENAME.pem chmod 600 $FILENAME.key $FILENAME.pem
openssl dhparam -out dhparams.pem 2048 cat dhparams.pem >> sst.pem
[sst] encrypt=2 tca=/etc/my.cnf.d/certificates/sst.crt tcert=/etc/my.cnf.d/certificates/sst.pem
But replace the paths with whatever is relevant on your system.
This should allow your SSTs to be encrypted.
To generate keys compatible with this encryption method, you can follow these directions.
For example:
# CA openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 \ -key ca-key.pem -out ca-cert.pem # server1 openssl req -newkey rsa:2048 -days 365000 \ -nodes -keyout server1-key.pem -out server1-req.pem openssl rsa -in server1-key.pem -out server1-key.pem openssl x509 -req -in server1-req.pem -days 365000 \ -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 \ -out server1-cert.pem
[sst] encrypt=3 tkey=/etc/my.cnf.d/certificates/server1-key.pem tcert=/etc/my.cnf.d/certificates/server1-cert.pem
But replace the paths with whatever is relevant on your system.
This should allow your SSTs to be encrypted.
To generate keys compatible with this encryption method, you can follow these directions.
For example:
# CA openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 \ -key ca-key.pem -out ca-cert.pem # server1 openssl req -newkey rsa:2048 -days 365000 \ -nodes -keyout server1-key.pem -out server1-req.pem openssl rsa -in server1-key.pem -out server1-key.pem openssl x509 -req -in server1-req.pem -days 365000 \ -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 \ -out server1-cert.pem
[sst] encrypt=4 ssl-ca=/etc/my.cnf.d/certificates/ca-cert.pem ssl-cert=/etc/my.cnf.d/certificates/server1-cert.pem ssl-key=/etc/my.cnf.d/certificates/server1-key.pem
But replace the paths with whatever is relevant on your system.
This should allow your SSTs to be encrypted.
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 the [sst] option group in an option file:
[sst] sst-syslog=1
If you are performing Percona XtraBackup SSTs with IPv6 addresses, then the socat utility needs to be passed the pf=ip6 option. This can be done by setting the sockopt option in the [sst] option group in an option file. For example:
[sst] sockopt=",pf=ip6"
See MDEV-18797 for more information.
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:
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/xtrabackup-v2-sst-method/