Percona Mysql server master - slave репликация

В данной статье хочу затронуть актуальную тему эксплуатации популярного сервера баз данных. Я расскажу, как настроить репликацию master - slave на примере Mysql сервера Percona. Это не пример настройки отказоустойчивой системы. Создается именно актуальная копия базы данных для различных нужд (бэкап, тестирование, тяжелые выборки и т.д.).

Введение

За основу я возьму 2 виртуальные машины на базе Centos 8. Если у вас их еще нет, можете воспользоваться моими статьями на тему установки и базовой настройки Centos 8. Ниже небольшая таблица, чтобы дальше было проще ориентироваться в статье.

Hostname	IP адрес	Версия OS	Версия Mysql
mysql-master	10.20.1.23	Centos 8	Percona Server for MySQL 8.0
mysql-slave	10.20.1.29	Centos 8	Percona Server for MySQL 8.0

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

Краткий список действий

Установка 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. Подобным же образом настраивается и master-master репликация, но на практике она очень нестабильно работает. Я пробовал в свое время, но в итоге отказался, так как надоело ее чинить и исправлять ошибки. Для полноценного кластера с мультизаписью лучше использовать какие-то специализированные решения типа Percona XtraDB Cluster.

Кстати, он же может заменить и текущую конфигурацию, если сделать его из двух нод и писать только в одну. Разрешив ему работать при выходе из строя реплики, получится примерно то же самое, что и в статье. Но смысла в этом особо нет, так как предложенная мной конфигурация настраивается проще и быстрее. Плюс, это типовое решение для любого mysql сервера.

Помогла статья? Подписывайся на telegram канал автора

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