Введение в передачу моментальных снимков состояния (SST)

При передаче моментального снимка состояния кластера (SST), кластер выделяет узлы, передавая полную копию данных с одного узла на другой. Когда новый узел присоединяется к кластеру, новый узел инициирует передачу моментального снимка состояния, чтобы синхронизировать свои данные с узлом, который уже является частью кластера.

Типы SST

Существует два концептуально различных способа передачи состояния с одного сервера MariaDB на другой:

1. Логический

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

2. Физический

Методы SST этого типа физически копируют файлы данных с узла-донора на узел-присоединитель. Это требует, чтобы узел-присоединитель был инициализирован после передачи. Метод mariabackup SST и некоторые другие методы SST относятся к этой категории. Эти методы SST намного быстрее, чем метод mysqldump SST, но у них есть определенные ограничения. Например, они могут использоваться только при запуске сервера, и узел-присоединитель должен быть настроен очень похоже на узел-донора (например, innodb_file_per_table должен быть таким же и так далее). Некоторые методы SST в этой категории неблокируют узел-донора, что означает, что узел-донор по-прежнему может обрабатывать запросы во время передачи SST (например, метод mariabackup SST неблокирующий).

Методы SST

Методы SST поддерживаются через скриптовый интерфейс. Новые методы SST потенциально могут быть разработаны путем создания новых скриптов SST. Скрипты обычно имеют имена в формате wsrep_sst_<method> , где <method> — один из методов SST, перечисленных ниже.

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

SET GLOBAL wsrep_sst_method='mariabackup';

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

[mariadb]
...
wsrep_sst_method = mariabackup

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

MariaDB Galera Cluster поставляется со следующими встроенными методами SST:

mariabackup

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

Этот метод SST поддерживает GTID.

Этот метод SST поддерживает Шифрование данных при хранении.

Этот метод SST доступен начиная с MariaDB 10.1.26 и MariaDB 10.2.10.

С этим методом SST невозможно выполнить обновление кластера между некоторыми основными версиями; см. MDEV-27437.

См. метод mariabackup SST для получения дополнительной информации.

rsync / rsync_wan

rsync является методом по умолчанию. Этот метод использует утилиту rsync для создания моментального снимка узла-донора. rsync должна быть доступна по умолчанию во всех современных дистрибутивах Linux. Узел-донор блокируется с блокировкой чтения во время SST. Это самый быстрый метод SST, особенно для больших наборов данных, так как он копирует двоичные данные. Поэтому это рекомендуемый метод SST, если вам не нужно разрешать узлу-донору выполнять запросы во время SST.

Метод rsync выполняет rsync в режиме --whole-file, предполагая, что узлы соединены быстрыми локальными сетевыми каналами, так что режим передачи по умолчанию может потреблять больше времени обработки, чем сэкономить на пропускной способности передачи данных. При наличии распределенного кластера со слабыми каналами связи между узлами метод rsync_wan выполняет rsync в стандартном режиме передачи различий, что может значительно сократить время передачи данных, когда состояние более старого каталога данных уже присутствует на узле-присоединителе. Оба метода фактически реализуются одним и тем же скриптом, wsrep_sst_rsync_wan — это просто символическая ссылка на скрипт wsrep_sst_rsync, и фактический режим rsync определяется именем, по которому был вызван скрипт.

Этот метод SST поддерживает GTID.

Этот метод SST поддерживает Шифрование данных при хранении.

Метод rsync SST не поддерживает таблицы, созданные с клаузой DATA DIRECTORY или INDEX DIRECTORY. Используйте метод SST mariabackup в качестве альтернативы для поддержки этой функции.

Использование этого метода SST может привести к повреждению данных при использовании innodb_use_native_aio (значение по умолчанию), если донор старше MariaDB 10.3.35, MariaDB 10.4.25, MariaDB 10.5.16, MariaDB 10.6.8 или MariaDB 10.7.4; см. MDEV-25975. Начиная с этих версий донора, wsrep_sst_method=rsync является надёжным способом обновления кластера до более новой основной версии.

Начиная с MariaDB 10.1.36, MariaDB 10.2.18 и MariaDB 10.3.10, stunnel может использоваться для шифрования данных по сети. Убедитесь, что stunnel установлен. Вам также необходимо сгенерировать сертификаты и ключи. См. документацию stunnel для получения информации о том, как это сделать. После получения ключей вам потребуется добавить опции tkey и tcert в группу опций [sst] в вашем файле конфигурации MariaDB, например:

[sst]
tkey = /etc/my.cnf.d/certificates/client-key.pem
tcert = /etc/my.cnf.d/certificates/client-cert.pem

Вам также нужно запустить директорию сертификатов через openssl rehash.

