MySQL multi-master на Oracle Linux

Важно: пример использует две машины с IP 192.168.43.11 (DB1) и 192.168.43.12 (DB2). Перед началом убедитесь, что между серверами есть сеть и права root для установки пакетов.

Введение и назначение

MySQL — зрелая СУБД, подходящая для использования в производстве. Репликация помогает обеспечить отказоустойчивость и распределение нагрузки. Обычная асинхронная репликация улучшает чтение, но не запись. Multi-master репликация позволяет реплицировать изменения, включая записи и DDL, между двумя мастерами, тем самым повышая доступность и позволяя писать на любую ноду.

Краткое описание структуры: мы настроим две ноды (DB1 и DB2), каждая будет одновременно мастером и слейвом для другой. В результате DDL и DML команды будут применяться на обеих серверах.

Требования и предпосылки

Две машины с Oracle Linux 6.8 (в примере 32-бит). Аналогичные шаги применимы к CentOS / RHEL.
Доступ root на обеих машинах.
Открытый порт 3306 между серверами.
Примеры IP: 192.168.43.11 (DB1) и 192.168.43.12 (DB2).

Определения в одну строку:

DDL: операции определения структуры (CREATE TABLE, ALTER и т. п.).
DML: операции изменения данных (INSERT, UPDATE, DELETE и т. п.).

1. Подготовка серверов (Preliminary Note)

В примере используется Oracle Linux Server release 6.8, 32-bit. На каждой машине выполните команды проверки ОС и конфигурации сети. Примеры вывода показаны ниже — оставьте их без изменений, они демонстрируют ожидаемый результат.

[root@DB1 ~]# lsb_release -a
LSB Version: :base-4.0-ia32:base-4.0-noarch:core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: OracleServer
Description: Oracle Linux Server release 6.8
Release: 6.8
Codename: n/a

