Метод SST mariabackup

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

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

Выбор Mariabackup для SST

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

SET GLOBAL wsrep_sst_method='mariabackup';

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

[mariadb]
...
wsrep_sst_method = mariabackup

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

Обновления основных версий

Формат журнала предварительной записи InnoDB был изменен в MariaDB 10.5 и MariaDB 10.8 таким образом, что не позволит восстановление после сбоя или подготовку резервной копии из более старой основной версии. Из-за этого метод SST mariabackup не может быть использован для некоторых обновлений основных версий, если вы временно не измените скрипт wsrep_sst_mariabackup, чтобы шаг --prepare на узле с новой основной версией выполнялся с использованием инструмента mariabackup старой основной версии.

Метод по умолчанию wsrep_sst_method=rsync будет работать для обновлений основных версий; см. MDEV-27437.

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

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

SET GLOBAL wsrep_sst_auth = 'mariabackup:mypassword';

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

[mariadb]
...
wsrep_sst_auth = mariabackup:mypassword

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

[mariadb]
...
wsrep_sst_auth = mariabackup:

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

CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY 'mypassword';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mariabackup'@'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 'mariabackup'@'localhost' IDENTIFIED VIA gssapi;
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mariabackup'@'localhost';

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

[mariadb]
...
wsrep_sst_auth = mariabackup:

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

Когда Mariabackup используется для создания резервной копии для SST на узле-доноре, Mariabackup на короткое время требует системной блокировки в конце резервного копирования. В MariaDB 10.3 и ранее это делается с помощью FLUSH TABLES WITH READ LOCK. В MariaDB 10.4 и более поздних версиях это делается с помощью BACKUP STAGE BLOCK_COMMIT.

Если определенный узел в вашем кластере выступает в роли главного узла, получая весь трафик записи приложения, то этот узел обычно не следует использовать в качестве узла-донора, потому что системная блокировка может помешать работе приложения. В этом случае вы можете определить один или несколько предпочтительных узлов-доноров, установив системную переменную 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)

Обратите внимание, что encrypt=1 относится к методу шифрования TLS, который устарел и удалён. encrypt=4 относится к методу шифрования TLS в xtrabackup-v2 , который ещё не был перенесён в mariabackup. См. MDEV-18050 по этому поводу.

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.

Логи

Метод mariabackup SST имеет собственное ведение журнала вне журнала регистрации MariaDB Server.

Ведение журнала в журналы SST

[sst]
sst-log-archive=1
sst-log-archive-dir=/var/log/mysql/sst/

Ведение журнала в Syslog

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

[sst]
sst-syslog=1

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

[mysqld_safe]
syslog

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

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

[sst]
sockopt=",pf=ip6"

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

Ручная SST с Mariabackup

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

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

См. также

• Конфигурация Percona XtraBackup SST
• Шифрование трафика PXC: ШИФРОВАНИЕ ТРАФИКА SST
• ПАРАМЕТРЫ XTRABACKUP
• SSL ДЛЯ ПЕРЕДАЧИ МГНОВЕННЫХ СНИМКОВ СОСТОЯНИЯ: ВКЛЮЧЕНИЕ SSL ДЛЯ XTRABACKUP