mysqldump

Этот метод SST выполняет mysqldump на узле-доноре и передает вывод в клиент mariadb, подключённый к узлу-присоединителю. Методу mysqldump SST требуется пара имя пользователя/пароль, установленная в переменной wsrep_sst_auth, чтобы получить дамп. Узел-донор блокируется с блокировкой чтения во время SST. Это самый медленный метод SST.

Этот метод SST поддерживает GTID.

Этот метод SST поддерживает Шифрование данных при хранении.

xtrabackup-v2

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

Этот метод SST не поддерживает GTID.

Этот метод SST не поддерживает Шифрование данных при хранении.

Этот метод SST доступен с MariaDB Galera Cluster 5.5.37 и MariaDB Galera Cluster 10.0.10.

См. метод xtrabackup-v2 SST для получения дополнительной информации.

xtrabackup

Этот метод SST является более старым методом SST, использующим утилиту Percona XtraBackup для выполнения SST. Метод xtrabackup-v2 следует использовать вместо метода xtrabackup SST, начиная с MariaDB 5.5.33.

Этот метод SST не поддерживает GTID.

Этот метод SST не поддерживает Шифрование данных в состоянии покоя.

Аутентификация

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

SET GLOBAL wsrep_sst_auth = 'mariabackup:password';

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

[mariadb]
...
wsrep_sst_auth = mariabackup:password

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

[mariadb]
...
wsrep_sst_auth = mariabackup:

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

SST и Systemd

Файл службы systemd MariaDB имеет стандартный таймаут запуска около 90 секунд на большинстве систем. Если SST занимает больше времени, чем этот стандартный таймаут запуска на узле-присоединителе, то systemd предположит, что mysqld не удалось запустить, что приводит к тому, что systemd убивает процесс mysqld на узле-присоединителе. Чтобы обойти эту проблему, вы можете перенастроить службу MariaDB systemd на бесконечный таймаут, выполнив одну из следующих команд:

Если вы используете systemd 228 или более раннюю версию, то можете выполнить следующее, чтобы установить бесконечный таймаут:

sudo tee /etc/systemd/system/mariadb.service.d/timeoutstartsec.conf <<EOF
[Service]

TimeoutStartSec=0
EOF
sudo systemctl daemon-reload

Systemd 229 добавил опцию бесконечности, поэтому если вы используете systemd 229 или более позднюю версию, то можете выполнить следующее, чтобы установить бесконечный таймаут:

sudo tee /etc/systemd/system/mariadb.service.d/timeoutstartsec.conf <<EOF
[Service]

TimeoutStartSec=infinity
EOF
sudo systemctl daemon-reload

См. Настройка таймаута службы Systemd для получения более подробной информации.

Обратите внимание, что systemd 236 добавил переменную среды EXTEND_TIMEOUT_USEC, которая позволяет службам продлевать таймаут запуска во время длительных процессов. Начиная с MariaDB 10.1.35, MariaDB 10.2.17 и MariaDB 10.3.8, на системах с версиями systemd, которые поддерживают эту функцию, MariaDB использует ее для продления таймаута запуска во время длительных SST. Поэтому, если вы используете systemd 236 или более позднюю версию, вам не нужно будет вручную переопределять TimeoutStartSec, даже если ваши SST выполняются дольше, чем заданное значение. См. MDEV-15607 для получения дополнительной информации.

Ошибка SST

Ошибка SST обычно делает узел-присоединение непригодным для использования. Поэтому при обнаружении ошибки SST узел-присоединение будет прерван.

Перезапуск узла после ошибки SST mysqldump может потребовать ручного восстановления административных таблиц.

SST и Шифрование данных в состоянии покоя

Обратитесь к описанию каждого метода SST, чтобы определить, какие методы поддерживают Шифрование данных в состоянии покоя.

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

Минимальный размер кластера

Для избежания ситуации «разделенного мозга» рекомендуется минимальное количество узлов в кластере — 3.

При использовании метода SST, который блокирует донора, есть еще одна причина требовать минимум 3 узла. В кластере из 3 узлов, если один узел выступает в роли узла-присоединения SST, а другой — в роли узла-донора SST, то еще один узел будет продолжать выполнять запросы.

Ручные SST

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

• Ручной SST узла Galera Cluster с Mariabackup
• Ручной SST узла Galera Cluster с Percona XtraBackup

Известные проблемы

mysqld_multi

Сценарии SST в настоящее время не могут читать [mysqldN] группы параметров в файлах файлов параметров, которые считываются экземплярами, управляемыми mysqld_multi.

См. MDEV-18863 для получения дополнительной информации.

См. также

• Документация Galera Cluster: STATE SNAPSHOT TRANSFERS