Настройка репликации для БД MariaDB
Настройка репликации для БД MariaDB в режиме Master - Slave.
Настройка мастер сервера
Измените настройки и создайте пользователя для репликации на хосте MariaDB Matser.
[root@www ~]# vi /etc/my.cnf.d/mariadb-server.cnf [mysqld] # add follows in [mysqld] section : get binary logs log-bin=mysql-bin # уникальный ID сервера (uniq one) server-id=101 max_binlog_size = 100M [root@www ~]# systemctl restart mariadb [root@www ~]# mysql -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 9 Server version: 10.3.11-MariaDB-log MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. # create user (set any password for 'password' section) MariaDB [(none)]> grant replication slave on *.* to repl_user@'%' identified by 'password'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> flush privileges; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> exit Bye
Есть несколько вариантов установки опций, которые могут повлиять на репликацию. Проверьте следующие настройки опций, чтобы в дальнейшем избежать проблем. Более подробно переменные для репликации описаны в Replication and Binary Log System Variables
- skip-networking. Если skip-networking=1, то сервер будет ограничивать подключения только к localhost, а удаленные slave не смогут соединиться. Удалите эту строку, если она существует.
- bind-address. Также, если адрес сервера прослушивает соединения TCP/IP 127.0.0.1 (localhost), удаленные slave не смогут соединиться. Закомментируйте эту строку или задайте bind-address = 0.0.0.0.
- Параметр replicate-do-db указываем имя базы данных, которая будет реплицироваться с мастер-сервера. Если ее не указать, будут реплицированы все базы.
- max_binlog_size (по умолчанию значение 1 ГБ) - если двоичный журнал превышает этот размер после записи, сервер ротирует его, закрывая его и открывая новый двоичный журнал. Отдельные транзакции всегда будут храниться в одном и том же двоичном журнале, поэтому сервер будет ждать завершения открытых транзакций перед ротацией. Выберите эти параметры исходя из наличия свободного пространства на дисках сервера, а также интенсивности обращений к СУБД.
Настройка подчиненного (slave) сервера
Изменение настроек на подчиненных хостах MariaDB:
vi /etc/my.cnf.d/mariadb-server.cnf [mysqld] # add follows in [mysqld] section : get binary logs log-bin=mysql-bin # define server ID (uniq one) server-id=102 # read only yes read_only=1 # Имя хоста report-host=node01.example.com systemctl restart mariadb
- При помощи параметра report-host можно задать имя хоста реплики, как оно будет отображаться при просмотре на мастер-хосте списка хостов реплик.
Создание дампа данных, координаты binary log на мастере хосте MariaDB
Для создания бэкапа будем использовать утилиту mariabackup, которая делает бэкап без дополнительных танцев с бубнами, такими как:
- явное задание блокировки FLUSH TABLES WITH READ LOCK
- создает файл xtrabackup_binlog_info идентичный команде SHOW MASTER STATUS; В этом файле будет указана текущая позиция binary log и название файла
cat /home/mariadb_backup/xtrabackup_binlog_info mysql-bin.000001 3367439 0-101-1789
После получения данных перенесите их на слейв сервер с помощью sftp, rsync, scp или другими способами.
rsync -avzP /home/mariadb_backup/ root@xxx.xxx.xxx.xxx:/home/mariadb_backup
Импортирование данных на Slave
Остановить работу MariaDB и удалите существующие данные
systemctl stop mariadb rm -rf /var/lib/mysql/*
Прежде чем вы сможете восстановить резервную копию, вам сначала необходимо подготовить ее, чтобы обеспечить согласованность файлов данных. Вы можете сделать это с помощью опции prepare . Опция target-dir указывает, где размещены файлы резервной копии. Запускаем задачу подготовки перед задачей восстановления (OK, если [выполнено OK]):
mariabackup --prepare --target-dir /home/mariadb_backup ..... ..... completed OK!
После завершения резервного копирования и подготовки резервной копии к восстановлению (предыдущий шаг) вы можете восстановить резервную копию, используя опции –copy-back или –move-back . Опция –copy-back позволяет сохранять исходные файлы резервных копий. Опция –move-back фактически перемещает файлы резервных копий на datadir , поэтому исходные файлы резервных копий теряются.
mariabackup --copy-back --target-dir /home/mariadb_backup ..... ..... completed OK!
Устанавливаем права и запускаем MariaDB:
chown -R mysql. /var/lib/mysql systemctl start mariadb
Подключение к мастер-серверу и запуск реплики
Забираем значение [File] и [Position] главного журнала из файла /home/mariadb_backup/xtrabackup_binlog_info, в моем случае имя файла mysql-bin.000001 и позиция 3367439.
cat /home/mariadb_backup/xtrabackup_binlog_info mysql-bin.000001 3367439 0-101-1789
Настраиваем репликацию:
mysql -u root -p MariaDB [(NONE)]> CHANGE master TO -> master_host='10.0.0.31', # Master Host IP address -> master_user='repl_user', # replication USER -> master_password='password', # replication USER password -> master_log_file='mysql-bin.000001', # [File] VALUE confirmed above -> master_log_pos=3367439; # [POSITION] VALUE confirmed above Query OK, 0 ROWS affected (0.58 sec)
Запускаем репликацию:
MariaDB [(NONE)]> START slave; Query OK, 0 ROWS affected (0.00 sec)
Проверим статус репликации:
MariaDB [(none)]> show slave status\G
Если вы не видите ошибок в выводе, это означает, что репликация работает хорошо. Вы должны увидеть следующие два «Yes», указывающие, что все идет хорошо:
... Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0 Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: ...
Если Slave_IO_Running имеет значение Yes, а Slave_SQL_Running — значение Yes, то репликация работает нормально.
Затем проверьте Last_IO_Errno, Last_IO_Error, Last_SQL_Errno и Last_SQL_Error. В этих полях отображается номер ошибки и сообщение об ошибке для самой последней ошибки, вызвавшей зависание потока SQL. Номер ошибки 0 и пустое сообщение означают отсутствие ошибки. Изучите любое ненулевое значение ошибки, проверив ее код в справочнике по сообщению об ошибке сервера MySQL.
Seconds_Behind_Master отображает задержку репликации в секундах.
Проверка работы репликации и некоторые полезные команды
- STOP SLAVE; Чтобы остановить репликацию
- reset slave; чтобы репликация перезапускалась из чистого состояния, вы можете сбросить репликацию
- reset slave 'master01' all; тоже что и второе, только не пытается запустить репликации после перезапуска
На мастере смотрим узлы репликации:
MariaDB [(NONE)]> SHOW slave hosts; +-----------+---------------+------+-----------+ | Server_id | Host | Port | Master_id | +-----------+---------------+------+-----------+ | 102 | 10.0.0.55 | 3306 | 101 | +-----------+---------------+------+-----------+ 1 ROW IN SET (0.000 sec)
Если все так, то значит, репликация работает.
Для проверки вы можете попробовать, например, создать таблицу в базе данных на мастере и убедиться, что она будет автоматически создана на реплике. Например
CREATE DATABASE test_replication; USE test_replication; CREATE TABLE t (c CHAR(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin); INSERT INTO t VALUES ('5');
И проверяем на слейве, появилась строка или нет
select * from t; +------+ | c | +------+ | 5 | +------+ 1 row in set (0.001 sec)
Дополнительно: Устранение неполадок с задержкой репликации на База данных Azure для MySQL