Метод SST xtrabackup-v2

Метод xtrabackup-v2 SST использует утилиту Percona XtraBackup для выполнения SST. Это один из методов, который не блокирует узел-донор.

Обратите внимание, что если вы используете метод xtrabackup-v2 SST, вам также необходимо установить socat на сервере. Это необходимо для потоковой передачи резервной копии с узла-донора на узел-приёмник.

Поскольку Percona XtraBackup — это продукт сторонних разработчиков, он может потребовать дополнительной установки и конфигурации. Обратитесь к документации Percona по xtrabackup SST для получения информации от производителя.

Выбор Percona XtraBackup для SST

Чтобы использовать метод xtrabackup-v2 SST, необходимо установить wsrep_sst_method=xtrabackup-v2 на узле-доноре и узле-приёмнике. Его можно изменить динамически с помощью SET GLOBAL на узле, который вы намереваетесь использовать в качестве донора SST. Например:

SET GLOBAL wsrep_sst_method='xtrabackup-v2';

Его можно установить в группе параметров сервера группа параметров в файле параметров файл параметров перед запуском узла:

[mariadb]
...
wsrep_sst_method = xtrabackup-v2

Для корректной работы SST узел-донор и узел-приёмник должны использовать один и тот же метод SST. Поэтому рекомендуется установить wsrep_sst_method на все узлы в одинаковом значении, так как любой узел может быть узлом-донором или узлом-приёмником в некоторый момент.

Аутентификация и привилегии

Чтобы использовать метод xtrabackup-v2 SST, Percona XtraBackup должен иметь возможность аутентифицироваться локально на узле-доноре, чтобы создать резервную копию для потоковой передачи на узел-приёмник. Вы можете указать узлу-донору имя пользователя и пароль, установив системную переменную wsrep_sst_auth. Ее можно изменить динамически с помощью SET GLOBAL на узле, который вы намереваетесь использовать в качестве донора SST. Например:

SET GLOBAL wsrep_sst_auth = 'xtrabackup:mypassword';

Также её можно установить в группе параметров сервера группа параметров в файле параметров файл параметров перед запуском узла:

[mariadb]
...
wsrep_sst_auth = xtrabackup:mypassword

Некоторые плагины аутентификации не требуют пароля. Например, плагины аутентификации unix_socket и gssapi не требуют пароля. Если вы используете учётную запись пользователя, которая не требует пароля для входа, вы можете оставить компонент пароля в wsrep_sst_auth пустым. Например:

[mariadb]
...
wsrep_sst_auth = xtrabackup:

Учётная запись пользователя, выполняющая резервное копирование для SST, должна иметь те же привилегии, что и Percona XtraBackup, которые являются RELOAD , PROCESS, LOCK TABLES и REPLICATION CLIENT глобальными привилегиями. Для большей безопасности следует убедиться, что эти привилегии установлены на каждом узле вашего кластера. Percona XtraBackup подключается локально на узле-доноре для выполнения резервного копирования, поэтому следующий пользователь будет достаточным:

CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'mypassword';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Беспарольная аутентификация - Unix-сокет

Можно использовать плагин аутентификации unix_socket для учётной записи пользователя, выполняющего SST. Это даёт преимущество — не нужно настраивать текстовый пароль в wsrep_sst_auth.

Учётная запись пользователя должна иметь то же имя, что и учётная запись пользователя операционной системы, которая запускает процесс mysqld. На многих системах это учётная запись пользователя, настроенная как параметр user, и по умолчанию она обычно равна mysql.

Например, если плагин аутентификации unix_socket уже установлен, вы можете выполнить следующее, чтобы создать учётную запись пользователя:

CREATE USER 'mysql'@'localhost' IDENTIFIED VIA unix_socket;
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mysql'@'localhost';

А затем, чтобы настроить wsrep_sst_auth, вы можете установить следующее в группе параметров сервера группа параметров в файле параметров файл параметров перед запуском узла:

[mariadb]
...
wsrep_sst_auth = mysql:

Беспарольная аутентификация - GSSAPI

Можно использовать плагин аутентификации gssapi для учётной записи пользователя, выполняющего SST. Это даёт преимущество — не нужно настраивать текстовый пароль в wsrep_sst_auth.

Следующие шаги необходимо выполнить предварительно:

• Вам нужен KDC, работающий под MIT Kerberos или Microsoft Active Directory.
• Вам потребуется создать файл keytab для сервера MariaDB.
• Вам потребуется установить пакет, содержащий плагин аутентификации gssapi.
• Вам потребуется установить плагин в MariaDB, чтобы плагин аутентификации gssapi был доступен для использования.
• Вам потребуется настроить плагин.
• Вам потребуется создать учётную запись пользователя, которая аутентифицируется с помощью плагина аутентификации gssapi, чтобы учётная запись пользователя могла использоваться для SST. Эта учётная запись должна соответствовать учётной записи пользователя, которая существует в KDC.

Например, вы можете выполнить следующее, чтобы создать учётную запись пользователя в MariaDB:

CREATE USER 'xtrabackup'@'localhost' IDENTIFIED VIA gssapi;
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

А затем, чтобы настроить wsrep_sst_auth, вы можете установить следующее в группе параметров сервера группа параметров в файле параметров файл параметров перед запуском узла:

[mariadb]
...
wsrep_sst_auth = xtrabackup:

Выбор узла-донора

При использовании Percona XtraBackup для создания резервной копии SST на узле-доноре, XtraBackup на короткое время требует системной блокировки в конце резервного копирования. Это выполняется с помощью FLUSH TABLES WITH READ LOCK.

