Home » Как настроить репликацию master-master в MySQL

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

В этой статье разберёмся, как настроить репликацию master-master в MySQL — без воды, с примерами, граблями и лайфхаками. Если ты когда-нибудь сталкивался с задачей обеспечить отказоустойчивость или масштабирование MySQL, то наверняка слышал про репликацию. Но вот как сделать так, чтобы оба сервера были равноправными, а не один главный и второй ведомый? Именно об этом и пойдёт речь. Разберёмся, как это работает, зачем это нужно, как быстро всё поднять, и на что наступают новички (и не только). Всё — на практике, с командами и схемами. Погнали!

Как это работает? — Краткая теория и архитектура

В классической схеме MySQL-репликации есть master (главный) и slave (ведомый). Все изменения идут на master, а slave просто послушно копирует их себе. Но что, если хочется, чтобы оба сервера были равноправными? Например, для балансировки нагрузки или отказоустойчивости? Тут и появляется master-master репликация (её ещё называют active-active).

Оба сервера одновременно принимают записи и изменения.
Каждый сервер является и master, и slave для другого.
Изменения с одного сервера реплицируются на второй, и наоборот.
В идеале — пользователи могут писать на любой сервер, а данные всегда синхронизированы.

Выглядит заманчиво, но есть нюансы. Главный — конфликты: если два пользователя одновременно изменят одну и ту же строку на разных серверах, кто победит? MySQL не волшебник, и тут нужно быть аккуратным.

Зачем это нужно и когда использовать?

Отказоустойчивость: если один сервер падает, второй продолжает работать.
Балансировка нагрузки: можно распределять запросы на запись между двумя серверами (но тут осторожно — см. ниже).
Горизонтальное масштабирование: удобно для геораспределённых проектов, когда сервера стоят в разных дата-центрах.
Обновления без простоя: можно обновлять один сервер, пока второй обслуживает пользователей.

Но! Не стоит думать, что master-master — это серебряная пуля. Есть подводные камни: конфликты, задержки репликации, сложность поддержки. Иногда лучше использовать классическую master-slave схему или современные решения типа Galera Cluster (о них ниже).

Как быстро и просто всё настроить? — Пошаговая инструкция

Переходим к самому вкусному — практике. Для примера возьмём два сервера: mysql1 (IP: 10.0.0.1) и mysql2 (IP: 10.0.0.2). Оба — свежие MySQL 8.x, но инструкция подойдёт и для 5.7.

Настройка уникальных server-id
В my.cnf на каждом сервере пропиши уникальный server-id:
[mysqld] server-id = 1 # на первом сервере log_bin = mysql-bin binlog_format = ROW auto_increment_increment = 2 auto_increment_offset = 1
[mysqld] server-id = 2 # на втором сервере log_bin = mysql-bin binlog_format = ROW auto_increment_increment = 2 auto_increment_offset = 2
- auto_increment_increment и auto_increment_offset нужны, чтобы избежать конфликтов auto_increment (например, id-шников).
- Перезапусти MySQL после изменений.
Создай репликационного пользователя
На каждом сервере:
CREATE USER 'repl'@'10.0.0.%' IDENTIFIED BY 'supersecret'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.%'; FLUSH PRIVILEGES;
Проверь статус binlog
SHOW MASTER STATUS;
Запомни File и Position на обоих серверах.
Настрой репликацию на каждом сервере
На mysql1 (чтобы он был slave для mysql2):
CHANGE MASTER TO MASTER_HOST='10.0.0.2', MASTER_USER='repl', MASTER_PASSWORD='supersecret', MASTER_LOG_FILE='mysql-bin.000001', -- укажи актуальный файл с mysql2 MASTER_LOG_POS=154; -- и позицию с mysql2
START SLAVE;
На mysql2 (чтобы он был slave для mysql1):
CHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='repl', MASTER_PASSWORD='supersecret', MASTER_LOG_FILE='mysql-bin.000001', -- актуальный файл с mysql1 MASTER_LOG_POS=154; -- и позицию с mysql1
START SLAVE;
- Проверь статус: SHOW SLAVE STATUS\G
- Оба сервера должны быть и master, и slave одновременно.
Проверь репликацию
Создай тестовую таблицу на одном сервере, проверь, что она появилась на втором.
CREATE DATABASE testdb; USE testdb; CREATE TABLE t1 (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50)); INSERT INTO t1 (name) VALUES ('hello from master1');
Проверь на втором сервере:
SELECT * FROM testdb.t1;

