В данном руководстве будет показано, как настроить простую репликацию Master-Slave в MariaDB. Под простой конфигурацией подразумевается наличие одного мастера и одного слейва, а также единственной репликации между ними. Пример выполнен на сервере с Debian 8 и MariaDB 10.1 в роли мастера, а также на Raspbian Jessie с MariaDB 10.1 в роли слейва.
Содержание статьи
Основы репликации Master-Slave в MariaDB
В конфигурации репликации master-slave все изменения данных осуществляются на сервере мастера, в то время как сервер слейва автоматически копирует эти изменения. Хотя вы можете вносить изменения на сервере слейва, они не будут отражены на сервере мастера.
Репликация MariaDB осуществляется с использованием двоичного журнала. Для успешной работы репликации необходимо активировать двоичное логирование на сервере-мастере. Основная задача двоичного журнала — обеспечить возможность репликации, а также резервного копирования и восстановления данных. На сервере-слейве двоичное логирование не является обязательным, но его использование настоятельно рекомендуется.
Процесс настройки репликации можно осуществить в четыре этапа:
- Настройка помощника
- Конфигурация вспомогательного устройства.
- Создание резервной копии баз данных на основном сервере и последующий импорт на резервный сервер.
- Подсоединение ведомого устройства к управляющему.
Приступим.
Подготовка мастера
Изменение файла конфигурации my. cnf.
Откройте конфигурационный файл my. cnf, который также называется файлом настроек, на сервере главного узла.
sudo nano /etc/my. cnf
Включите эти 5 строк в раздел [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 = имя_базы_данных
Двоичный журнал включает в себя файлы журнала и индексный файл. Параметр log-bin активирует двоичное логирование. Двоичный журнал располагается в каталоге /var/log/mysql/. Основное имя двоичного журнала — master-bin. Параметр log-bin-index определяет имя индексного файла для двоичного журнала.
Третий параметр binlog-format указывает на формат двоичного логирования. Доступные варианты включают логирование, основанное на выражениях, на строках или их смешанный вариант. Смешанное логирование сочетает в себе оба метода и является рекомендованным для репликации. По умолчанию используется логирование на основе выражений, однако, если MariaDB обнаруживает, что выражение может быть небезопасным для репликации, оно переключается на логирование на основе строк.
Хотя записи событий в binlog находятся в бинарном формате, инструмент mysqlbinlog способен выводить их в текстовом виде.
Идентификатор сервера служит для того, чтобы отличать один сервер от другого. Все сервера в репликационной группе обязаны иметь свои уникальные идентификационные номера.
Параметр replicate-do-db служит для определения, какая база данных будет копироваться на слейв-сервер. Не забудьте заменить имя_базы_данных на реальное название вашей базы данных. Если требуется репликация нескольких баз, добавьте несколько строк с replicate-do-db, как показано ниже:
replicate-do-db = db1 replicate-do-db = db2
В вашем файле конфигурации my. cnf может присутствовать строка bind-address = 127.0.0.1. В таком случае, ваш сервер MariaDB будет доступен только с локального хоста. Когда слейв попытается подключиться к мастеру удаленно, необходимо закомментировать эту строку, чтобы разрешить удаленные соединения. Не забудьте сохранить файл и перезапустить службу MariaDB, чтобы изменения вступили в силу.
sudo systemctl restart mariadb
Добавление пользователя для репликации на мастер-сервере.
Сервер-слейв будет применять данного пользователя для удаленного доступа к серверу-мастеру и получения двоичных журналов с него.
Сначала подключитесь к серверу MariaDB.
mysql - u root - p
После этого создайте учетную запись пользователя и дайте этому пользователю права на репликацию (репликация слейва).
Конфигурация Р slaves
Откройте конфигурационный файл my. cnf на сервере-реплике.
sudo nano /etc/my. cnf
Включите журнал реле и репликацию, добавив указанные 4 параметра в раздел [mysqld].
server-id = 02 replicate-do-db = имя_базы_данных relay-log-index = /var/log/mysql/slave-relay-bin. index relay-log = /var/log/mysql/slave-relay-bin
Сохраните файл и закройте его. После этого перезапустите сервер MariaDB slave для применения изменений.
sudo systemctl restart mariadb
В некоторых случаях MariaDB может не перезапуститься. Для проверки её статуса выполните команду systemctl status mariadb.
Экспорт данных из баз на главном сервере.
Зайдите на сервер мастера MariaDB и выполните данную команду, чтобы остановить все последующие изменения в базах данных.
flush tables with read lock;
show master status;
Не спешите выходить. Задокументируйте информацию о файле и его местоположении. Затем откройте новое окно терминала и выполните подключение к вашему мастер-серверу через SSH. Для экспорта базы данных в файл. sql воспользуйтесь утилитой mysqldump.
mysqldump - u root - p имя_базы_данных > имя_базы_данных. sql
Теперь у вас есть возможность разблокировать таблицы на сервере мастера, выполнив соответствующую команду в мониторе MariaDB.
unlock tables;
Скопируйте этот файл дампа на ваш slave-сервер с помощью scp. После этого выполните импорт на slave-сервере.
mysql - u root - p имя_базы_данных. sql < имя_базы_данных
Соединение Р slaves с Мастером
Теперь выполните эту команду на сервере MariaDB slave.
Репликация master-slave в MariaDB способствует повышению доступности и масштабируемости, однако не защищает от потери данных. Если на мастер-сервере выполнить команду drop database, это действие отразится и на слейве. Таким образом, регулярное создание резервных копий вашей базы данных остается необходимым.Одно из достоинств репликации master-slave в MariaDB заключается в том, что можно воспользоваться mysqldump для создания резервной копии базы данных на слейв-сервере. Это происходит без негативного воздействия на производительность мастер-сервера и не вмешивается в операции записи на нем.
Одно из достоинств репликации master-slave в MariaDB заключается в том, что можно воспользоваться mysqldump для создания резервной копии базы данных на слейв-сервере. Это происходит без негативного воздействия на производительность мастер-сервера и не вмешивается в операции записи на нем.