Шаг 1. Настройка Мастера
На сервере, который будет выступать мастером, необходимо внести правки в my.cnf :
- server-id — идентификатор сервера, должен быть уникален. Лучше не использовать 1;
- log_bin — путь к бинарному логу;
- binlog_do_db — позволяет перечислить отдельные базы, для которых будет использоваться реплика.Если не инициализирована, то реплицируются все.
mysqld # предлагаю указать последний октет IP-адреса server-id = 11 log_bin = varlibmysqlmysql-bin.log # название Вашей базы данных, которая будет реплицироваться binlog_do_db = newdatabase
Перезагружаем MySQL:
# В зависимости от системы и ПО: etcinit.dmysql restart # или systemctl restart mysqld.service # или systemctl restart mariadb.service
Конфигурационные файлы
Для настройки репликации с использованием GTID в MYSQL в конфиге мастера достаточно прописать следующие значение:
Ниже описание используемых обязательных директив из конфига:
- gtid_mode=ON – собственно, включает GTID;
- log_bin=mysql-bin – ведение бинарного лога для мастера (с него читает слейв). Когда на сервере используются GTID, и если бинарный лог не включен, при перезапуске сервера после аварийного выключения, некоторые GTID могут быть потеряны, что приведет к сбою репликации. При обычном завершении работы набор идентификаторов GTID из бинарного лога сохраняется в таблице mysql.gtid_executed;
- enforce-gtid-consistency – обязательный параметр для GTID, который не даёт всё поломать;
- server_id=1 идентификатор мастер сервера, цифровое значение может быть отличным от единицы в данном примере;
Также присутствуют необязательные директивы, но пару слов можно сказать и про них:
log-slave-updates = 0 – необходим при использовании схемы А -> Б -> C, где А – гл. сервер для Б, а Б – гл. сервер для С, т.е. “гирляндная” или последовательная схема. Для случаев, когда данные от мастера пишутся в отдельный бинлог реплики для использования реплики в качестве мастера для другой реплики. Редкий случай;sync_binlog = 0 – используется для синхронизации всех транзакций с двоичным файлом. По факту повышает надёжность транзакций для слейва при отказе ОС в случае сбоя. А также сильно влияет на производительность I\O хранилища, поэтому можно либо его отключить и положиться на надёжность отказоустойчивости системы, или же включить при наличии скоростного хранилища. В общем, использовать или нет – зависит от требований. Например, при установке sync_binlog=1 для БД Битрикс24, попугаи в тестах производительности на чтение\запись в БД могут заметно уменьшиться.
Шаг 2. Права на репликацию
Далее необходимо создать профиль пользователя, из под которого будет происходить репликация. Для этого запускаем консоль:
mysql -u root -p
Далее создаем и назначаем права пользователю для реплики:
Далее блокируем все таблицы в нашей базе данных:
Проверяем статус Мастер-сервера:
Мы увидим что-то похожее на:
mysql> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 107 | newdatabase | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
Часто задаваемые вопросы по теме статьи (FAQ)
Есть ли отличия в настройке репликации master slave в других форках mysql, например mariadb?
Нет. Описанный мной способ подходит для настройки репликации во всех популярных версиях серверов mysql.
Как следует добавлять дополнительные slave серверы, если возникнет такая необходимость?
Никакой разницы нет, будет ли у вас один slave сервер или несколько. Добавление следующих серверов происходит точно так же, как и первого. Настраиваете slave сервер, заливаете дамп баз и запускаете репликацию.
Что следует сделать, чтобы вернуть репликацию, если slave сервер потеряет связь с мастером?
Ничего особенного делать не надо. Если связь с мастером прервалась и репликация остановилась, достаточно восстановить связь и запустить заново репликацию. Slave сервер подтянет все изменения с мастера.
How to Configure MySQL (MariaDB) Master-Slave Replication on Debian 10
22 Апреля 2021
|
Debian
Репликация MySQL — это процесс копирования данных с одного сервера базы данных (главного) на один или несколько серверов (подчиненных).
MySQL поддерживает несколько топологий репликации, причем топология «ведущий / ведомый» является одной из наиболее известных топологий, в которой один сервер базы данных действует как ведущий, а один или несколько серверов действуют как ведомые. По умолчанию репликация является асинхронной, когда ведущее устройство отправляет события, описывающие изменения базы данных, в свой двоичный журнал, а ведомые устройства запрашивают события, когда они готовы.
Этот тип топологии репликации лучше всего подходит для развертывания реплик чтения для масштабирования чтения, резервного копирования баз данных в реальном времени для аварийного восстановления и для задач аналитики.
Прежде чем продолжить
Мы предполагаем, что у вас есть два сервера под управлением Debian 10, которые обмениваются данными друг с другом по частной сети. Если ваш хостинг-провайдер не поддерживает частные IP-адреса, вы можете использовать общедоступные IP-адреса и настроить брандмауэр, чтобы разрешить трафик на порт 3306 только из надежных источников.
Серверы, используемые в этом примере, имеют следующие IP-адреса:
Установка MariaDB
Репозитории Debian 10 по умолчанию включают MariaDB версии 10.3. Лучше всего установить одну и ту же версию MariaDB на оба сервера, чтобы избежать любых потенциальных проблем.
Установите MariaDB как на ведущем, так и на ведомом устройстве, выполнив следующие команды:
Настройка главного сервера
Первый шаг — настроить главный сервер. Мы внесем следующие изменения:
- Настройте сервер MariaDB для прослушивания частного IP-адреса .
- Установите уникальный идентификатор сервера.
- Включите двоичное ведение журнала.
Откройте файл конфигурации MariaDB и раскомментируйте или установите следующие строки:
мастер: /etc/mysql/mariadb.conf.d/50-server.cnf
После этого сохраните файл и перезапустите службу MySQL, чтобы изменения вступили в силу:
Следующим шагом будет создание нового пользователя репликации. Войдите на сервер MariaDB как пользователь root:
Выполните следующие запросы SQL, чтобы создать пользователя с именем и предоставить ему привилегию:
Убедитесь, что вы изменили IP-адрес на свой подчиненный IP-адрес. Вы можете назвать пользователя как хотите.
Находясь в командной строке MySQL, выполните следующую команду, которая распечатает двоичное имя файла и позицию.
Обратите внимание на имя файла mysql-bin.000001 и позицию 328. Эти значения необходимы при настройке подчиненного сервера и, вероятно, будут другими на вашем сервере.
Настройка подчиненного сервера
Мы внесем те же изменения на подчиненном сервере, что и на главном:
- Настройте сервер MySQL на прослушивание частного IP-адреса.
- Установите уникальный идентификатор сервера.
- Включите двоичное ведение журнала.
Откройте файл конфигурации MariaDB и отредактируйте следующие строки:
подчиненный: /etc/mysql/mariadb.conf.d/50-server.cnf
Перезапустите службу MariaDB:
Следующим шагом является настройка параметров, которые подчиненный сервер будет использовать для подключения к главному серверу. Войдите в оболочку MariaDB:
Начните с остановки подчиненных потоков:
Выполните следующий запрос, чтобы настроить репликацию Master / Slave:
Убедитесь, что вы используете правильный IP-адрес, имя пользователя и пароль. Имя и позиция файла журнала должны совпадать со значениями, полученными от главного сервера.
После этого запустите подчиненные потоки.
Проверить конфигурацию
На этом этапе у вас должна быть рабочая настройка репликации Master / Slave.
Чтобы убедиться, что все настроено правильно, создайте новую базу данных на главном сервере:
Войдите в подчиненную оболочку MySQL:
Выполните следующую команду, чтобы вывести список всех баз данных :
Вы заметите, что база данных, созданная на главном сервере, реплицируется на подчиненный:
В этом руководстве мы показали, что вы создаете репликацию MariaDB Master / Slave в Debian 10.
Настройка главного сервера
Первым делом нужно настроить главный сервер. Внесем следующие изменения:
- Настройте сервер MariaDB для прослушивания частного IP-адреса .
- Установите уникальный идентификатор сервера.
- Включите двоичное ведение журнала.
Откройте файл конфигурации MariaDB и раскомментируйте или установите следующие строки:
master:/etc/mysql/mariadb.conf.d/50-server.cnf
![Mysql. настройка репликации master-slave [в помощь...]](https://myeditor.ru/wp-content/uploads/e/5/c/e5c56f4877cefa8eae855aad0cb87692.png)
После этого сохраните файл и перезапустите службу MySQL, чтобы изменения вступили в силу:
Следующим шагом будет создание нового пользователя репликации. Войдите на сервер MariaDB как пользователь root:
Выполните следующие запросы SQL, чтобы создать пользователя с именем и предоставить пользователю привилегию :
Убедитесь, что вы изменили IP-адрес на свой подчиненный IP-адрес. Вы можете назвать пользователя как хотите.
Находясь в командной строке MySQL, выполните следующую команду, которая выведет двоичное имя файла и позицию.
Обратите внимание на имя файла, mysql-bin.000001 и позицию 328. Эти значения необходимы при настройке подчиненного сервера и, вероятно, будут другими на вашем сервере
Многопоточная репликация
До недавнего времени Mysql реплика работала всего в один поток. Тогда, даже если мастер и слейв идентичны по характеристикам, слейв все равно может отставать от мастера.
... slave-parallel-workers = 2 ...
# Включение репликации в 2 потока
Число задает количество потоков и может принимать значения от до . Значение отключит многопоточную обработку бинлога.
При включении этой настройки Mysql будет распределять обработку бинлога разных баз данных между разными потоками. Это даст возможность Mysql не ждать завершения операций в разных базах, а выполнять их параллельно. На мастере для этого ничего настраивать не нужно.
Понятно, что если у вас всего одна база данных, вы не получите прирост в производительности. Зато в версии Mysql 5.7 можно изменить тип распределения операций с помощью настройки в my.cnf:
... slave-parallel-workers = 2 ...
# Изменения типа параллелизации обработки бинлога
В таком случае, уже все операции (точнее закомиченные транзакции) из бинлога будут обрабатываться параллельно.
Принцип работы GTID
GTID появился с MySQL 5.6 и представляет собой уникальный 128-битный глобальный идентификационный номер (SERVER_UUID), который увеличивается с каждой новой транзакцией. Выглядит GTID примерно так:
Классическая репликация MySQL без GTID использует позицию в бинарном логе. Но благодаря GTID больше не нужно разбираться с вычислениями позиции бинлога. Из преимуществ GTID является согласованность данных, т.е. на сервере (как на мастере, так и на слейве) будет подтверждена одна и только одна транзакция с одним GTID, а любые другие транзакции, имеющие такой же UUID, будут проигнорированы. Подробную теорию можно дополнительно изучить на официальном сайте MySQL.
Использование GTID – это хорошая практика, т.к. данные между мастером и слейвом более консистентные с GTID, настройка ещё быстрее и проще.
В MySQL при использовании GTID есть две глобальные переменные, о которых необходимо знать:
- gtid_executed – содержит набор всех транзакций из бинарного лога;
- gtid_purged – содержит набор транзакций, которые были зафиксированы на сервере, но не содержащиеся в бинарном логе. gtid_purged является подмножеством gtid_executed.
Вышеописанные переменные получают свои значения при каждом запуске MySQL. На мастер-сервере это выглядит так:
MySQL репликация MASTER-MASTER
Инструкция как настроить репликацию типа Master-Master в MySQL.
Предположим, у нас есть один сервер БД, и нужно подключить второй. Например, хотим кластер из двух серверов, на каждом из которых будет происходить постоянная активность.
Итак, на первом сервере (192.168.30.11) у нас есть база base_test. Необходимо создать её также и на втором (192.168.30.12):
|
mysql> CREATE DATABASE base_test; Query OK, 1 row affected (0.00 sec) mysql> GRANT ALL PRIVILEGES ON base_test.* TO ‘base_test_user’@’%’ identified by ‘123456’; |
Базу создали. Далее желательно запретить все подключения к базе первого сервера, и скопировать базу данных base_test на второй сервер.
В файл конфига MySQL my.cnf на первом сервере пишем к примеру так:
|
#уникальный ID сервера, участвующего в репликации server-id = 1 # чтобы не было конфликтов автоинкремента, говорим серверу, чтобы айдишники он генерил начиная с 1-го прибавляя по 2, например 1, 3, 5, 7 … Зеркало будет генерить 2, 4,6, 8 … auto_increment_increment = 2 auto_increment_offset = 1 # путь к файлу журнала log_bin = /var/log/mysql/mysql-bin expire_logs_days = 5 max_binlog_size = 100M binlog_do_db = base_test replicate_do_db = base_testbase_test |
А на втором изображаем такое:
|
Server-id = 2 auto_increment_increment = 2 auto_increment_offset = 2 log_bin = /var/log/mysql/mysql-bin expire_logs_days = 5 max_binlog_size = 100M binlog_do_db = base_test replicate_do_db = base_test |
Перезапускаем демоны mysql-server на каждом сервере:
|
# /usr/local/etc/rc.d/mysql-server restart |
На обоих серверах создадим пользователя replicator для репликации:
|
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘replicator’@’%’ IDENTIFIED BY ‘password’; |
Сбрасываем параметры репликации:
|
mysql> STOP SLAVE; mysql> RESET SLAVE; mysql> RESET MASTER; |
Далее сделаем конструкцию, чтобы каждый сервер друг другу был мастером и также слейвом. На первом сервере (192.168.30.11) выполняем команду:
|
mysql> SHOW MASTER STATUS; +————————-+————+———————+————————-+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +————————-+————+———————+————————-+ | mysql-bin.000005 | 97 | blog,blog | | +————————-+————+———————+————————-+ 1 row in set (0.00 sec) |
и на втором (192.168.30.12):
|
mysql> SHOW MASTER STATUS; +————————+————+———————+—————————+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +————————+————+———————+—————————+ | mysql-bin.000006 | 97 | blog,blog | | +————————+————+———————+—————————+ 1 row in set (0.00 sec) |
Из вывода последней команды нас интересуют значения параметров File и Position и вместе с IP-адресом, подставим в команду CHANGE MASTER текущего сервера. Таким образом, на первом 192.168.30.11 сервере выполняем:
|
mysql> CHANGE MASTER TO MASTER_HOST=’192.168.30.12′, MASTER_PORT=3306, MASTER_USER=’replicator’, MASTER_PASSWORD=’password’, MASTER_LOG_FILE=’mysql-bin.000006′, MASTER_LOG_POS=107, MASTER_CONNECT_RETRY=10; START SLAVE; |
На втором 192.168.30.12 сервере:
|
mysql> CHANGE MASTER TO MASTER_HOST=’192.168.30.11′, MASTER_PORT=3306, MASTER_USER=’replicator’, MASTER_PASSWORD=’password’, MASTER_LOG_FILE=’mysql-bin.000005′, MASTER_LOG_POS=107, MASTER_CONNECT_RETRY=10; START SLAVE; |
Чтобы убедиться, что репликация работает, смотрим вывод команды на обоих серверах:
|
mysql> SHOW SLAVE STATUS\G |
Должны присутствовать строки:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Репликация Мастер-Мастер
Для репликации мастер-мастер (двусторонняя репликация) проводится настройка аналогичная “Master-Slave” с точностью до наоборот (основной Master настраивается как Slave, а второй (бывший Slave) — как Мастер). Если на втором мастере не будет производиться запись (”пассивный” мастер), то изменение Autoincrement-increment не потребуется.
При репликации двух активных master-master следует обратить внимание на Autoincrement. Действительно, если на двух серверах одновременно будет создана запись с одинаковым первичным ключом, то при попытке репликации получим ошибку Dublicate entry
Проблема с auto_increment решается выставлением двух переменных
Однако, при этом следует иметь ввиду, что на первом сервере ВСЕ автоинкрементные поля будут нечетными, а на втором — все будут четными.
Подборка ссылок по уникальным ключам (в PostgreSQL)
http://www.sql.ru/forum/actualthread.aspx?tid=422194
Подборка ссылок по Master-Slave репликации
http://habrahabr.ru/blogs/mysql/56702/ — подробно, с описанием “рокировки”;
Подборка ссылок по двусторонней репликации в MySQL
http://www.howtoforge.com/mysql_master_master_replication
http://www.itnotes.org.ua/administration/mysql/master_master_replication_db.html
http://www.initialize.ru/mysql-master-master-replikaciya
http://www.gra2.com/article.php/setting-up-database-replication-on-mysql
MySQL Multi Master Manager
http://mysql-mmm.org/
http://onlamp.com/onlamp/2006/04/20/advanced-mysql-replication.html
MySQL Load Balanced Cluster
http://www.howtoforge.com/loadbalanced_mysql_cluster_debian
http://www.dancryer.com/2010/01/mysql-circular-replication
Синхронизация сайтов:
http://habrahabr.ru/blogs/ubuntu/104342/
http://habrahabr.ru/blogs/sysadm/86496/
http://en.wikipedia.org/wiki/High-availability_cluster
http://habrahabr.ru/blogs/studiobusiness/90349/
Синхронизация Drupal-сайтов с помощью migraine
http://barkingiguana.com/2008/07/20/load-balanced-highly-available-mysql-on-ubuntu-804/
Основы масштабирования + ссылки
http://habrahabr.ru/blogs/webdev/15362/
Метки: mysql
Статус репликации
Проверить работу репликации на Слейве можно запросом:
mysql> SHOW SLAVE STATUS\G
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 3306
Connect_Retry: 3
Master_Log_File: gbichot-bin.005
Read_Master_Log_Pos: 79
Relay_Log_File: gbichot-relay-bin.005
Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno:
Last_Error:
Skip_Counter:
Exec_Master_Log_Pos: 79
Relay_Log_Space: 552
Until_Condition: None
Until_Log_File:
Until_Log_Pos:
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 8
Выход из строя
При выходе из строя Slave, достаточно просто переключить все приложение на работу с Master. После этого восстановить репликацию на Slave и снова его запустить.
Если выходит из строя Master, нужно переключить все операции (и чтения и записи) на Slave. Таким образом он станет новым Master. После восстановления старого Master, настроить на нем реплику, и он станет новым Slave.
Резервирование
Намного чаще репликацию Master-Slave используют не для масштабирования, а для резервирования. В этом случае, Master сервер обрабатывает все запросы от приложения. Slave сервер работает в пассивном режиме. Но в случае выхода из строя Master, все операции переключаются на Slave.
