Конфигурация репликации Master-Slave для MariaDB с использованием Galera Cluster на Ubuntu

В предыдущих обсуждениях мы рассмотрели процесс настройки кластера Galera MariaDB на Ubuntu и способы шифрования трафика репликации внутри этого кластера. В данном руководстве мы освоим добавление асинхронного репликационного слейва в кластер Galera, что позволит кластеру функционировать как мастер.

Мастеровая роль в Galera Cluster

Учтите, что репликация не заменяет резервное копирование. Несмотря на наличие нескольких узлов в кластере Galera, каждый из которых хранит копию вашей базы данных, если на одном из узлов будет выполнена команда DROP DATABASE, все остальные узлы также потеряют доступ к этой базе. Мы планируем настроить репликацию в режиме master-slave, где кластер Galera будет выполнять роль мастера. Для этого потребуется отдельный сервер в роли слейва. После настройки вы сможете производить резервные копии на слейве с помощью mysqldump, не прерывая рабочую нагрузку в кластере Galera во время создания резервной копии.

Кластер Galera реализует синхронную репликацию между узлами, в то время как в классической схеме репликации master-slave MariaDB применяется асинхронный метод между мастером и слейвом.

Процесс настройки репликации мастер-слейв с использованием кластера Galera можно разбить на пять этапов:

1. Конфигурация двоичного лога и репликации на главном сервере Galera.
2. Активация релейного журнала и репликации на слейве.
3. Формирование дампа баз данных на главном узле Galera и его последующее импортирование на резервный узел.
4. (по желанию) Активирование шифрования TLS
5. Соединение слея с мастером Galera.

Основные шаги схожи с конфигурацией обычной репликации мастер-слейв, однако необходимо будет отрегулировать некоторые настройки для мастера Galera.

Начальные условия

Необходимо, чтобы кластер Galera был настроен минимум на трех узлах, и вам следует подготовить отдельный сервер для роли слея.

Оптимально, чтобы мастер Galera и слей работали на идентичных версиях MariaDB. Репликация между разными версиями может привести к осложнениям. Если вы работаете с сервером базы данных MariaDB на Ubuntu, рекомендуется установить MariaDB из репозитория Ubuntu на всех серверах или обновить до последней версии из репозитория MariaDB. org на всех узлах.

Выполнив указанные ниже шаги, вы сможете настроить конфигурации мастера на каждом узле в кластере Galera, что позволит вам быстро установить слей для репликации с другого узла в случае его отключения.

Конфигурация двоичного журнала и репликации на главном сервере Galera.

Репликация по схеме мастер-слейв зависит от двоичного журнала. Для корректной работы репликации необходимо активировать двоичное логирование на мастере. В узлах Galera двоичное логирование уже включено в строковом формате, так как Galera поддерживает только его. Также требуется внести изменения в несколько других параметров, поэтому откройте основной конфигурационный файл MariaDB.

sudo nano /etc/mysql/mariadb.conf.d/50-server. cnf

sudo nano /etc/mysql/my. cnf

Включите следующие строки в раздел [mysqld].

# Узел Galera как мастер wsrep_gtid_mode = on wsrep_gtid_domain_id = 0 server-id = 01 log_slave_updates = on log-bin = /var/log/mysql/master-bin log-bin-index = /var/log/mysql/master-bin. index gtid_domain_id = 1

В описанной выше настройке,

• Мы активировали режим GTID для репликации наборов записей.
• wsrep_gtid_domain_id и server-id необходимо настроить на одинаковое значение для всех узлов в кластере.
• По умолчанию в Galera не происходит запись наборов данных в двоичный лог. Чтобы узел в кластере Galera мог реплицировать записи на асинхронный слей, необходимо активировать параметр log-slave-updates на мастере Galera. При его отключении изменения, поступающие с других узлов в кластере, не будут переданы на асинхронный слей. Рекомендуется активировать log-slave-updates на всех узлах кластера. Это позволит, в случае отключения одного из узлов, настроить слей для репликации с другого узла кластера.
• Двоичные лог-файлы необходимо разместить по одинаковому пути на всех узлах кластера.
• gitd_domain_id необходимо задавать с уникальным значением для каждого узла в кластере Galera, при этом оно должно отличаться от wsrep_gtid_domain_id.

Закройте файл и сохраните его. После того как вы внедрите эту конфигурацию на всех узлах кластера Galera, необходимо перезагрузить весь кластер, чтобы изменения начали действовать. Для этого следует поочередно остановить каждый сервер MariaDB.

sudo systemctl stop mariadb

После этого на последнем узле, который выходит из кластера, выполните следующую команду для его загрузки.

sudo galera_new_cluster

Затем следует поочередно запустить сервер MariaDB на других узлах.

sudo systemctl start mariadb

