Настройка репликации Master-Slave для MariaDB на Ubuntu 18.04 и 20.04

В данном руководстве объясняется процесс настройки репликации Master-Slave для MariaDB на серверах с Ubuntu 18.04/20.04. MariaDB представляет собой надежную и стабильную реляционную базу данных с открытым исходным кодом, являющуюся форком MySQL. Репликация в MariaDB — это функция, позволяющая копировать данные с одного сервера на другой. Существуют различные виды репликации в MariaDB, включая:

• Репликация «Мастер-Роб»
• Репликация типа Master-Master
• Мульти-источниковое дублирование данных
• Циклическое воспроизведение.

Репликация Master-Slave представляет собой вид репликации, при которой данные передаются только в одном направлении. Сервер, который получает данные от другого сервера, называется slave, а сервер, с которого происходит репликация, — master. Все изменения данных происходят на сервере master, а сервер slave автоматически синхронизирует эти изменения. Несмотря на то что данные на сервере slave могут быть изменены, эти изменения не отразятся на сервере master.

Репликация Master-Slave может иметь различные назначения.

• Масштабируемость: Запись данных осуществляется на главном сервере, в то время как операции чтения могут быть распределены между двумя и более серверами-репликами, что способствует повышению производительности.
• Высокая надежность: Повышение резервирования данных для улучшения устойчивости к сбоям.
• Резервный сервер, предназначенный исключительно для этой цели: вы можете иметь несколько серверов-слейв, из которых один будет выделен только для резервного копирования. На этот резервный сервер-слейв не поступают запросы. При создании резервной копии не будет нарушена работа основного сервера и остальных серверов-слейв.

Репликация Master-Slave в MariaDB: принцип действия и особенности.

Репликация MariaDB осуществляется с помощью двоичного журнала (binlog). Основная задача двоичного журнала заключается в обеспечении репликации, а также в создании резервных копий и восстановлении баз данных. Для успешной работы репликации необходимо активировать двоичное ведение журнала на главном сервере (master). Хотя на сервере-слейве (slave) это ведение не обязательно, его использование настоятельно рекомендуется.

Для успешной работы репликации серверы master и slave должны сначала содержать идентичные данные. После этого изменения данных, известные как транзакции, выполняются на сервере master. Master назначает каждой транзакции уникальный глобальный идентификатор транзакции (GTID) и фиксирует её в своем двоичном журнале. Сервер slave периодически осуществляет проверку двоичного журнала сервера master. В случае наличия новых транзакций, сервер slave добавляет их в свой собственный журнал ретрансляции и выполняет соответствующие операции.

В MariaDB репликация Master-Slave осуществляется в асинхронном режиме. Это означает, что сервер master выполняет транзакции сразу, не дожидаясь их репликации на серверах slave, что позволяет не снижать производительность записи. При асинхронной репликации не требуется постоянное соединение между серверами master и slave.

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

Конфигурация репликации Master-Slave может осуществляться в пяти шагах:

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

Предварительные условия для настройки репликации Master-Slave MariaDB на Ubuntu 18.04 и 20.04.

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

Обратите внимание: есть два способа доступа к мониторингу MariaDB. Первый — это традиционный метод:

mysql - u root - p

Во-вторых, использование префикса sudo перед командой mysql позволяет осуществить вход в MariaDB без необходимости вводить пароль root.

sudo mysql - u root

Я сконфигурировал свой сервер MariaDB для применения второго метода; выберите тот, который вам больше нравится. Теперь приступим к делу.

Активирование двоичного журнала и настройки репликации на главном сервере.

Двухичный лог отключен по умолчанию. Для его активации необходимо отредактировать основной конфигурационный файл MariaDB. Обычно он именуется my. cnf, однако на Ubuntu этот файл называется 50-server. cnf.

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

Перейдите в раздел Logging and Replication в блоке [mysqld] и внесите следующие пять строк.

log-bin = /var/log/mysql/master-bin log-bin-index = /var/log/mysql/master-bin. index binlog_format = mixed server-id = 01 replicate-do-db = database_name

