Как настроить mysql master-master репликацию?

Введение

Когда-то давно мною была написана статья по настройке репликации в MySQL. Но данный способ имеет один нюанс: данный метод блокирует публичную часть сайта и начинает дропать все таблицы и переносить их заново. Так происходит, потому что репликация в MySQL заранее не настроена, и первичная настройка выполняется через интерфейс битрикса. В общем, есть некоторые неудобства данного способа.

Также я писал про другой метод репликации Master-Slave в MySQL с использованием GTID. И вот теперь можно применить его при настройке репликации MySQL в битрикс, чтобы избежать проблем из первоначальной статьи и всё сделать правильно.

В данной статье будет рассказано о настройке репликации MySQL для Битрикс24 с использованием GTID. Описанные шаги также применимы и к настройке репликации с GTID уже на работающем сервере MySQL.

Используемый форк MySQL – Percona 5.7.30
Конфиг по пути
Директория для MySQL – /mnt/u01/mysql/data

Настроить главный сервер

Первый шаг — настроить главный сервер MySQL. Внесем следующие изменения:

Настройте сервер MySQL на прослушивание частного IP-адреса .
Установите уникальный идентификатор сервера.
Включите двоичное ведение журнала

Для этого откройте файл конфигурации MySQL и раскомментируйте или установите следующее:

master:/etc/mysql/mysql.conf.d/mysqld.cnf

После этого перезапустите службу MySQL, чтобы изменения вступили в силу:

Следующим шагом будет создание нового пользователя репликации. Войдите на сервер MySQL как пользователь root, набрав:

Изнутри командной строки MySQL выполните следующие SQL-запросы, которые создадут пользователя и предоставят пользователю привилегию :

Убедитесь, что вы изменили IP-адрес на свой подчиненный IP-адрес. Вы можете назвать пользователя как хотите.

Находясь в командной строке MySQL, выполните следующую команду, которая выведет двоичное имя файла и позицию.

Обратите внимание на имя файла mysql-bin.000001 и позицию 629. Эти значения понадобятся вам при настройке подчиненного сервера

Эти значения, вероятно, будут другими на вашем сервере.

Задержка репликации

Асинхронность репликации означает, что данные на Slave могут появиться с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Master, чтобы получить актуальные данные:(При обращении к изменяемым данным, необходимо использовать Master-соединение)

<?$master = mysql_connect('10.10.0.1', 'root', 'pwd');$slave = mysql_connect('10.10.0.2', 'root', 'pwd');mysql_query('UPDATE users SET age = 25 WHERE id = 7', $master);$q = mysql_query('SELECT * FROM users WHERE id = 7', $master);# ...$q = mysql_query('SELECT * FROM photos ...', $slave);

Статус репликации

Проверить работу репликации на Слейве можно запросом:

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

Мониторинг

Отдельно стоит упомянуть про мониторинг настроенной реплики. Необходимо взять серверы с Master и Slave под наблюдение, чтобы следить за отставанием, статусом репликации.

На мастер-сервере после настройки репликации команда select * from pg_stat_replication; должна возвращать не пустые значения, а команда SELECT count(*) FROM pg_stat_replication возвращать минимум значение “1”.

