Репликация

TL;DR

Репликация — механизм копирования данных между узлами базы данных для отказоустойчивости, масштабирования чтения или геораспределения. Позволяет переживать сбои основного сервера и распределять нагрузку чтения.

Краткое определение

Репликация — процесс копирования данных с основного узла (primary/master) на вторичные узлы (replicas/slaves) для обеспечения отказоустойчивости, масштабирования операций чтения или географического распределения данных.

Оригинал и перевод

• Язык: английский
• Оригинал: Replication (от лат. replicatio — повторение)
• Буквальный перевод: репликация, воспроизведение, копирование
• Русские аналоги: репликация данных, репликация БД, копирование данных

Синонимы и варианты написания

• Репликация данных
• Database replication
• Master-slave replication
• Primary-replica replication

Где используется

• СУБД: PostgreSQL, MySQL, MariaDB, MongoDB, Redis
• Распределённые хранилища: Cassandra, DynamoDB
• Очереди сообщений: Kafka, RabbitMQ
• Распределённые файловые системы: Ceph, GlusterFS

Когда это важно

Репликация критична в следующих сценариях:

• Отказоустойчивость: переключение на реплику при сбое primary
• Масштабирование чтения: распределение SELECT запросов по репликам
• Геораспределение: данные ближе к пользователям в разных регионах
• Бэкапы без нагрузки на primary: бэкап с реплики
• Аналитика: тяжёлые запросы на реплике, не на primary

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

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

Данные записываются на primary и реплики одновременно:

Клиент → Primary → Реплика 1
                  → Реплика 2
                  
✅ Гарантирует: данные не потеряются
❌ Требует: подтверждения от всех реплик (медленнее)

Использование: финансы, платежи, критичные данные

2. Асинхронная репликация

Primary подтверждает запись сразу, реплики догоняют позже:

Клиент → Primary ✅ (подтверждение)
              ↓ (позже)
         Реплика 1
         Реплика 2
         
✅ Быстрее: не ждёт реплик
❌ Риск: реплики могут отставать (потеря данных при сбое)

Использование: бэкапы, аналитика, кэширование

3. Полусинхронная репликация

Компромисс: ждёт подтверждения хотя бы от одной реплики:

Клиент → Primary → Реплика 1 ✅
                  → Реплика 2 (асинхронно)
                  
✅ Баланс: надёжность + производительность

Схемы репликации

Primary-Replica (Master-Slave)

Один узел принимает запись, остальные обслуживают чтение:

        ┌─────────────┐
        │   Primary   │ ← Запись (INSERT, UPDATE, DELETE)
        │   (Master)  │
        └──────┬──────┘
               │ WAL / Binlog
    ┌──────────┼──────────┐
    │          │          │
    ▼          ▼          ▼
┌────────┐ ┌────────┐ ┌────────┐
│Replica │ │Replica │ │Replica │ ← Чтение (SELECT)
│  (1)   │ │  (2)   │ │  (3)   │
└────────┘ └────────┘ └────────┘

Плюсы:

• Простота реализации
• Чёткое разделение запись/чтение
• Легко добавить новую реплику

Минусы:

• Primary — единая точка отказа (нужен failover)
• Реплики могут отставать

Multi-Primary (Master-Master)

Несколько узлов принимают запись:

┌─────────────┐         ┌─────────────┐
│  Primary 1  │ ←→→→→→→ │  Primary 2  │
│             │         │             │
└─────────────┘         └─────────────┘
       ↑                       ↑
    Запись                   Запись
    
✅ Выше доступность: запись на любой узел
❌ Сложнее: конфликты записи, нужна синхронизация

Использование: гео-распределённые системы, high availability

Репликация в PostgreSQL

Настройка streaming replication

# postgresql.conf на primary
wal_level = replica
max_wal_senders = 3
wal_keep_size = 64MB

# pg_hba.conf на primary
host replication replicator 10.0.0.2/32 md5

# На реплике
primary_conninfo = 'host=10.0.0.1 user=replicator password=secret'

Проверка статуса

-- На primary
SELECT client_addr, state, sent_lsn, write_lsn, replay_lsn
FROM pg_stat_replication;

-- На реплике
SELECT pg_is_in_recovery();  -- t (true, если реплика)
SELECT pg_last_wal_receive_lsn();
SELECT pg_last_wal_replay_lsn();

Репликация в MySQL

Настройка репликации

-- На primary
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

-- SHOW MASTER STATUS;
-- File: mysql-bin.000001, Position: 154

-- На реплике
CHANGE MASTER TO
  MASTER_HOST='primary_host',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

START SLAVE;

-- Проверка
SHOW SLAVE STATUS\G
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0

Типичные проблемы репликации

1. Отставание реплик (Replication Lag)

Реплика не успевает применять изменения:

Причины:

• Медленный диск на реплике
• Тяжёлые запросы на реплике
• Сетевая задержка
• Одна транзакция на primary блокирует репликацию

Решение:

• Мониторинг Seconds_Behind_Master (MySQL) или pg_stat_replication (PostgreSQL)
• Оптимизация запросов на реплике
• SSD диски на репликах
• Разделение нагрузки чтения

2. Конфликты при Multi-Primary

Два узла изменили одну запись:

Primary 1: UPDATE users SET balance = 100 WHERE id = 1
Primary 2: UPDATE users SET balance = 200 WHERE id = 1

Решение:

• Шардирование по ключу (какая запись на каком узле)
• Конфликт-резолвинг (последняя запись побеждает)
• Избегать Multi-Primary без необходимости

3. Потеря данных при сбое primary

Асинхронная репликация → реплики не успели получить данные:

Решение:

• Синхронная или полусинхронная репликация
• Мониторинг отставания
• План failover с проверкой реплик

Аналоги и связанные термины

• High Availability — отказоустойчивость
• Failover — переключение на резервный узел
• WAL (Write-Ahead Logging) — журнал упреждающей записи
• Read replicas — реплики для чтения
• Sharding — горизонтальное разбиение данных

Смотри также (статьи на сайте)

• PostgreSQL для веб-разработчиков — миграция с MySQL, JSON, оптимизация
• Бэкап и восстановление PostgreSQL — pg_dump и pg_restore

Смотри также (сниппеты)

• PostgreSQL: JSONB и GIN-индекс — работа с JSON
• ACID — атомарность транзакций

Смотри также (термины)

• Sharding — горизонтальное разбиение
• ACID — свойства транзакций
• Failover — переключение при сбое
• Backup strategy — стратегии бэкапа

Мини-FAQ

Репликация и бэкап — одно и то же?

Ответ: Нет. Репликация копирует данные в реальном времени и может тиражировать ошибки (удаление, повреждение). Бэкап — снимок на момент времени, позволяет откатиться назад.

Сколько реплик нужно?

Ответ:

• Минимум: 1 реплика для отказоустойчивости
• Оптимально: 2-3 реплики (чтение + бэкап + failover)
• Для масштабирования: столько, сколько нужно для нагрузки чтения

Как выбрать между синхронной и асинхронной?

Ответ:

• Синхронная: критичные данные (финансы, платежи)
• Асинхронная: бэкапы, аналитика, кэширование
• Полусинхронная: компромисс для production

Репликация замедляет primary?

Ответ: Минимально при асинхронной репликации. При синхронной — задержка = время сети до самой медленной реплики.