Двоичный журнал состоит из файлов журнала и индексов. В первой строке представлено двоичное ведение записи. Данный журнал сохраняется в директории /var/log/mysql/. Основное имя двоичного журнала — master-bin. Вторая строка, log-bin-index, указывает на название файла, содержащего индекс двоичного журнала.

В третьей строке формата binlog указывается тип двоичных логов. Этот формат может быть основан на операторах (statement-based).

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

sudo mysql - u root

Затем создайте учетную запись пользователя и дайте этому пользователю право на репликацию slave. Замените выделенный текст на нужное имя пользователя и пароль.

create user 'replicant'@'%' identified by 'replicant_passwordпредоставить права на репликацию слейва на . дляreplicant;

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

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

После этого необходимо обновить таблицу прав доступа.

flush privileges;

Не покидайте окно MariaDB в данный момент.

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

Откройте файл 50-server. cnf на резервном сервере.

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

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

server-id = 02 relay-log-index = /var/log/mysql/slave-relay-bin. index relay-log = /var/log/mysql/slave-relay-bin replicate-do-db = database_name

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

log-bin = /var/log/mysql/02-bin log-bin-index = /var/log/mysql/02-bin. index binlog_format = mixed

Если slave будет исполнять функции мастера для другого slave, добавьте также следующую строку.

log_slave_updates = ON

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

sudo systemctl restart mariad


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

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

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

show databases;

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

unlock tables;

Примените команду scp или любой другой способ, чтобы перенести этот SQL-файл на рабочий сервер, после чего зайдите в монитор MariaDB на этом сервере.

sudo mysql - u root

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

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

Покиньте экран MariaDB.

exit;

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

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

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

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

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

read-only = 1

Пол

Если значение равно "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 и обеспечить наличие OpenSSL 1.1.1 на вашей системе Ubuntu.

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

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

После того как вы войдете, выполните

status;

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

Соедините Служебный с Основным.

Теперь откройте интерфейс службы MariaDB и введите следующую команду для создания профиля подключения.

MariaDB [(none)]>Измените мастер 'master01' to -> master_host='master_IP_address', -> master_user='replicant', -> master_password='replicant_password', -> master_port=3306, -> master_log_file='master-bin.000001', -> master_log_pos=62307428, -> master_connect_retry=10, -> master_use_gtid=slave_pos, -> master_ssl=1;

В начале строки имя подключения задается как master01. Для получения значений master_log_file и master_log_pos следует использовать команду show master status на основном сервере MariaDB. Установка master_use_gtid=slave_pos активирует использование GTID (глобального идентификатора транзакции) в процессе репликации MariaDB. Эта функция стала доступна с версии MariaDB 10.0.2.

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

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

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

Пожалуйста, уточните текущее состояние.

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

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

Slave_IO_Running: Yes Slave_SQL_Running: Yes

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

Чтобы прекратить репликацию, выполните следующее:

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

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

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

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

MariaDB [(none)]> reset slave 'master01' all;

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

При первом обращении к статусу служебного, вы можете столкнуться с такой ошибкой.

Last_SQL_Error: Error 'Duplicate entry

Это обычно случается при первом подключении служебного к основному. Если произойдет ошибка, процесс репликации будет приостановлен. Мы можем игнорировать эту ошибку дублирующей записи, добавив следующие две строки в раздел [mysqld] файла конфигурации сервера MariaDB (50-server.conf).

slave-skip-errors=1062 skip-slave-start

Перезапустите сервер MariaDB и затем заново запустите репликацию для служебного экземпляра.

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

Пожалуйста, уточните текущее состояние.

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

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

Убедитесь, что репликация функционирует корректно.

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

MariaDB [(none)]> показать переменные как 'gtid_binlog_pos';

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

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

При равенстве двух значений изменения информации на основном сервере копируются на вторичный сервер.

Как создать резервную копию базы данных на сервере-реплике.

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

• Как создать резервную копию и восстановить базы данных MariaDB через командную строку.

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

Заключение

Надеюсь, этот гид оказался полезным для настройки репликации мастер-слейв MariaDB на серверах Ubuntu 18.04 или 20.04. Если вам понравился этот материал, не забудьте подписаться на нашу бесплатную рассылку, чтобы получать ещё больше полезных советов и рекомендаций.