На stabdby-сервере можно наблюдать за отставанием относительно мастера, для этого подойдут команды select pg_is_in_recovery(),pg_is_wal_replay_paused(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();. Но высчитывать здесь уже будет сложнее.

Поэтому рекомендую подключить комплексный шаблон мониторинга PostgreSQL через zabbix-agent2 в Zabbix 5+, где все вышеуказанные параметры (и множество других) учтены и позволят быть в курсе всех происходящих событий с базой и репликой.

Настройка Slave

В файл my.cnf вносим измнения:


server-id = 2  - идентификатор slave-сервера должен обязательно отличаться от идентификатора master.                                                                                                                                                                                                                  
relay-log = /var/lib/mysql/mysql-relay-bin    - как и двоичный журнал, состоит из набора пронумерованных файлов, содержащих события, которые описывают изменения в базе данных.                                                             
relay-log-index = /var/lib/mysql/mysql-relay-bin.index -  индексный файл, который содержит имена всех используемых файлов журналов relay.                                                                                                  
replicate-do-db = БД, которая будет реплицироваться.

Важное замечание! При организации cross db (когда используется одна БД, а данные обновляются в другой БД) в настройках мастер-сервера не нужно указывать binlog-do-db, binlog-и должны писаться для всех баз данных, а в настройках slave нужно вместо replicate-do-db указать replicate-wild-do-table=db_name.%, где db_name — имя реплицируемой БД. Перезагружаем mysql-сервер:


/etc/init.d/mysql restart

How to Configure MySQL Master-Slave Replication on Ubuntu 18.04

27 Февраля 2021
|

Ubuntu

Репликация MySQL — это процесс, который позволяет автоматически копировать данные с одного сервера базы данных на один или несколько серверов.

MySQL поддерживает несколько топологий репликации, причем топология «главный / подчиненный» является одной из наиболее известных топологий, в которой один сервер базы данных действует как главный, а один или несколько серверов действуют как подчиненные. По умолчанию репликация является асинхронной, когда ведущее устройство отправляет события, описывающие изменения базы данных, в свой двоичный журнал, а ведомые устройства запрашивают события, когда они готовы.

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

Прежде чем вы приступите

В этом примере предполагается, что у вас есть два сервера под управлением Ubuntu 18.04, которые могут обмениваться данными друг с другом по частной сети. Если ваш хостинг-провайдер не предлагает частные IP-адреса, вы можете использовать общедоступные IP-адреса и настроить брандмауэр, чтобы разрешить трафик на порт 3306 только из надежных источников.

Серверы в этом примере имеют следующие IP-адреса:

Установить MySQL

По умолчанию репозитории Ubuntu 18.04 включают MySQL версии 5.7. Чтобы избежать каких-либо проблем, лучше всего установить одну и ту же версию MySQL на оба сервера.

Установите MySQL на главный сервер:

Установите MySQL на подчиненный сервер, используя те же команды:

Настроить главный сервер

Первый шаг — настроить главный сервер MySQL. Внесем следующие изменения:

Настройте сервер MySQL на прослушивание частного IP-адреса .
Установите уникальный идентификатор сервера.
Включите двоичное ведение журнала

Для этого откройте файл конфигурации MySQL и раскомментируйте или установите следующее:

мастер: /etc/mysql/mysql.conf.d/mysqld.cnf

После этого перезапустите службу MySQL, чтобы изменения вступили в силу:

Изнутри командной строки MySQL выполните следующие SQL-запросы, которые создадут пользователя и предоставят ему привилегию:

Убедитесь, что вы изменили IP-адрес на свой подчиненный IP-адрес. Вы можете назвать пользователя как хотите.

Находясь в командной строке MySQL, выполните следующую команду, которая распечатает двоичное имя файла и позицию.

Эти значения, вероятно, будут другими на вашем сервере.

Настроить подчиненный сервер

Как и в случае с главным сервером выше, мы внесем следующие изменения в подчиненный сервер:

Настройте сервер MySQL для прослушивания частного IP-адреса
Установите уникальный идентификатор сервера
Включите двоичное ведение журнала

Откройте файл конфигурации MySQL и отредактируйте следующие строки:

подчиненный: /etc/mysql/mysql.conf.d/mysqld.cnf

Перезапустите службу MySQL:

Следующим шагом является настройка параметров, которые подчиненный сервер будет использовать для подключения к главному серверу. Войдите в оболочку MySQL:

Сначала остановите подчиненные потоки:

Выполните следующий запрос, который настроит подчиненное устройство для репликации главного устройства:

Убедитесь, что вы используете правильный IP-адрес, имя пользователя и пароль. Имя и позиция файла журнала должны совпадать со значениями, полученными от главного сервера.

После этого запустите подчиненные потоки.

Проверить конфигурацию

На этом этапе у вас должна быть рабочая настройка репликации Master / Slave.

Чтобы убедиться, что все работает должным образом, мы создадим новую базу данных на главном сервере:

Войдите в подчиненную оболочку MySQL:

Выполните следующую команду, чтобы вывести список всех баз данных :

Вы заметите, что база данных, созданная на главном сервере, реплицируется на подчиненный:

В этом руководстве мы показали, как создать репликацию MySQL Master / Slave.

Асинхронность репликации

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.

Задержка в репликации (replication lag) может быть как очень маленькой, так и очень большой. Обычно рост задержки говорит о том, что сервера не справляются с текущей нагрузкой и их необходимо масштабировать дальше, например техниками горизонтального и вертикального шардинга.

Синхронный режим

Синхронный режим репликации позволит гарантировать копирование данных на Слейв.

Это упростит работу в приложении, т.к. все операции чтения можно будет всегда отправлять на Слейв. Однако это может значительно уменьшить скорость работы MySQL. Синхронный режим не следует использовать в Web приложениях.

Траблшутинг

show master status возвращает пустой вывод

Если

SHOW MASTER STATUS;

возвращает пустой результат, проверьте, включены ли бинарные логи:

SHOW BINARY LOGS;

Если на выходе получаем ошибку:

ERROR 1381 (HY000) at line 1: You are not using binary logging

то смотрим информацию ниже.

ERROR 1381 (HY000) at line 1: You are not using binary logging

Ошибка возвращается при запросе статистики по бинарным логам:

SHOW BINARY LOGS;

Не включили бинарные логи

Проверьте корректно ли задали параметр log_bin — важно, чтобы он был определён в секции

Last_IO_Error: error connecting to master…

Если SHOW SLAVE STATUS выводим примерно следующую ошибку:

*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Master_Host: 10.1.0.11
                  Master_User: slave_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 419
               Relay_Log_File: mysql-relay-bin.000005
                Relay_Log_Pos: 529
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Connecting
            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: 419
              Relay_Log_Space: 1281
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 2003
                Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 60  retries: 86400  message: Can't connect to MySQL server on '10.1.0.11' (113)
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 11

то у slave-сервера отсутствует возможность соединения с master-сервером. Причины:

некорректные авторизационные данные пользователя репликации;
закрыт порт MySQL для исходящих соединений на slave-сервере;
закрыт порт MySQL для входящих соединений на master-сервере.

Проверяем соединение:

$ telnet 10.1.0.11 3306
Trying 10.1.0.11...
telnet: connect to address 10.1.0.11: No route to host

Добавим правило на slave-сервере

iptables -I OUTPUT -p tcp -m tcp --dport 3306 -j ACCEPT

Добавим правило на master-сервере:

iptables -I INPUT -p tcp -m tcp --dport 3306 -j ACCEPT

Проверим возможность соединения:

$ telnet 10.1.0.11 3306
Trying 10.1.0.11...
Connected to 10.1.0.11.
Escape character is '^]'.
V
5.5.47-MariaDB-log
                  0P$_6/&�}K;%Gt7Po\aQmysql_native_password