Если определённый узел в вашем кластере работает как главный узел, получая весь трафик записей приложения, то этот узел обычно не следует использовать в качестве узла-донора, поскольку системная блокировка может помешать приложению. В этом случае вы можете определить один или несколько предпочтительных узлов-доноров, установив системную переменную wsrep_sst_donor.

Например, предположим, что у нас есть кластер из 5 узлов с узлами node1, node2, node3, node4, и node5, и предположим, что node1 является главным узлом. Предпочтительные узлы-доноры для node2 можно настроить, установив следующее в группе параметров сервера группа параметров в файле параметров файл параметров перед запуском узла:

[mariadb]
...
wsrep_sst_donor=node3,node4,node5,

Кома в конце указывает серверу разрешить любой другой узел как донор, когда предпочтительные доноры недоступны. Таким образом, если node1 является единственным оставшимся узлом в кластере, запятая позволяет использовать его в качестве узла-донора.

Зависимость от Socat

В процессе SST узел-донор использует socat для потоковой передачи резервной копии на узел-приёмник. Затем узел-приёмник подготавливает резервную копию перед её восстановлением. Утилита socat должна быть установлена на узле-доноре и на узле-приёмнике, для того чтобы это работало. В противном случае журнал ошибок MariaDB будет содержать ошибку, подобную:

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)

Установка Socat на RHEL/CentOS

На RHEL/CentOS, socat может быть установлен из репозитория Extra Packages for Enterprise Linux (EPEL).

TLS

Этот метод SST поддерживает три различных метода TLS. Конкретный метод может быть выбран путём установки опции encrypt в разделе [sst] файла конфигурации MariaDB. Варианты:

• TLS с использованием шифрования OpenSSL, встроенного в socat (encrypt=2)
• TLS с использованием шифрования OpenSSL с сертификатами и ключами, совместимыми с Galera (encrypt=3)
• TLS с использованием шифрования OpenSSL с сертификатами и ключами, совместимыми с MariaDB (encrypt=4)

Обратите внимание, что encrypt=1 относится к методу шифрования TLS, который устарел и удалён.

TLS с использованием шифрования OpenSSL, встроенного в Socat

Для генерации ключей, совместимых с этим методом шифрования, вы можете следовать этим инструкциям.

Например:

• Сначала сгенерируйте ключи и сертификаты:

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

• На некоторых системах вам также может потребоваться добавить dhparams к сертификату:

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

Но замените пути на соответствующие вашему системному окружению.

Это должно обеспечить шифрование ваших SST.

Шифрование TLS с использованием OpenSSL, сертификатов и ключей, совместимых с Galera

Для генерации ключей, совместимых с этим методом шифрования, вы можете следовать этим инструкциям.

Например:

• Сначала сгенерируйте ключи и сертификаты:

# 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

Но замените пути на соответствующие вашему системному окружению.

Это должно обеспечить шифрование ваших SST.

Шифрование TLS с использованием OpenSSL, сертификатов и ключей, совместимых с MariaDB

Для генерации ключей, совместимых с этим методом шифрования, вы можете следовать этим инструкциям.

Например:

• Сначала сгенерируйте ключи и сертификаты:

# 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

Но замените пути на соответствующие вашему системному окружению.

Это должно обеспечить шифрование ваших SST.

Логи

Метод xtrabackup-v2 SST имеет собственные логи, отдельные от логирования сервера MariaDB.

Логирование в SST логи

По умолчанию на узле-доноре логирование происходит в innobackup.backup.log. Этот файл логов расположен в datadir.

По умолчанию на узле-присоединителе логирование происходит в innobackup.prepare.log и innobackup.move.log. Эти файлы логов находятся в каталоге .sst, который является скрытым каталогом внутри datadir.

Эти файлы логов перезаписываются каждым последующим SST, поэтому, если SST завершается неудачно, лучше всего скопировать их в безопасное место перед запуском следующего SST, чтобы можно было проанализировать файлы логов. См. MDEV-17973 по этому поводу.

Логирование в Syslog

Вы можете перенаправить SST логи в syslog, установив следующее в группе опций [sst] группы опций в файле опций файле опций:

[sst]
sst-syslog=1

Вы также можете перенаправить SST логи в syslog, установив следующее в группе опций [mysqld_safe] группы опций в файле опций файле опций:

[mysqld_safe]
syslog

Выполнение SST с адресами IPv6

Если вы выполняете Percona XtraBackup SST с адресами IPv6, то утилите socat необходимо передать опцию pf=ip6. Это можно сделать, установив опцию sockopt в группе опций [sst] группы опций в файле опций файле опций. Например:

[sst]
sockopt=",pf=ip6"

Дополнительную информацию см. в MDEV-18797.

Ручная SST с Percona XtraBackup

В некоторых случаях, если автоматические SST Galera Cluster постоянно завершаются неудачно, может быть полезно выполнить «ручную SST». Смотрите следующую страницу, чтобы узнать, как это сделать:

• Ручная SST узла Galera Cluster с Percona XtraBackup

См. также

• Настройка SST Percona XtraBackup
• Шифрование трафика PXC: ШИФРОВАНИЕ ТРАФИКА SST
• Параметры XTRABACKUP
• SSL ДЛЯ ПЕРЕДАЧИ СНАПШОТОВ СОСТОЯНИЯ: ВКЛЮЧЕНИЕ SSL ДЛЯ XTRABACKUP