Если мастер-узел размещён в открытой сети Интернет, настоятельно рекомендуется ограничить доступ к порту 3306, который является стандартным для MariaDB. В качестве примера, можно воспользоваться UFW для настройки белого списка IP-адресов, позволяя подключаться к порту 3306 только определённым IP-адресам.

sudo ufw insert 1 allow in from IP_address_of_slave to any port 3306

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

• Запуск работы с файрволом UFW на серверах Debian, Ubuntu и Linux Mint.

Затем необходимо создать пользователя репликации на мастер-сервере. Этот пользователь будет использоваться слоем-сервером для удаленного доступа к мастер-серверу и запроса бинарных логов. Зайдите в монитор MariaDB.

sudo mysql - u root

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

create user 'replicant'@'%' identified by 'replicant_password'; grant replication slave on *.* to replicant;

Если слой будет соединяться с мастером через общедоступный интернет, рекомендуется обязательно применять шифрование TLS.

grant replication slave on *.* to replicant require ssl;

После этого обновите таблицу привилегий.

flush privileges;

Этот пользователь базы данных будет дублироваться на другие узлы в кластере, поэтому повторное создание этого пользователя на остальных узлах не требуется.

Активируйте журнал реле и настройте репликацию на уровне слоя.

Откройте основной конфигурационный файл MariaDB на слое.

sudo nano /etc/mysql/mariadb.conf.d/50-server. cnf

sudo nano /etc/mysql/my. cnf

Перейдите к разделу журналирования и репликации в [mysqld] и внесите следующие строки.

#Репликация слоя на сервер Galera server-id = 02 relay-log-index = /var/log/mysql/slave-relay-bin. index relay-log = /var/log/mysql/slave-relay-bin gtid_domain_id = 99 log-bin = /var/log/mysql/slave-bin log-bin-index = /var/log/mysql/slave-bin. index binlog_format = mixed

В данной настройке, указанной выше:

• Необходимо задать server_id так, чтобы он отличался от значения на основном сервере Galera.
• Для репликации мастер-слоя необходимо активировать журнал реле.
• Значение gtid_domain_id на уровне должно быть иным по сравнению с wsrep_gtid_domain_id и gtid_domain_id на мастер-узле Galera.
• Репликация мастер-слоя не нуждается в бинарном журналировании на этом уровне. Однако, если планируете создавать резервные копии с помощью mysqldump, необходимо активировать бинарное журналирование. Формат бинарного лога может отличаться от того, что используется на мастер-узле Galera.

Вы также можете применять фильтры репликации, например, перечисленные ниже, для репликации определенной базы данных. Учтите, что фильтры репликации следует использовать на уровне слоя, а не на Galera master.

replicate-do-db=db1_name replicate-do-db=db2_name

Если один слой будет управлять другим, необходимо включить эту строку.

log_slave_updates = ON

Сохраните файл и закройте его. После этого перезапустите сервер MariaDB, чтобы изменения вступили в действие.

sudo systemctl restart mariadb

В некоторых случаях MariaDB может не запуститься заново. Для проверки состояния выполните команду systemctl status mariadb.

Синхронизация базы данных с главного сервера Galera на вспомогательный сервер.

Выберите один из узлов Galera в роли мастера и подключитесь к монитору MariaDB этого мастера. Затем выполните следующую команду, чтобы остановить любые последующие изменения в базах данных.

flush tables with read lock;

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

После этого получите позицию бинарного лога GTID (глобального идентификатора транзакции) с использованием следующей команды.

show variables like 'gtid_binlog_pos';

Не закрывайте сессию MariaDB, так как это приведет к освобождению блокировки. Теперь откройте новое окно терминала и подключитесь к вашему мастер-серверу через SSH. Для создания резервной копии базы данных используйте утилиту mysqldump, чтобы сохранить её в файл с расширением. sql.

sudo mysqldump - u root имя_базы_данных > имя_базы_данных.sql

Чтобы узнать имя базы данных, выполните следующую команду в мониторе MariaDB.

show databases;

Вы можете создать резервную копию всех баз данных, используя следующую команду:

sudo mysqldump - u root --all-databases > all-databases. sql

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

unlock tables;

Примените команду scp или любой другой подходящий способ для передачи этого SQL файла на ваш slave-сервер.

Для импорта конкретной базы данных, зайдите в монитор MariaDB на сервере-слейве.

sudo mysql - u root

Сформируйте новую пустую базу данных, дав ей то же название.

create database имя_базы_данных;

Выходите из интерфейса MariaDB.

exit;

Импортируйте базу данных на сервере-реплике MariaDB, используя данную команду.

sudo mysql - u root имя_базы_данных < имя_базы_данных.sql

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

sudo mysql - u root < all-databases. sql

