Что такое мастер реплики в БД?

Мастер-реплика: архитектура репликации баз данных

Мастер-реплика (master-replica) — это архитектура репликации данных в системах баз данных, где выделяется один основной узел (мастер, master) и один или несколько подчинённых узлов (реплики, replicas). Мастер принимает все операции записи (INSERT, UPDATE, DELETE) и чтения, в то время как реплики асинхронно или синхронно копируют данные с мастера и обслуживают запросы на чтение. Эта модель также известна как primary-replica, source-replica или leader-follower.

Как работает репликация мастер-реплика?

1. Все операции записи направляются только на мастер. Например:

-- Этот запрос выполнится ТОЛЬКО на мастере
INSERT INTO users (name, email) VALUES ('Иван', 'ivan@example.com');

1. Изменения с мастера реплицируются на реплики через один из механизмов:

   • Бинарный лог (binary log) в MySQL/PostgreSQL: мастер записывает изменения в лог, реплики читают и применяют их.
   • WAL (Write-Ahead Log) в PostgreSQL: реплики читают WAL-записи мастера.
   • Операционный лог (oplog) в MongoDB.

2. Пример потока данных в PostgreSQL с логической репликацией:

-- На мастере
CREATE PUBLICATION mypub FOR TABLE users, orders;

-- На реплике
CREATE SUBSCRIPTION mysub CONNECTION 'host=master dbname=mydb' PUBLICATION mypub;

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

• Асинхронная репликация (по умолчанию в MySQL): мастер подтверждает запись клиенту ДО того, как изменения достигнут реплик. Высокая производительность, но возможна потеря данных при сбое мастера.
• Синхронная репликация (например, в PostgreSQL): мастер ждёт подтверждения от одной или нескольких реплик перед подтверждением записи клиенту. Гарантирует консистентность, но снижает производительность.
• Полусинхронная репликация (полусинхронная в MySQL): компромиссный вариант, где мастер ждёт подтверждения хотя бы от одной реплики.

Преимущества архитектуры мастер-реплика

1. Масштабирование чтения: Распределение запросов SELECT между репликами:

// Пример на Go: роутинг запросов чтения на реплики
func getDBConnection(isWrite bool) *sql.DB {
    if isWrite {
        return masterDB // соединение с мастером
    }
    return replicaPool.Get() // соединение с одной из реплик
}

1. Повышение доступности: При падении мастера одна из реплик может быть повышена до нового мастера (failover).

2. Геораспределение: Реплики можно размещать в разных регионах для уменьшения задержек.

3. Резервное копирование без остановки: Бэкапы делаются с реплик, не нагружая мастер.

4. Аналитика без нагрузки на продакшен: Тяжёлые аналитические запросы выполняются на репликах.

Недостатки и ограничения

1. Задержка репликации (replication lag): Реплики могут отставать от мастера на секунды или даже минуты при высокой нагрузке.
2. Сложность отказоустойчивости: Автоматический failover требует дополнительных инструментов (Patroni, Orchestrator).
3. Ограничения на запись: Все записи всё равно проходят через один мастер, что создает bottleneck.
4. Согласованность данных: При асинхронной репликации возможны чтения устаревших данных.

Реализация в различных СУБД

• MySQL: Бинарные логи и GTID (Global Transaction Identifiers):

-- Настройка реплики в MySQL
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='master_host',
    SOURCE_USER='repl_user',
    SOURCE_PASSWORD='password',
    SOURCE_AUTO_POSITION=1;
START REPLICA;

• PostgreSQL: Физическая репликация через WAL или логическая репликация:

-- Проверка статуса репликации в PostgreSQL
SELECT client_addr, state, sync_state FROM pg_stat_replication;

• MongoDB: Replica set с автоматическим выбором мастера:

// Конфигурация replica set в MongoDB
rs.initiate({
    _id: "rs0",
    members: [
        {_id: 0, host: "master:27017"},
        {_id: 1, host: "replica1:27017"}
    ]
})

Паттерны использования в Go-приложениях

// Пример использования мастер-реплика в Go-приложении
package main

import (
    "database/sql"
    "github.com/go-sql-driver/mysql"
)

type DBManager struct {
    master *sql.DB
    replicas []*sql.DB
    nextReplica int
}

func (m *DBManager) GetWriter() *sql.DB {
    return m.master // Всегда возвращаем мастер для записи
}

func (m *DBManager) GetReader() *sql.DB {
    // Простой round-robin балансировщик для реплик
    m.nextReplica = (m.nextReplica + 1) % len(m.replicas)
    return m.replicas[m.nextReplica]
}

// Использование
func main() {
    dbManager := NewDBManager()
    
    // Запись идёт на мастер
    _, err := dbManager.GetWriter().Exec("INSERT INTO products ...")
    
    // Чтение идёт на реплику
    rows, err := dbManager.GetReader().Query("SELECT * FROM products ...")
}

Современные альтернативы и эволюция

Архитектура мастер-реплика эволюционировала в более сложные схемы:

• Multi-master репликация (несколько узлов для записи)
• Шардирование (горизонтальное разделение данных)
• Гибридные подходы (например, Vitess для MySQL)

Вывод: Мастер-реплика остаётся фундаментальным паттерном для повышения доступности и масштабируемости чтения в реляционных базах данных. Однако при проектировании distributed systems необходимо учитывать её ограничения, особенно связанные с консистентностью данных и single point of failure на запись. В современном стеке технологий эта архитектура часто комбинируется с другими подходами для создания полноценных отказоустойчивых систем.