Сколько будет мастеров в режиме Master-Master?

Принцип работы и количество мастеров в режиме Master-Master

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

Стандартный сценарий: два мастера

Наиболее распространённая конфигурация — это два мастера, работающих в режиме взаимной репликации. Каждый узел принимает операции записи и чтения, а изменения реплицируются на другой узел.

Пример схемы на Go с использованием каналов для демонстрации логики:

package main

import (
    "fmt"
    "sync"
)

// Master узел в топологии Master-Master
type Master struct {
    ID      int
    Data    map[string]string
    Partner *Master
    mu      sync.RWMutex
}

// Write операция записи на локальном мастере с репликацией
func (m *Master) Write(key, value string) {
    m.mu.Lock()
    m.Data[key] = value
    m.mu.Unlock()
    
    // Асинхронная репликация на партнёрский узел
    go m.Partner.replicate(key, value)
}

// Репликация изменений от партнёрского узла
func (m *Master) replicate(key, value string) {
    m.mu.Lock()
    defer m.mu.Unlock()
    m.Data[key] = value
    fmt.Printf("Узел %d получил репликацию: %s = %s\n", m.ID, key, value)
}

func main() {
    // Создаём два мастера
    master1 := &Master{ID: 1, Data: make(map[string]string)}
    master2 := &Master{ID: 2, Data: make(map[string]string)}
    
    // Связываем их для репликации
    master1.Partner = master2
    master2.Partner = master1
    
    // Операции записи на обоих мастерах
    master1.Write("user1", "Alice")
    master2.Write("user2", "Bob")
    
    // Данные реплицируются между узлами
}

Архитектурные вариации количества мастеров

Количество мастеров в системе зависит от нескольких факторов:

1. Технологический стек:

   • MySQL/MariaDB с Galera Cluster — поддерживает до ~10 узлов
   • PostgreSQL с BDR — обычно 2-4 узла
   • CockroachDB, YugabyteDB — распределённые SQL БД, поддерживают десятки узлов
   • Cassandra, DynamoDB — NoSQL с multi-master, поддерживают сотни узлов

2. Протоколы консенсуса и репликации:

   • Двусторонняя репликация — только 2 узла
   • Кольцевая репликация — 3+ узлов
   • На основе Raft/Paxos — теоретически неограниченно, но практически 3-7
   • На основе gossip-протоколов — десятки/сотни узлов

Практические ограничения и компромиссы

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

// Псевдокод, демонстрирующий проблему конфликтов при N мастеров
func handleConflict(masters []*Master, key, value string) {
    // При N > 2 возрастает вероятность конфликтов одновременных записей
    // Требуются сложные алгоритмы разрешения конфликтов:
    // - Векторные часы (vector clocks)
    // - Последний писатель побеждает (LWW)
    // - Автоматическое слияние (CRDT)
}

Ключевые ограничения:

• Конфликты записей — вероятность растёт квадратично с увеличением мастеров
• Задержки репликации — сетевые задержки между географически распределёнными узлами
• Согласованность данных — CAP-теорема: при разделении сети нужно выбирать между доступностью и согласованностью
• Сложность администрирования — мониторинг, восстановление после сбоев

Рекомендации по выбору количества мастеров

2 мастера — оптимально для:

• Высокой доступности с автоматическим failover
• Географического распределения (например, EU и US датацентры)
• Сравнительно простого управления конфликтами

3+ мастеров — целесообразно при:

• Требованиях к локальности данных в нескольких регионах
• Использовании специализированных распределённых БД
• Готовности к сложностям разрешения конфликтов

Пример выбора архитектуры на Go:

// Конфигурация кластера с переменным количеством мастеров
type ClusterConfig struct {
    MinMasters   int    // Минимальное количество для кворума
    TotalMasters int    // Общее количество мастер-узлов
    QuorumType   string // "majority", "weighted", "geographic"
}

// Расчёт кворума для принятия решений
func (c *ClusterConfig) CalculateQuorum() int {
    switch c.QuorumType {
    case "majority":
        return c.TotalMasters/2 + 1
    case "weighted":
        // С учётом весов узлов
        return c.TotalMasters * 2 / 3
    default:
        return c.MinMasters
    }
}

Заключение

Количество мастеров в режиме Master-Master не фиксировано, но на практике:

• 80% случаев — 2 мастера (баланс простоты и отказоустойчивости)
• 15% случаев — 3-5 мастеров (сложные распределённые системы)
• 5% случаев — 6+ мастеров (специализированные глобально распределённые системы)

Выбор зависит от требований к доступности, согласованности, задержкам и толерантности к конфликтам. Для большинства Go-приложений рекомендуется начинать с двух мастеров, добавляя узлы только при явных операционных требованиях, используя проверенные решения типа Vitess, CockroachDB или TiDB для масштабирования.