Подготовка Master-сервера

В конфигурационном файле MySQL необходимо изменить следующие параметры в зависимости от доступной оперативной памяти и физического размещения MySQL на сервере:

datadir – путь, где физически располагаются файлы MySQL. В данной инструкции предполагается, что это директория /mnt/u01/mysql/data
socket – путь до сокета для консольного клиента, в той же директории /mnt/u01/mysql/data
innodb_buffer_pool_size – требует тонкой настройки, для начала можно выставить в 50% от свободной оперативной памяти (значение в 4096М или 4G – мегабайты или гигабайты соответственно).
server-id – в зависимости от роли Master или Slave
innodb_strict_mode=0 – данный параметр нужно указать явно в конфиге

Прочие параметры можно оставить по умолчанию, они подлежат корректировке в случае необходимости.

Проверьте конфигурацию

На этом этапе у вас должна быть работающая настройка репликации Master/Slave.

Чтобы убедиться, что все работает должным образом, мы создадим новую базу данных на главном сервере:

sudo mysql

CREATE DATABASE replicatest;

Войдите в подчиненную оболочку MySQL:

sudo mysql

Список баз данных:

SHOW DATABASES;

Вы заметите, что база данных, которую вы создали на главном сервере, реплицируется на ведомое устройство:

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| replicatest        |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