Всё! Теперь у тебя два равноправных MySQL-сервера, которые синхронизируют изменения друг с другом.

Практические советы, схемы и грабли

Избегай одновременной записи в одну и ту же таблицу с разных серверов
Это главный источник конфликтов. Если можешь — раздели зоны ответственности (например, разные базы или таблицы).
Следи за auto_increment
Если не настроить auto_increment_increment и auto_increment_offset, будут дубли id-шников.
Мониторь задержки репликации
SHOW SLAVE STATUS\G — смотри на Seconds_Behind_Master. Если там не 0 — ищи причину.
Не используй master-master для write-heavy нагрузок
Если у тебя тысячи одновременных записей — лучше смотри в сторону Galera Cluster или Percona XtraDB Cluster.
Бэкапы только с одного сервера
Не делай mysqldump одновременно на обоих — могут быть рассинхроны.

Таблица: сравнение master-master и master-slave

Параметр	Master-Master	Master-Slave
Отказоустойчивость	Высокая	Средняя (только чтение на slave)
Балансировка записи	Возможна, но риск конфликтов	Нет
Балансировка чтения	Да	Да
Сложность настройки	Средняя/Высокая	Низкая
Риск конфликтов	Есть	Нет
Поддержка в MySQL	Официально не рекомендуется	Официально поддерживается

Положительные и отрицательные кейсы

Положительный: интернет-магазин с двумя дата-центрами (Москва и Новосибирск). Один сервер обслуживает запад, второй — восток. Записи по географии разделены, конфликтов нет. При падении одного — второй продолжает работу.
Отрицательный: SaaS-платформа, где пользователи могут менять одни и те же данные с разных регионов. Одновременные изменения приводят к конфликтам, часть данных теряется, приходится вручную разруливать.

Альтернативы и похожие решения

Galera Cluster — синхронная мульти-мастер репликация, нет конфликтов, все ноды равноправны. galeracluster.com
Percona XtraDB Cluster — форк Galera, с улучшениями для MySQL. percona.com
MySQL Group Replication — встроенное решение для кластеризации, но требует MySQL 5.7+ и специфической настройки. dev.mysql.com
ProxySQL, MaxScale — прокси для балансировки запросов между несколькими MySQL-серверами.

Статистика и сравнение с другими решениями

По данным db-engines.com, MySQL — самый популярный open-source СУБД, но для кластеризации чаще используют Galera или Percona XtraDB Cluster.
В крупных проектах (>1000 QPS) master-master используют редко — чаще выбирают синхронные кластеры.
Для небольших и средних нагрузок (до 100 QPS) master-master — рабочий вариант, если грамотно разделить зоны записи.

Интересные факты и нестандартные применения

Можно использовать master-master для миграции между дата-центрами: поднял второй сервер, синхронизировал, переключил трафик — и миграция без простоя.
Некоторые используют master-master для “горячих” бэкапов: один сервер всегда в резерве, можно быстро переключиться.
В связке с ProxySQL можно динамически балансировать нагрузку между двумя мастерами, но только для чтения или с разделением зон записи.

Автоматизация и скрипты — что нового открывается?

Можно автоматизировать failover: если один сервер падает, скрипт автоматически переключает приложение на второй.
Скрипты мониторинга (например, zabbix, prometheus) легко интегрируются — достаточно следить за статусом репликации на обоих серверах.
Возможность обновлять MySQL без простоя: обновляешь один сервер, второй продолжает обслуживать пользователей.
Можно писать свои утилиты для автоматического разрешения конфликтов (например, если знаешь, что записи не пересекаются).

Выводы и рекомендации

Master-master репликация в MySQL — мощный инструмент для отказоустойчивости и масштабирования, если использовать его с умом. Это не серебряная пуля, но для небольших и средних проектов, где можно разделить зоны записи, — отличный вариант. Для write-heavy нагрузок или если нужна настоящая синхронность — смотри в сторону Galera или Percona XtraDB Cluster.

Главные советы:

Настраивай уникальные server-id и auto_increment параметры.
Не пиши в одну и ту же таблицу с разных серверов одновременно.
Мониторь статус репликации и делай бэкапы только с одного сервера.
Для автоматизации используй скрипты failover и мониторинга.

Если нужен VPS для тестов или продакшена — заказать VPS. Для серьёзных задач — выделенный сервер.

Официальная документация MySQL по репликации: dev.mysql.com

Пробуй, экспериментируй, автоматизируй — и пусть твои базы всегда будут доступны и быстры!

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

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