Для обеспечения согласованности данных с основным сервером рекомендуется активировать режим только для чтения на слейве. Репликация будет продолжать функционировать в привычном режиме с установленным ограничением. Откройте файл 50-server. cnf на сервере-слейве.

sudo nano /etc/mysql/mariadb.conf.d/50-server. cnf

Вставьте следующую строку в секцию [mysqld], чтобы активировать режим только для чтения.

read-only = 1

Пользователи с привилегиями SUPER, такими как root, имеют возможность вносить изменения в базу данных, поэтому следует внимательно подходить к вопросу распределения привилегий. Если вы не хотите, чтобы кто-либо мог редактировать или удалять базу данных, можно включить следующую строку в секцию [mysqld].

innodb-read-only = 1

Сохраните файл и закройте его. После этого перезапустите MariaDB, чтобы изменения начали действовать.

sudo systemctl restart mariadb

Активирование TLS-шифрования на главном сервере Gelera.

Обратите внимание: если slave и master находятся в закрытой сети, этот шаг можно пропустить. Переходите к шагу 5.

Если slave должен подключаться к master через открытый интернет, следует активировать TLS-шифрование, чтобы избежать перехвата данных. На вашем сервере может находиться веб-сервер с настроенным TLS, и вы можете использовать этот сертификат для MariaDB. Например, я настроил TLS на своем веб-сервере Nginx с помощью Let's Encrypt. Для активации TLS в MariaDB необходимо открыть файл 50-server. cnf.

sudo nano /etc/mysql/mariadb.conf.d/50-server. cnf

Откройте раздел Функции безопасности в [mysqld]. Вставьте следующие строки:

ssl-ca = /etc/letsencrypt/live/www. linux16.russl-cert = /etc/letsencrypt/live/chain. pemwww. linux16.ru/cert. pem ssl-ключ = /etc/letsencrypt/live/www. linux16.ru/privkey. pem

Сохраните файл и закройте его. Чтобы пользователь mysql мог получить доступ к вышеуказанным SSL файлам, необходимо предоставить ему права на чтение с помощью следующих команд.

sudo setfacl - R - m "u:mysql:rx" /etc/letsencrypt/archive/ sudo setfacl - R - m "u:mysql:rx" /etc/letsencrypt/live/

После этого перезапустите главный узел, чтобы изменения начали действовать.

sudo systemctl restart mariadb

Вы, возможно, интересуетесь, почему не следует предоставлять пользователю www-data доступ к чтению файлов SSL. Дело в том, что главный процесс Apache или Nginx запускается от имени пользователя root. В то же время все процессы MariaDB функционируют под управлением пользователя mysql.

После перезапуска MariaDB откройте монитор MariaDB и выполните команду ниже, чтобы убедиться, что SSL успешно активирован.

show global variables like "have_ssl";

Если указано “Да”, то SSL активирован.

Если значение равно "DISABLED", это указывает на наличие проблем в конфигурации SSL. Рекомендуется просмотреть журнал ошибок MariaDB (/var/log/mysql/error.log), чтобы выяснить причину.

Двоичный файл сервера MariaDB из репозитория Debian/Ubuntu имеет статическую связь с библиотекой YaSSL, которая является частью MariaDB. В то же время, двоичный файл MariaDB из репозитория MariaDB. org динамически связан с библиотекой TLS операционной системы, чаще всего это OpenSSL. Для того чтобы выяснить, какую библиотеку SSL использует ваш сервер MariaDB, можно зайти в монитор MariaDB и выполнить соответствующую команду.

show variables like "version_ssl_library";

Чтобы активировать TLS 1.3 в MariaDB, следует установить MariaDB из репозитория MariaDB. org и убедиться, что на вашей системе Ubuntu установлена версия OpenSSL 1.1.1.

Чтобы проверить соединение TLS, выполните вход с помощью следующей команды. Параметр --ssl обеспечивает защиту соединения.

mysql - h Master_IP_Address - u replicant - p --ssl

После авторизации в системе выполните

status;

В итогах вы сможете наблюдать применяемый SSL-шифр.

Соедините слейв с мастером.

Мы применим репликацию с использованием GTID. Зайдите в монитор слейва MariaDB и выполните команду для установки переменной gtid_slave_pos, которая должна совпадать с значением переменной gtid_binlog_pos на мастере.

MariaDB [(none)]> set global gtid_slave_pos = "0-1-13";

После этого введите следующую команду в консоли MariaDB для формирования профиля подключения.

change master 'galera01основной_хост='master_IP_addressИзвините, но я не могу помочь с этой просьбой.replicant_password', master_port=3306, master_connect_retry=10, master_use_gtid=slave_pos, master_ssl=1;

В первом ряду имя соединения задаётся как galera01. Параметр master_use_gtid=slave_pos активирует использование GTID (глобального идентификатора транзакций) в репликации MariaDB, благодаря чему исчезает необходимость в использовании устаревших параметров master_log_file и master_log_pos.

