Как работает асинхронная репликация?

Как работает асинхронная репликация

Асинхронная репликация — это механизм копирования данных, при котором изменения на основном узле (мастере) фиксируются локально, и лишь затем асинхронно передаются на реплики, без блокировки подтверждения операций на стороне источника.

Основные принципы работы

Ключевая идея — разделение процессов записи и репликации:

1. Клиент отправляет запрос на запись на основной узел.
2. Мастер немедленно подтверждает успешность операции клиенту, не дожидаясь передачи данных на реплики.
3. Изменения помещаются в буфер или лог (например, WAL — Write-Ahead Log, binlog в MySQL, oplog в MongoDB).
4. В фоновом режиме реплики забирают изменения из лога мастера и применяют их локально.

Вот упрощённый пример на уровне архитектуры в псевдокоде:

// Основной узел (Master)
type Master struct {
    dataStore map[string]string
    changeLog chan ChangeEvent
}

func (m *Master) Write(key, value string) error {
    m.dataStore[key] = value
    // Немедленное подтверждение клиенту
    go m.replicateAsync(ChangeEvent{key, value}) // Асинхронная репликация
    return nil // Успех подтверждён до фактической репликации
}

func (m *Master) replicateAsync(event ChangeEvent) {
    // Неблокирующая отправка в лог для последующей передачи репликам
    select {
    case m.changeLog <- event:
    default:
        // Обработка переполнения буфера
    }
}

// Реплика (Slave/Replica)
type Replica struct {
    localStore map[string]string
}

func (r *Replica) subscribeToMaster(log chan ChangeEvent) {
    for event := range log { // Фоновое применение изменений
        r.localStore[event.key] = event.value
    }
}

Технические детали реализации

Асинхронная репликация обычно включает несколько компонентов:

• Журнал изменений (log): Все модификации данных последовательно записываются в устойчивый журнал.
• Отправитель изменений (sender): Передаёт записи журнала репликам.
• Приёмник и применитель (receiver/applier): На стороне реплики получает и применяет изменения, сохраняя порядок операций.

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

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

• Низкая задержка записи: Клиент не ждёт репликации.
• Высокая доступность мастера: Запросы не блокируются из-за проблем с репликами.
• Гибкость сети: Допускает временные разрывы соединения с репликами.
• Масштабируемость чтения: Реплики обслуживают read-only запросы.

Недостатки:

• Потенциальная потеря данных: При сбое мастера непереданные изменения могут быть утрачены.
• Неконсистентность в реальном времени: Реплики могут отставать (replication lag).
• Сложность обеспечения транзакционной целостности: Операции на разных узлах могут расходиться во времени.

Пример в реальных СУБД

В MySQL асинхронная репликация настраивается через binlog:

-- На мастере
CHANGE MASTER TO
  MASTER_HOST='replica1',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=107;

START SLAVE;

В PostgreSQL используется аналогичный механизм с WAL:

-- В postgresql.conf
wal_level = replica
max_wal_senders = 3

-- На реплике создаётся recovery.conf (или настройка в PostgreSQL 12+)
primary_conninfo = 'host=master port=5432 user=replicator'

Сценарии использования

Асинхронную репликацию применяют там, где доступность и производительность записи важнее мгновенной консистентности:

• Системы аналитики и отчётности (данные могут быть слегка устаревшими)
• Геораспределённые системы с высокой сетевой задержкой
• Резервное копирование "на лету" без остановки основного сервиса

Важное замечание: В современных распределённых системах асинхронную репликацию часто комбинируют с синхронной для критичных данных, используя гибридные подходы (как в Raft или Kafka ISR). Это позволяет балансировать между производительностью и надёжностью.

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