Архитектура репликации баз данных: от мастер-слейв до мультимастер систем

Современные приложения генерируют до 2.5 квинтиллионов байт данных ежедневно (IBM Research). В таких условиях обеспечение доступности и масштабируемости становится критической задачей. Репликация баз данных решает эти проблемы, но выбор между мастер-слейв и multi-master архитектурами требует глубокого понимания их особенностей.

Основные принципы репликации

Сердце любой системы репликации — механизм синхронизации данных. Рассмотрим ключевые аспекты:

flowchart TD A[Мастер-сервер] -->|Синхронная запись| B[Слейв 1] A -->|Асинхронная запись| C[Слейв 2] B --> D[Чтение данных] C --> E[Чтение данных]


# Пример настройки MySQL Master-Slave
CHANGE MASTER TO
  MASTER_HOST='master_host',
  MASTER_USER='replica_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=107;

Типы репликации

Параметр	Синхронная	Асинхронная
Задержка	Высокая	Низкая
Согласованность	Сильная	Возможны расхождения
Производительность	До 1200 TPS	До 9500 TPS

Практическая реализация

Рассмотрим пошаговую настройку в PostgreSQL:


-- Настройка потоковой репликации
wal_level = replica
max_wal_senders = 5
hot_standby = on

# Инициализация реплики
pg_basebackup -h master_host -D /var/lib/pgsql/13/data -U replicator

flowchart LR A[Клиент] --> B[Мастер 1] A --> C[Мастер 2] B --> D[Синхронизация] C --> D D --> E[Глобальное согласование]

Кейс: Масштабирование Airbnb

32 read replica для обработки 2.4 млн запросов/час
Задержка репликации < 120 мс
Автоматический failover за 8.3 секунды

Сравнение архитектур

Критерий	Master-Slave	Multi-Master
Запись	Только мастер	Любой узел
Конфликты	Нет	Требуют разрешения
Сложность	Низкая	Высокая

Пример конфликта в Multi-Master


-- Разрешение конфликта в PostgreSQL
CREATE FUNCTION resolve_conflict() RETURNS TRIGGER AS $$
BEGIN
  IF NEW.timestamp > OLD.timestamp THEN
    RETURN NEW;
  ELSE
    RETURN OLD;
  END IF;
END;
$$ LANGUAGE plpgsql;