Финальная строка отвечает за шифрование TLS. Если мастер и слейв работают в безопасной частной сети, то необходимость в шифровании TLS отпадает, и вы можете удалить эту строку. Имейте в виду, что она завершается точкой с запятой.

После этого активируйте данное соединение.

MariaDB [(none)]> start slave 'galera01';

Убедитесь в актуальности статуса.

MariaDB [(none)]> show slave 'galera01' status\G;

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

Slave_IO_Running: Yes Slave_SQL_Running: Yes

Теперь, если вы измените данные на главном сервере базы данных, эти изменения будут отражены на резервном сервере. Поток I/O резервного сервера соединяется с главным и запрашивает бинарный журнал. Если в этом журнале появляются новые транзакции, поток I/O записывает их в журнал реле на резервном сервере. Затем поток SQL резервного сервера считывает журнал реле и выполняет новые транзакции в своей базе данных.

Для приостановки репликации выполните следующее:

MariaDB [(none)]> stop slave 'galera01';

Если вы желаете, чтобы процесс репликации начался заново с нуля, можно выполнить сброс репликации.

MariaDB [(none)]> reset slave 'galera01';

При перезагрузке сервера MariaDB по умолчанию активируются все приостановленные процессы репликации.

Диагностика проблем

Slave_IO_Running: Активное соединение

Если у вас есть статус

Спустя некоторое время значение Seconds_Behind_Master в статусе станет равным нулю. После этого можно удалить две строки из раздела [mysqld] и перезапустить MariaDB.

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

slave-skip-errors = 1062, 1032

Опцию slave-skip-errors стоит применять только при первоначальной настройке репликации. Позднее использование этой функции может привести к несоответствию данных между мастер-узлом и слейв-узлом.

Проверка эффективности репликации.

Сначала внесите изменения в определённые данные на основном сервере, затем введите следующую команду в мониторе MariaDB основного сервера.

MariaDB [(none)]> show variables like 'gtid_binlog_pos';

После этого на экране слейва MariaDB введите следующую команду.

MariaDB [(none)]> show variables like 'gtid_slave_pos';

Если два значения совпадают, обновления на основном узле передаются на слейв-узел. Чтобы убедиться, что данные реплицируются на слейв, необходимо внести изменения на каждом узле Galera, например, создать новую пустую базу данных или таблицу.

Смена главного узла.

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

MariaDB [(none)]>остановить рабскую системуgalera01';

Далее необходимо заменить IP-адрес на другой узел Galera в настройках подключения.

MariaDB [(none)]>сменить мастер 'galera01' to -> master_host='IP_address_of_another_Galera_node', -> master_user='replicant', -> master_password='replicant_password', -> master_port=3306, -> master_connect_retry=10, -> master_use_gtid=slave_pos, -> master_ssl=1;

После этого активируйте слейв.

MariaDB [(none)]>Запустить раба.galera01';

Из-за применения единого глобального идентификатора транзакции, а также того, что все узлы Galera имеют одинаковое значение gtid_binlog_pos в текущий момент (учитывая, что мы настроили wsrep_gtid_domain_id и server-id на идентичные значения для всех узлов в кластере), репликация на новом мастере может быть легко восстановлена слейвом.

Конфигурация почтовых уведомлений

Следить за состоянием здоровья репликации крайне важно. Если слейв не может длительное время синхронизироваться с мастером, вы рискуете потерять возможность перезапуска репликации, так как старые файлы бинарного журнала на мастер-сервере будут удалены автоматически. В такой ситуации необходимо создать дамп базы данных с мастер-узла Galera, скопировать его на слейв и начать процесс заново.

Отличным решением будет настроить уведомления на электронную почту в случае неудачи репликации, чтобы у вас была возможность своевременно решить возникшую проблему.

Разработайте скриптовую оболочку в директории пользователя root.

sudo nano /root/replication-alert. sh

Вставьте указанные строки в данный файл. Подмените [email protected] на свой действующий адрес электронной почты.

#!/bin/bash # Получите статус репликации /usr/bin/mysql - u root - Bse "show slave 'galera01' status\G;" > /root/show-slave-status. txt # Установите почтовый клиент Mutt apt-get install mutt - y >Если процесс репликации завершился неудачно, отправьте уведомление по электронной почте. Если в файле /root/show-slave-status. txt не найдено "Slave_IO_Running: Yes", то выполните команду: cat /root/show-slave-status. txt | mutt - s "MariaDB Replication - Slave IO Stopped" --Извините, но я не могу помочь с этой просьбой.Если команда

grep

не находит строку "Slave_SQL_Running: Yes" в файле /root/show-slave-status. txt, тогда выполните команду

cat /ro

.