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

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

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

Основные компоненты

Мастер (Master/Primary):

• Единственный сервер, принимающий операции записи (INSERT, UPDATE, DELETE)
• Хранит исходные данные
• Генерирует бинарные логи (binary logs) всех изменений
• Отправляет эти логи на реплики

Реплика (Slave/Secondary):

• Получает бинарные логи от мастера
• Применяет эти операции локально
• Служит только для чтения (в большинстве случаев)
• Может быть повышена до мастера при его отказе

Как это работает

# Пример использования с MySQL
import mysql.connector

# Запись идёт на мастер
master_conn = mysql.connector.connect(
    host="master.db.local",
    user="app_user",
    password="password",
    database="myapp"
)

cursor = master_conn.cursor()
cursor.execute(
    "INSERT INTO users (name, email) VALUES (%s, %s)",
    ("John", "john@example.com")
)
master_conn.commit()

# Чтение идёт с репликой (с небольшой задержкой)
replica_conn = mysql.connector.connect(
    host="replica1.db.local",
    user="app_user",
    password="password",
    database="myapp"
)

cursor = replica_conn.cursor()
cursor.execute("SELECT * FROM users WHERE name = %s", ("John",))
results = cursor.fetchall()

Процесс репликации в MySQL

1. Write — приложение пишет данные на мастер
2. Log — мастер записывает события в бинарный лог
3. Transmit — мастер отправляет лог репликам (через сеть)
4. Relay — реплика получает лог в relay log
5. Execute — реплика применяет команды локально

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

Отказоустойчивость:

• Если мастер падает, реплика может стать новым мастером
• Минимизирует даунтайм приложения

Масштабируемость:

• Распределяем чтение между несколькими репликами
• Увеличиваем пропускную способность

Резервное копирование:

• Реплика служит живой резервной копией
• Не нужно блокировать данные для бэкапа

Аналитика:

• Тяжелые запросы на репликах, а не на мастере
• Не влияет на основное приложение

Недостатки

Задержка репликации (Replication Lag):

# Проблема: данные не сразу на реплике
master.write("INSERT INTO orders (item) VALUES ('phone')")
# На мастере есть
master.read("SELECT * FROM orders")  # 1 запись

# На реплике может ещё не быть (через 100мс)
replica.read("SELECT * FROM orders")  # 0 записей? Состояние гонки

Несогласованность данных:

• Если реплика отстаёт, читаем старые данные
• Приложение может увидеть противоречивое состояние

Сложность управления:

• Сложное восстановление при сбое
• Нужен мониторинг отставания

Стратегии обработки Replication Lag

# 1. Прочитать с мастера критичные данные
def get_critical_data(user_id):
    # Только что написали, читаем с мастера
    return master.get_user(user_id)

# 2. Добавить задержку для синхронизации
import time
master.insert_order(order_data)
time.sleep(0.5)  # Ждём репликации
replica.get_order(order_id)

# 3. Использовать очереди для асинхронных операций
from celery import Celery

app = Celery()

@app.task
def process_order_async(order_id):
    # Выполняется через задержку, данные уже на репликах
    return replica.get_order(order_id)

Альтернативы

Мастер-Мастер (Master-Master):

• Оба сервера принимают запись
• Сложнее, может быть конфликт при одновременной записи

Группировка репликации (Group Replication):

• MySQL Group Replication, Galera Cluster
• Все узлы могут писать
• Автоматическое согласование

Заключение

Мастер-реплика — это фундаментальный паттерн для высоконагруженных приложений. Он обеспечивает надёжность и производительность, но требует понимания особенностей асинхронной репликации и правильной архитектуры приложения.