[root@DB1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:42:C0:4C
inet addr:192.168.43.11 Bcast:192.168.43.255 Mask:255.255.255.0
...

Сделайте то же самое на DB2 и проверьте IP 192.168.43.12.

Далее добавьте записи в /etc/hosts на обеих нодах:

[root@DB1 ~]# vi /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.43.11 DB1
192.168.43.12 DB2

2. Установка MySQL (Installation Phase)

Добавим репозиторий MySQL и установим сервер и клиент через yum на обеих нодах.

[root@DB1 ~]# cd /etc/yum.repos.d/
[root@DB1 yum.repos.d]# wget http://repo.mysql.com/mysql-community-release-el6-5.noarch.rpm
[root@DB1 yum.repos.d]# rpm -Uvh mysql-community-release-el6-5.noarch.rpm

Затем включите репозиторий для MySQL 5.6, отредактировав mysql-community.repo (пример ниже):

[root@DB1 yum.repos.d]# vi mysql-community.repo
# Enable to use MySQL 5.6
[mysql56-community]
name=MySQL 5.6 Community Server
baseurl=http://repo.mysql.com/yum/mysql-5.6-community/el/6/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:/etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

Проверяем наличие пакета и устанавливаем:

[root@DB1 yum.repos.d]# rpm -qa|grep -i mysql
[root@DB1 yum.repos.d]# yum install mysql-server mysql-client

Пример вывода установки приведён в исходном материале — внимательно следите за зависимостями и подтверждайте установку.

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

[root@DB1 yum.repos.d]# service mysqld restart

В конце инициализации сервер подскажет установить пароль для root. Сделаем это и проверим подключение:

[root@DB1 yum.repos.d]# mysqladmin -u root password "Pass1234"
[root@DB1 yum.repos.d]# mysql -u root -p
Enter password:
mysql> select user();

Важно: использование пароля в командной строке небезопасно — по возможности используйте mysql_secure_installation или переменные окружения.

3. Конфигурация multi-master (Configuration Phase)

На обеих нодах нам нужно отредактировать /etc/my.cnf и присвоить уникальный server-id, включить бинарный лог и указать реплицируемую базу.

Пример для DB1 (server-id = 11):

[root@DB1 ~]# vi /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
port=3306
innodb_file_per_table=ON
pid-file=/var/lib/mysql/mysqld.pid

server-id = 11
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = test_rep

Пояснение параметров:

server-id — уникальный идентификатор репликации для узла.
log_bin — файл бинарного лога, необходимый для репликации.
binlog_do_db — список баз, которые участвуют в репликации (в примере test_rep).

Создадим базу и учётную запись репликации на DB1:

[root@DB1 ~]# mysql -u root -p
mysql> create database test_rep;
mysql> create user 'replicator'@'DB2' identified by 'Rep1234';
mysql> grant replication slave on *.* to 'replicator'@'DB2';

Перезапустите MySQL, затем получите статус мастера, чтобы узнать текущий файл и позицию binlog:

mysql> show master status;

Повторите аналогичные шаги на DB2, но с server-id = 12 и с созданием пользователя ‘replicator’@’DB1’. Пример /etc/my.cnf для DB2:

[root@DB2 ~]# vi /etc/my.cnf
[mysqld]
... (те же основные настройки)
server-id = 12
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = test_rep

В DB2 создайте базу и пользователя:

[root@DB2 ~]# mysql -u root -p
mysql> create database test_rep;
mysql> create user 'replicator'@'DB1' identified by 'Rep1234';
mysql> grant replication slave on *.* to 'replicator'@'DB1';

4. Настройка мастера/слейва в обе стороны

На DB2 укажите в мастере параметры подключения к DB1 и запустите слейв-процессы:

mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_HOST = 'DB1', MASTER_PORT = 3306, MASTER_USER = 'replicator', MASTER_PASSWORD = 'Rep1234', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 854;
mysql> start slave;
mysql> show slave status\G

В ответ вы должны увидеть Slave_IO_Running: Yes и Slave_SQL_Running: Yes.

На DB1 аналогично укажите DB2 как мастер и запустите слейв:

mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_HOST = 'DB2', MASTER_PORT = 3306, MASTER_USER = 'replicator', MASTER_PASSWORD = 'Rep1234', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 553;
mysql> start slave;
mysql> show slave status\G

Если оба слейва работают, репликация в режиме multi-master установлена.

5. Тестирование репликации (Testing Phase)

План теста: создать таблицу на DB1, проверить её появление на DB2; затем вставить строки на DB2 и убедиться, что они видны на DB1. Пример сессии:

На DB1:

[root@DB1 ~]# mysql -u root -p test_rep
mysql> create table tbl1( id int(11) primary key auto_increment, fullname varchar(30));
mysql> show tables in test_rep;

На DB2 ожидаем появления таблицы tbl1, затем вставляем несколько строк и проверяем обе ноды:

[root@DB2 ~]# mysql -u root -p test_rep
mysql> insert into tbl1 ( fullname ) values ('Shahril'), ('mark'), ('Allen'), ('Suzy'), ('Adam');
mysql> select * from tbl1;

Потом вернитесь на DB1 и выполните select и delete, чтобы проверить двунаправленную репликацию:

[root@DB1 ~]# mysql -u root -p test_rep
mysql> select * from tbl1;
mysql> delete from tbl1 where fullname like 'A%';
mysql> select * from tbl1;

Если на обеих нодах видны одни и те же изменения — тест пройден.

Когда multi-master не подходит

Высокая вероятность конфликтов при параллельных обновлениях одной и той же строки на разных узлах.
Сценарии с интенсивными транзакциями и сложной согласованностью лучше решать через шардинг или специализированные кластеры.
Если приложение не терпит небольших задержек репликации — отдайте предпочтение синхронным/полу-синхронным решениям (Galera, Group Replication).

Альтернативные подходы

Galera Cluster (synchronous multi-master) — защищает от конфликтов и обеспечивает согласованность, но требует совместимых версий и дополнительных требований к сети.
MySQL Group Replication — встроенное решение для современных версий MySQL.
Асинхронный мастер-слейв + ProxySQL/HAProxy для распределения чтения и записи.

Модель принятия решений — когда выбрать multi-master

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

Плейбук развёртывания (шаги)

Подготовить ОС и сеть между узлами.
Добавить записи в /etc/hosts.
Установить репозиторий MySQL и пакеты на обе ноды.
Инициализировать MySQL, задать пароль root.
Отредактировать /etc/my.cnf: уникальный server-id, log_bin, binlog_do_db.
Создать реплицируемую базу и пользователя replicator на каждой ноде.
Получить show master status и выполнить CHANGE MASTER TO … на противоположной ноде.
Запустить start slave; проверить show slave status.
Выполнить тесты DDL и DML.
Настроить мониторинг и бэкапы.

Критерии приёмки

Оба слейва показывают Slave_IO_Running: Yes и Slave_SQL_Running: Yes.
DDL, выполненный на одной ноде, появляется на второй.
DML, выполненный на одной ноде, появляется на второй.
Нет критичных ошибок в логах mysql (grep ERR/ERROR).

План восстановления и отката (Runbook)

Если слейв упал: проверить сетевое соединение, учетные данные replicator, и позицию binlog.
В случае рассинхронизации: остановить слейв, сделать дамп одной ноды, восстановить на второй и заново настроить CHANGE MASTER TO с актуальной позицией.
Для критического конфликта данных: остановить записи на всех нодах, провести ручную сверку и восстановление из бэкапа.

Тестовые сценарии и контрольные проверки

Тест 1: Создать таблицу на DB1 — она должна появиться на DB2.
Тест 2: Вставить 100 строк на DB2 — они должны появиться на DB1.
Тест 3: Выполнить одновременные обновления одной строки на обеих нодах — проверить, какой результат закрепился и как обрабатывается конфликт.
Критерии успеха: согласованное состояние или воспроизводимый конфликт-процесс.

Безопасность и рекомендации по жёсткой конфигурации

Используйте TLS для репликации (MASTERSSL* параметры) на продакшене.
Ограничьте доступ для пользователя replicator по IP и минимизируйте привилегии.
Включите аудит и логирование операций, особенно DDL.
Регулярно проверяйте и обновляйте версии MySQL; для продакшена рассмотрите более новые релизы и поддерживаемые решения.

Риски и способы снижения

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

Миграция и совместимость

Multi-master на MySQL 5.6 применим, но современные production-системы чаще используют Galera или Group Replication.
При обновлении версии MySQL протестируйте совместимость бинарных логов и формат InnoDB.

Короткая памятка и Cheat sheet

Файлы: /etc/my.cnf, /var/log/mysql/mysql-bin.log
Основные команды: service mysqld restart; mysql -u root -p; show master status; show slave status\G; CHANGE MASTER TO …; start slave; stop slave.

Однострочный словарь

master: узел, источник бинарного лога; slave: узел, применяющий события из бинарного лога.

Пример приветственного сообщения для соцсетей

OG title: MySQL multi-master репликация на Oracle Linux OG description: Пошаговое руководство по установке и тестированию двунаправленной MySQL репликации между двумя серверами.

Краткое объявление (100–200 слов)

Настроили двухузловую MySQL multi-master репликацию на Oracle Linux 6.8. Руководство проходит через установку пакетов, настройку /etc/my.cnf с уникальными server-id, создание пользователей репликации и двунаправленную привязку мастера/слейва. В конце мы проверяем DDL и DML операции, чтобы подтвердить корректность репликации. Публикация полезна админам и инженерам, которым нужно обеспечить запись и чтение на любой ноде, с акцентом на практические команды и проверочные тесты.

Резюме: Multi-master репликация на MySQL возможна и полезна в ряде сценариев, но требует внимательного подхода к конфликтам, безопасности и мониторингу. Используйте данное руководство как основу и адаптируйте его под конкретные требования окружения.

Настройка MySQL multi-master репликации на Oracle Linux