Master-master репликация

Master-master репликация — это схема репликации баз данных, при которой два или более сервера (узла) одновременно выступают в роли как ведущих (master), так и ведомых (slave) по отношению друг к другу. В отличие от классической master-slave архитектуры, где запись разрешена только на одном узле, в master-master конфигурации каждый сервер может принимать запросы на запись и чтение, а также синхронизировать изменения с другими узлами. Данная схема обеспечивает повышенную отказоустойчивость и распределение нагрузки на запись, но требует тщательного управления конфликтами данных.

История

Концепция master-master репликации возникла в конце 1990-х — начале 2000-х годов как развитие идей распределённых систем управления базами данных (СУБД). Первые реализации появились в коммерческих продуктах, таких как Oracle Advanced Replication (с поддержкой multi-master) и IBM DB2. В открытом программном обеспечении одной из первых систем, реализовавших master-master репликацию, стала MySQL, начиная с версии 3.23 (2001 год) через механизм репликации на основе бинарного лога. Однако ранние реализации MySQL требовали ручного разрешения конфликтов. В 2010-х годах с развитием NoSQL-баз данных (например, Cassandra, Riak) и распределённых SQL-решений (Galera Cluster для MySQL/MariaDB) master-master репликация стала более зрелой и автоматизированной.

Принцип работы

В master-master репликации каждый узел хранит полную копию данных. Изменения, внесённые на одном узле, передаются на другие узлы через протокол репликации. Основные этапы:

1. Запись на узле A: приложение выполняет операцию INSERT, UPDATE или DELETE на сервере A.
2. Логирование изменений: сервер A записывает изменения в свой бинарный лог (binary log) или журнал транзакций.
3. Передача изменений: сервер A отправляет записи из лога на сервер B (и другие узлы) через сетевой протокол (например, TCP/IP).
4. Применение изменений на узле B: сервер B получает записи и применяет их к своей локальной базе данных, повторяя те же операции.
5. Обратная синхронизация: аналогичный процесс происходит при записи на сервер B — изменения передаются на сервер A.

Для корректной работы необходимо, чтобы все узлы были настроены на взаимную репликацию. В простейшей конфигурации с двумя серверами каждый из них выступает как master для другого и как slave для себя.

Виды и реализации

Синхронная и асинхронная репликация

• Синхронная: транзакция считается завершённой только после подтверждения записи на всех узлах. Обеспечивает строгую согласованность данных, но увеличивает задержки и снижает производительность. Пример: Galera Cluster (синхронная multi-master репликация для MySQL/MariaDB).
• Асинхронная: транзакция завершается сразу после записи на локальном узле, а изменения распространяются на другие узлы с задержкой. Увеличивает производительность, но может приводить к временным расхождениям данных. Пример: стандартная master-master репликация MySQL.

По типу СУБД

• Реляционные СУБД: MySQL, MariaDB (с поддержкой Galera Cluster), PostgreSQL (через расширения, например, BDR — Bi-Directional Replication), Oracle (с опцией Advanced Replication).
• NoSQL-базы данных: Apache Cassandra (multi-master по умолчанию), Riak, CouchDB (с поддержкой multi-master через репликацию).

Преимущества и недостатки

Преимущества

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

Недостатки

• Конфликты данных: при одновременной записи на разных узлах могут возникать конфликты (например, изменение одной и той же строки). Разрешение конфликтов требует либо ручного вмешательства, либо автоматических механизмов (например, «последняя запись побеждает» — last-write-wins).
• Сложность настройки и обслуживания: требуется тщательная настройка сетевого соединения, мониторинг задержек репликации и управление версиями схемы базы данных.
• Проблемы с согласованностью: при асинхронной репликации возможны временные расхождения данных, что может быть критично для некоторых приложений (например, банковских систем).
• Увеличение нагрузки на сеть: каждый узел передаёт изменения на другие узлы, что может создавать дополнительный трафик.

Применение

Master-master репликация используется в системах, где требуется высокая доступность и распределение нагрузки на запись:

• Веб-приложения и CMS: системы управления контентом (например, WordPress с поддержкой multi-master через плагины) для обеспечения непрерывной работы при высоких нагрузках.
• Электронная коммерция: интернет-магазины, где одновременная запись заказов и обновление каталогов происходит на нескольких серверах.
• Системы реального времени: чаты, онлайн-игры, системы мониторинга, где важна отказоустойчивость.
• Геораспределённые системы: сервисы, работающие в нескольких дата-центрах (например, облачные платформы, CDN).

Примеры конфигураций

MySQL с Galera Cluster

Galera Cluster — это синхронная multi-master реализация для MySQL и MariaDB. Она обеспечивает автоматическое разрешение конфликтов на уровне транзакций и поддерживает до 32 узлов. Конфигурация требует установки расширения Galera и настройки параметров, таких как wsrep_cluster_address (список узлов) и wsrep_sync_wait (уровень синхронизации).

PostgreSQL с BDR

BDR (Bi-Directional Replication) — расширение для PostgreSQL, позволяющее организовать multi-master репликацию. Оно использует асинхронный протокол и поддерживает разрешение конфликтов на основе правил, задаваемых администратором. BDR требует установки отдельного пакета и настройки параметров, таких как bdr.node_id и bdr.connections.

Критика

Основная критика master-master репликации связана с проблемами согласованности данных. В асинхронных реализациях возможны ситуации, когда пользователь видит устаревшие данные после записи на другом узле (так называемая «несогласованность чтения»). В синхронных реализациях, таких как Galera Cluster, снижается производительность из-за необходимости подтверждения записи на всех узлах. Кроме того, сложность разрешения конфликтов в multi-master системах ограничивает их применение в критически важных приложениях, где требуется строгая согласованность (например, в финансовых транзакциях). Некоторые эксперты отмечают, что для большинства сценариев достаточно master-slave репликации с автоматическим переключением (failover), что проще в настройке и обслуживании.

Интересные факты

• В MySQL до версии 5.5 (2009 год) master-master репликация была возможна только при ручном разрешении конфликтов, что делало её малопригодной для производственных систем.
• Galera Cluster, разработанный компанией Codership, стал первой популярной реализацией синхронной multi-master репликации для MySQL, получившей широкое распространение в 2010-х годах.
• В распределённых базах данных, таких как Apache Cassandra, multi-master репликация является встроенной функцией, а не дополнительной опцией, что упрощает её использование.

Источники

• MySQL Documentation: Replication — Multi-Source and Multi-Master
• Galera Cluster Documentation: Introduction to Galera Cluster
• PostgreSQL BDR Documentation: Bi-Directional Replication
• Oracle Advanced Replication Guide
• «High Performance MySQL» — Baron Schwartz, Peter Zaitsev, Vadim Tkachenko (O'Reilly Media, 2012)
• «Cassandra: The Definitive Guide» — Jeff Carpenter, Eben Hewitt (O'Reilly Media, 2016)