Multi-Master

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

История

Концепция Multi-Master возникла в 1980-х годах в связи с ростом потребностей в распределённых вычислениях и отказоустойчивых системах. Первые коммерческие реализации появились в СУБД, ориентированных на высокую доступность, таких как Oracle RAC (Real Application Clusters) и Microsoft SQL Server с технологиями репликации. В 1990-2000-х годах архитектура получила развитие в open-source проектах: MySQL Cluster, MariaDB Galera Cluster, PostgreSQL с расширениями типа BDR (Bi-Directional Replication). В 2010-х годах Multi-Master стала основой для многих NoSQL-систем (например, Cassandra, Riak) и распределённых баз данных нового поколения, таких как CockroachDB и YugabyteDB.

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

В Multi-Master-кластере каждый узел (мастер) хранит полную копию данных или их часть (шард). При записи на одном узле изменения автоматически распространяются на другие узлы через механизмы репликации. Существует два основных подхода к синхронизации:

• Синхронная репликация: запись считается завершённой только после подтверждения от всех (или большинства) узлов. Это гарантирует консистентность данных, но увеличивает задержки.
• Асинхронная репликация: узел фиксирует запись локально и отправляет изменения другим узлам в фоновом режиме. Это повышает производительность, но может привести к временным расхождениям данных (конфликтам).

Разрешение конфликтов

Конфликты возникают, когда два узла одновременно изменяют один и тот же объект данных. Методы их разрешения включают:

• Last-Writer-Wins (LWW): сохраняется значение от последней по времени записи (на основе временных меток).
• Merge-функции: данные объединяются по определённым правилам (например, для счётчиков — суммирование, для строк — конкатенация).
• Версионирование: сохраняются все версии изменений, конфликт разрешается приложением или администратором.
• CRDT (Conflict-Free Replicated Data Types): специальные структуры данных, которые математически гарантируют отсутствие конфликтов (например, счётчики, множества).

Классификация

Multi-Master архитектуры делятся по способу организации кластера:

• Active-Active: все узлы одновременно обрабатывают запросы на чтение и запись. Используется в системах с высокой нагрузкой (например, веб-приложения, чаты).
• Active-Passive: один узел активен, остальные находятся в режиме ожидания, но могут взять на себя запись при отказе основного. Фактически это гибрид с Single-Master.
• Multi-Master с шардированием: каждый узел отвечает за свой сегмент данных (шард), но при этом может принимать записи для других шардов через координацию (например, в Cassandra).

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

• Высокая доступность: при отказе одного узла остальные продолжают работу без потери возможности записи.
• Горизонтальное масштабирование: добавление новых узлов увеличивает пропускную способность по записи.
• Снижение задержек: пользователи могут писать на ближайший географически узел (в распределённых системах).
• Отказоустойчивость: отсутствие единой точки отказа (single point of failure).

Недостатки

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

Применение

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

• Геораспределённые системы: глобальные сервисы (например, облачные платформы, социальные сети), где пользователи из разных регионов должны иметь возможность писать данные локально.
• Финансовые системы: биржи, банковские системы, где отказ одного узла не должен останавливать операции.
• Интернет вещей (IoT): устройства, генерирующие данные в разных точках, которые должны синхронизироваться.
• Корпоративные приложения: ERP-системы, CRM, где требуется высокая доступность и низкое время простоя.

Примеры реализаций

• MySQL Galera Cluster: синхронная Multi-Master репликация для MySQL/MariaDB. Поддерживает до 32 узлов, автоматическое разрешение конфликтов.
• Cassandra: асинхронная Multi-Master с шардированием, использует LWW и настраиваемые уровни консистентности.
• CockroachDB: распределённая SQL-СУБД с синхронной репликацией и автоматическим разрешением конфликтов на основе транзакций.
• Oracle RAC: кластерная архитектура, где все узлы имеют доступ к общему хранилищу данных (Shared Disk), что упрощает синхронизацию.
• PostgreSQL BDR: расширение для асинхронной Multi-Master репликации с поддержкой конфликт-резолюции.

Критика

Основные претензии к Multi-Master связаны с компромиссом между консистентностью и производительностью. В синхронных реализациях (например, Galera) при большом количестве узлов растёт задержка записи, что делает их непригодными для высоконагруженных систем с частыми операциями записи. В асинхронных системах (Cassandra) возможны временные потери данных при сбоях, что критично для финансовых транзакций. Кроме того, сложность настройки и администрирования Multi-Master кластеров часто приводит к ошибкам конфигурации, особенно в организациях без квалифицированных DBA.

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

• В 2010-х годах Google разработал собственную Multi-Master систему Spanner, которая использует атомные часы и GPS для синхронизации времени, что позволило достичь глобальной консистентности данных.
• В России архитектура Multi-Master активно применяется в системах «1С:Предприятие» для распределённой работы филиалов крупных компаний, где требуется локальная запись данных с последующей синхронизацией.
• В 2023 году компания MariaDB объявила о поддержке Multi-Master в облачной версии SkySQL, что позволило клиентам строить отказоустойчивые кластеры без необходимости самостоятельной настройки репликации.

Источники

• «Database Systems: The Complete Book» (H. Garcia-Molina, J. D. Ullman, J. Widom)
• «Designing Data-Intensive Applications» (Martin Kleppmann)
• Документация MySQL Galera Cluster
• Документация Apache Cassandra
• Статья «Multi-Master Replication: Pros and Cons» (журнал «Database Journal», 2021)