В данной статье хочу затронуть актуальную тему эксплуатации популярного сервера баз данных. Я расскажу, как настроить репликацию master - slave на примере Mysql сервера Percona. Это не пример настройки отказоустойчивой системы. Создается именно актуальная копия базы данных для различных нужд (бэкап, тестирование, тяжелые выборки и т.д.).
За основу я возьму 2 виртуальные машины на базе Centos 8. Если у вас их еще нет, можете воспользоваться моими статьями на тему установки и базовой настройки Centos 8. Ниже небольшая таблица, чтобы дальше было проще ориентироваться в статье.
Начнем настройку репликации с установки Mysql сервера на обе виртуальные машины. Ниже приведу краткий список действий, чтобы сразу было понятно, что мы будем делать.
Краткий список действий
Необходимое время: 1 час.
Настройка master-slave репликации mysql.
- Установка percona mysql server. Подключаем репозиторий и устанавливаем необходимые пакеты.
- Создание или загрузка баз данных для репликации. Покажу на примере, как загрузить из дампа базу данных, для которой настроим репликацию.
- Настройка непосредственно репликации. Подробно расскажу и покажу, как настроить репликацию загруженной базы.
- Проверка работы репликации. Приведу пример, как можно убедиться, что репликация работает.
Установка Percona Mysql Server
Установить percona mysql server не представляет никакой сложности, так как есть репозиторий с готовыми пакетами под все популярные системы, в том числе под centos. Подключаем этот репозиторий. Действия выполняем одновременно на обоих серверах.
# dnf install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
Отключаем стандартный модуль mysql и активируем репозиторий перконы.
# dnf module disable mysql
# percona-release setup ps80
Устанавливаем Percona Mysql Server на Centos 8. Заодно поставим xstrabackup и другие утилиты, которые нам могут понадобиться в процессе эксплуатации.
# dnf install percona-server-server percona-toolkit percona-xtrabackup-80
После установки запускаем mysql сервер и добавляем в автозагрузку.
# systemctl enable --now mysqld
Во время установки был автоматически сгенерирован временный пароль root. Посмотреть его можно в логе /var/log/mysqld.log.
# grep "temporary password" /var/log/mysqld.log
2020-04-28T09:31:57.348581Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: NdqhLZkEr0_p
Используя этот пароль, выполним начальную настройку сервера, удалив все лишнее и указав свой пароль. Имейте ввиду, что по умолчанию установлен Password Validation Plugin, который не позволит вам создать простой пароль. Он должен удовлетворять следующим требованиям:
- Длина от 8-ми символов;
- Минимум 1 цифра;
- Минимум 1 спецсимвол.
# mysql_secure_installation
Убедитесь, что вы запомнили свой новый пароль и можете подключаться, используя его.
# mysql -u root -p
> SHOW VARIABLES LIKE 'validate_password%';
Серверы Mysql установили на обоих виртуальных машинах. Двигаемся дальше.
Загрузка базы данных
Загрузим теперь на оба наших сервера дампы базы данных, которую он будет обслуживать. Если вы начинаете новую базу с нуля, то просто создайте ее на обоих серверах. Я же загружу из архива, сделанного с помощью mysqldump, базу своего сайта.
# mysql -u root -p
> create database serveradmin;
> use serveradmin;
> source ~/mysql_serveradmin.ru_2020-04-28_04-15.sql;
Теперь создадим на мастере учетную запись, от имени которой будет работать репликация. Напоминаю, что 10.20.1.29 — ip адрес для slave сервера.
> CREATE USER 'repl'@'10.20.1.29' IDENTIFIED BY '1qaz@WSX';
> GRANT replication slave ON . TO 'repl'@'10.20.1.29';
Настройка master — slave репликации
У нас все готово для настройки непосредственно репликации. Но перед тем, как ее начать, убедитесь, что у вас настроен или отключен firewalld. В общем случае на мастере разрешите подключаться к серверу по tcp порту 3306, на котором работает mysql сервер.
# firewall-cmd --permanent --add-port=3306/tcp
# firewall-cmd --reload
Теперь запускаем репликацию. Для этого идем на мастер и смотрим master log position в консоли mysql.
> show master status;
Переходим на slave и выполняем в консоли mysql.
> CHANGE MASTER TO MASTER_HOST = '10.20.1.23', MASTER_USER = 'repl', MASTER_PASSWORD = '1qaz@WSX', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 706;
> start slave;
Проверяем статус репликации.
> show slave status \G;
Скорее всего вы увидите ошибку:
error connecting to master 'repl@10.20.1.23:3306' - retry-time: 60 retries: 7 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.
Суть ее в том, что в версии Mysql 8 поменялся плагин для аутентификации с mysql_native_password на caching_sha2_password. Теперь для корректной работы репликации необходимо настраивать подключение с использованием tls сертификатов. Если инфраструктура закрытая и данные передаются не через интернет, то этим можно пренебречь. К примеру, я всегда настраиваю vpn тоннель, если репликация работает через интернет.
Самый простой способ исправить ошибку, это зашифровать пароль пользователя предыдущим плагином. Делается это так.
> ALTER USER 'repl'@'10.20.1.29' IDENTIFIED WITH mysql_native_password BY '1qaz@WSX';
После этого вернитесь на slave, остановите репликацию, обновите информацию с мастера и запустите заново. Ошибки быть не должно.
> stop slave;
> CHANGE MASTER TO MASTER_HOST = '10.20.1.23', MASTER_USER = 'repl', MASTER_PASSWORD = '1qaz@WSX', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 1226;
> start slave;
Проверьте теперь статус репликации. Признаком того, что все в порядке, будет отсутствие ошибок и информация в следующих строках.
Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
- Slave_IO_State — состояние репликации, в норме ожидание событий с мастера.
- Slave_IO_Running — индикатор работы демона по сбору бинарного лога с мастера и записи его в локальный relay лог.
- Slave_SQL_Running — индикатор выполнения команд из локального relay лога.
- Seconds_Behind_Master — то, насколько слейв сервер отстает от мастера в репликации. Идеально 0 секунд, но может и отставать немного.
Если репликация идет нормально, slave будет идти за master. Номер лога Master_Log_File и позиция Exec_Master_Log_Pos будут расти. Если значение Slave_IO_State пусто или Connecting to master, а Seconds_Behind_Master равно NULL, репликация не началась.
Проверка репликации
Дальше можете проверять работу репликации. Так как у нас настроена репликация всей информации, можете создать на мастере новую базу данных и добавить в нее какие-то значения.
> CREATE DATABASE testdb;
> CREATE TABLE IF NOT EXISTS testdb.data1 (id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, string VARCHAR(100));
> INSERT INTO data1(string) VALUES ("Test For Replication");
Теперь идем на реплику и проверяем, получила ли она изменения.
> show databases;
> use testdb;
> select * from data1;
Все в порядке, репликация работает. Можно настроить ее мониторинг. Для бэкапа данных с реплики рекомендую использовать percona xtrabackup.
Часто задаваемые вопросы по теме статьи (FAQ)
Есть ли отличия в настройке репликации master slave в других форках mysql, например mariadb?
Нет. Описанный мной способ подходит для настройки репликации во всех популярных версиях серверов mysql.
Как следует добавлять дополнительные slave серверы, если возникнет такая необходимость?
Никакой разницы нет, будет ли у вас один slave сервер или несколько. Добавление следующих серверов происходит точно так же, как и первого. Настраиваете slave сервер, заливаете дамп баз и запускаете репликацию.
Что следует сделать, чтобы вернуть репликацию, если slave сервер потеряет связь с мастером?
Ничего особенного делать не надо. Если связь с мастером прервалась и репликация остановилась, достаточно восстановить связь и запустить заново репликацию. Slave сервер подтянет все изменения с мастера.
Заключение
Вот так относительно просто настраивается обычная master — slave репликация mysql. Подобным же образом настраивается и master-master репликация, но на практике она очень нестабильно работает. Я пробовал в свое время, но в итоге отказался, так как надоело ее чинить и исправлять ошибки. Для полноценного кластера с мультизаписью лучше использовать какие-то специализированные решения типа Percona XtraDB Cluster.
Кстати, он же может заменить и текущую конфигурацию, если сделать его из двух нод и писать только в одну. Разрешив ему работать при выходе из строя реплики, получится примерно то же самое, что и в статье. Но смысла в этом особо нет, так как предложенная мной конфигурация настраивается проще и быстрее. Плюс, это типовое решение для любого mysql сервера.