Как это работает

Slave-сервер с определённой периодичностью будет опрашивать master-сервер на предмет изменений в базе. Таким образом все изменения в master-сервере будут повторяться на slave-сервере. Таким образом создаётся избыточность данных на двух серверах и тем самым достигается высокая доступность и надёжность данных. Важным преимуществом между “холодным копированием” заключается в том, что мы переносим по сети только изменения, а не все данные каждый раз. Тем более не стоит забывать что во время создания backup`а мы нагружаем наш master-сервер. Здесь же всё иначе, master-сервер все изменения в базе пишет в “бинарный журнальный лог”, присваивая каждой операции номер. Когда slave-сервер обращается к нашему главному серверу, то он сообщает номер последней операции, которую он уже произвёл у себя и получает все новые изменения отсчитывая от этого номера.

Асинхронность репликации

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Slave.

Синхронный режим

Синхронный режим репликации позволит гарантировать копирование данных на Slave.

Это упростит работу в приложении, т.к. все операции чтения можно будет всегда отправлять на Slave. Однако это может значительно уменьшить скорость работы MySQL. Синхронный режим не следует использовать в Web приложениях.

Шаг 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)

Репликация MySQL в виде Master/Slave

В данной статье предполагается наличие пользователя с привилегиями sudo, а также уже установленной системы MySQL. Чтобы установить MySQL, наберите:

Если используете deb’s ОС (Debian/Ubuntu):

Если используете rpm ОС (CentOS/Fedora/RedHat):

Вот некоторые полезные статьи:

Настройка безопасности MYSQL в Unix/Linux

Сменить кодировку в Mysql/MariaDB в Unix/Linux

Сколько MySQL соединений в Unix/Linux

Проверить тип баз данных MySQL для хранения данных в Linux

Тюнинг MySQL в Unix/Linux

Просмотр привилегий пользователя MySQL

Настройка Master

Открываем конфигурационный файл на master-сервере:

Сейчас я его немного видоизменю и для самого начала заменим ИП адрес который слушает mysql (он связывает сервер с локальным хостом):

Замените стандартный IP-адрес IP-адресом сервера.

PS: если он не прописан, то добавьте строку что выше себе в конфигурационный файл.

Идем далее, нужно прописать директиву «server-id»:

Она может принимать любое значение, но как по мне — проще начинать с 1. Данная величина должна быть уникальной и не совпадать ни с одним из другим «server-id» в этой группе репликации.

Находим» log_bin» — эта переменная будет нести в себе некоторые детали о самой репликации ( сервер slave будет копировать все изменения, зарегистрированные в указанном лог файле):

PS: Возможно, у вас не хватит прав на запись этого файла в указанной директории, по этому, измените путь или добавьте запись на папку.

И напоследок, стоит задать БД, которую необходимо будет копировать на slave-сервер( допускается добавлять более 1 БД, но для этого стоит прописывать данную строку, но с нужно базой), напимер:

И так, все было сделано и мой конфиг выглядит следующим образом:

Перезапускаем master с MySQL:

После перезапуска, нужно подключиться к самой оболочке MySQL:

Создаем пользователя, который будет передавать данные с мастера на слейв:

Сбросим все привелегии (чтобы все заработало):

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

И так, у нас настроен сервер с мастером и уже работает некоторая БД (у меня это magento_db), выберем ее для использования:

Поле чего, я заблокирую данную базу для того, чтобы не записывались никакие данные в нее:

выполняем проверку :

И видим, что мастер уже заработал:

Т.к я заблокировал все изменения, то не будет записываться ничего в эту БД и я могу создать дамп этой БД для переноса ее на слейв. Я выполню экспорт БД с помощью mysqldump:

После того как создался дам, нужно вернуть все на свои места и разблокировать БД:

Вуоля, master готов к использованию!

Настройка slave

Подключаемся на созданный slave сервер и создаем БД:

Выполняем импорт базы которую мы создали с мастера:

Открываем конфигурационный файл и внесем некоторые изменения:

Тоже прописываем ID сервера (значение должно быть не такое как у мастера):

И прописываем следующие значения:

Выполняем перезапуск MySQL со слейвом:

Осталось активировать репликацию в MySQL. Открываем оболочку MySQL и вводим:

Пояснения данной команды:

Запускаем slave-сервер следующей командой:

Проверяем что слейв запустился и работает должным образом:

Иногда возникают проблемы со связью и их можно решить:

Вот некоторые полезные статьи:

Duplicate entry/Error_code: 1062 в MySQL репликации (Master-Slave)

Перезапуск MySQL репликации

А на этом, у меня все и тема «Репликация MySQL в виде Master/Slave» завершена.

Настройка репликации MySQL

В этой инструкции мы будем использовать для примера Ubuntu 16.04 и MariaDB версии 10.1. Перед тем, как начать полностью обновите систему:

Поскольку мы будем развертывать нашу конфигурацию на нескольких узлах, нужно выполнить операции обновления на всех них. Если сервер баз данных MariaDB еще не установлен, его нужно установить. Сначала добавьте репозиторий и его ключ:

Когда обновление списка пакетов завершено, установите MariaDB командой:

Пакет rsync нам понадобится для выполнения непосредственно синхронизации. Когда установка будет завершена, вам необходимо защитить базу данных с помощью скрипта mysql_secure_installation:

По умолчанию разрешен гостевой вход, есть тестовая база данных, а для пользователя root не задан пароль. Все это надо исправить. Читайте подробнее в статье установка MariaDB в Ubuntu. Если кратко, то вам нужно будет ответить на несколько вопросов:

Когда все будет готово, можно переходить к настройке нод, между которыми будет выполняться репликация баз данных mysql. Сначала рассмотрим настройку первой ноды. Можно поместить все настройки в my.cnf, но лучше будет создать отдельный файл для этих целей в папке /etc/mysql/conf.d/.

Добавьте такие строки:

Здесь адрес 192.168.56.101 — это адрес текущей ноды. Дальше перейдите на другой сервер и создайте там такой же файл:

Аналогично тут адрес ноды — 192.168.0.103. Остановимся на примере с двумя серверами, так как этого достаточно чтобы продемонстрировать работу системы, а добавить еще один сервер вы можете, прописав дополнительный IP адрес в поле wsrep_cluster_address. Теперь рассмотрим что означают значения основных параметров и перейдем к запуску:

binlog_format — формат лога, в котором будут сохраняться запросы, значение row сообщает, что там будут храниться двоичные данные;
default-storage-engine — движок SQL таблиц, который мы будем использовать;
innodb_autoinc_lock_mode — режим работы генератора значений AUTO_INCREMENT;
bind-address — ip адрес, на котором программа будет слушать соединения, в нашем случае все ip адреса;
wsrep_on — включает репликацию;
wsrep_provider — библиотека, с помощью которой будет выполняться репликация;
wsrep_cluster_name — имя кластера, должно соответствовать на всех нодах;
wsrep_cluster_address — список адресов серверов, между которыми будет выполняться репликация баз данных mysql, через запятую;
wsrep_sst_method — транспорт, который будет использоваться для передачи данных;
wsrep_node_address — ip адрес текущей ноды;
wsrep_node_name — имя текущей ноды.

Настройка репликации MySQL почти завершена. Остался последний штрих перед запуском — это настройка брандмауэра. Сначала включите инструмент управления правилами iptables в Ubuntu — UFW:

Затем откройте такие порты:

Настройка репликации

Подразумевается, что уже запущено два инстанса PostgreSQL для выполнения дальнейшей работы.

На master-сервере необходимо создать пользователя, от имени которого будет реплицироваться БД, предоставить ему права для подключения и перечитать конфиг:

На сервере slave должна быть установлена утилита pg_basebackup также версии 12+ и подготовлена пустая директория, куда будет размещена копия с мастера:

На slave-сервере перед дальнейшим продолжением необходимо остановить PostgreSQL!

Теперь допустимо выполнить копирование файлов с мастера на слейв:

-R — будет создан автоматически файл standby.signal и заполнен файл postgresql.auto.conf с информацией о подключении к мастеру-P — примерный прогресс-барЕсть также ключ -Xs, используется дефолтом, но для понимания нужно знать, что в таком случае открывается 2 соединения до мастера – в одном идёт копирование файлов, а во втором – копирование журналов предзаписи (внимание на параметр max_wal_senders мастера), в которых накапливаются изменения, пока копируются основные файлы. И по окончании вся информация из журналов будет прочитана и применена

Таким образом все изменения в процессе копирования будут учтены и на слейве будет получена полностью самодостаточная резервная копия.Другие ключи для pg_basebackup не требуются, если нет никаких особенностей.

На этом всё, копирование через basebackup выполняется достаточно быстро, а также не мешает работе мастера. Слейв можно запускать и проверять логи, в которых не должно фигурировать ошибок.

Настройте главный сервер

Сначала мы настроим главный сервер MySQL и внесем следующие изменения:

Настройте сервер MySQL для прослушивания частного IP .
Установите уникальный идентификатор сервера.
Включите двоичное ведение журнала.

Для этого откройте файл конфигурации MySQL и добавьте в раздел следующие строки :

Master: /etc/my.cnf

После этого перезапустите службу MySQL, чтобы изменения вступили в силу.

Следующим шагом является создание нового пользователя репликации. Войдите на сервер MySQL от имени пользователя root:

В командной строке MySQL выполните следующие SQL-запросы, которые создадут пользователя и предоставят пользователю привилегию:

Убедитесь, что вы изменили IP-адрес с вашего ведомого IP-адреса. Вы можете назвать пользователя, как вы хотите.

Находясь в приглашении MySQL, выполните следующую команду, которая выведет двоичное имя файла и положение.

Обратите внимание на имя файла «mysql-bin.000001» и «1427». Эти значения понадобятся вам при настройке подчиненного сервера

Эти значения, вероятно, будут отличаться на вашем сервере.

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-bin.000001 и позицию 328. Эти значения необходимы при настройке подчиненного сервера и, вероятно, будут другими на вашем сервере.

Настройка подчиненного сервера

Мы внесем те же изменения на подчиненном сервере, что и на главном:

Настройте сервер MySQL на прослушивание частного IP-адреса.
Установите уникальный идентификатор сервера.
Включите двоичное ведение журнала.

Откройте файл конфигурации MariaDB и отредактируйте следующие строки:

подчиненный: /etc/mysql/mariadb.conf.d/50-server.cnf

Перезапустите службу MariaDB:

Следующим шагом является настройка параметров, которые подчиненный сервер будет использовать для подключения к главному серверу. Войдите в оболочку MariaDB:

Начните с остановки подчиненных потоков:

Выполните следующий запрос, чтобы настроить репликацию Master / Slave:

После этого запустите подчиненные потоки.