Какие плюсы и минусы репликации в БД?

Плюсы и минусы репликации в БД

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

Плюсы репликации

1. Высокая доступность

Плюс: если master упал, переводим трафик на replica.

Архитектура:
          Master (Роман до)
            ↓
         Replica 1 (готов заменить)
         Replica 2 (готов заменить)

Если Master упал → переводим приложение на Replica
Данные уже актуальны (или почти актуальны).

Практически:

# Приложение смотрит на адрес виртуального хоста
master_host = "db-master.internal"  # 1.2.3.4
replica_host = "db-replica.internal"  # 1.2.3.5

# Если master упал, DNS/LB переводит:
master_host → 1.2.3.5 (был replica, теперь master)

# Приложение не знает об изменениях, работает дальше!

2. Распределение нагрузки для чтения

Плюс: читаешь с replica, пишешь в master.

Архитектура:
         Master (все пишут)
          ↓
       Replica 1 (читает запрос 1)
       Replica 2 (читает запрос 2)
       Replica 3 (читает запрос 3)

Если 90% операций — чтение:
- Master: 10% нагрузки (только пишет)
- 3 Replica: 30% нагрузки каждая (распределено)

Код:

from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

# Для пишущих операций
master_engine = create_engine("postgresql://1.2.3.4/db")
master_session = sessionmaker(bind=master_engine)

# Для читающих операций
replica_engine = create_engine("postgresql://1.2.3.5/db")  # или другая replica
replica_session = sessionmaker(bind=replica_engine)

# Использование
write_session = master_session()
read_session = replica_session()

# Пишем в master
new_user = User(name="John")
write_session.add(new_user)
write_session.commit()

# Читаем с replica (может быть задержка!)
users = read_session.query(User).all()

3. Резервная копия в реальном времени

Плюс: replica всегда содержит актуальные данные (почти).

Если кто-то случайно удалил важный данные:
- Master: DELETE FROM users; COMMIT;  -- Упс!
- Replica: все ещё хорошо (может восстановить, если оперативно)

4. Миграции без downtime

Плюс: можно обновлять схему на replica без влияния на master.

Шаги:
1. Остановить репликацию
2. На replica: ALTER TABLE ... (могут быть long locks)
3. Когда готово, включить репликацию
4. Когда replica синхронизируется, делаем failover
5. Старый master теперь может обновиться

Минусы репликации

1. Replication lag (задержка репликации)

Минус: replica не всегда синхронизирована с master.

Время на master: 12:00:00 — вставили user_id=100
Время на replica: 12:00:01 — еще не вставили
Приложение читает с replica → user_id=100 не найден!

Проблема в коде:

# Пишем в master
write_session = master_session()
new_user = User(id=100, name="John")
write_session.add(new_user)
write_session.commit()

# Сразу же читаем с replica
read_session = replica_session()
user = read_session.query(User).filter(User.id == 100).first()

if user is None:
    print("Пользователь не найден!")  # Race condition!
else:
    print(f"Found: {user.name}")

# Решение: прочитать с master сразу после записи
user = write_session.query(User).filter(User.id == 100).first()

Типичные значения lag:

• Network LAN: 1-10 ms
• Network WAN: 100-1000 ms
• Overloaded replica: секунды или минуты

2. Чтение неактуальных данных

Минус: из-за lag'а можешь прочитать старые данные.

# Пример: выполнить платеж
user = read_session.query(User).filter(User.id == 1).first()
print(f"Balance: {user.balance}")  # 1000 (старые данные из replica)

# В этот момент в master:
# UPDATE users SET balance = 500 WHERE id = 1  (платеж!)

# Если приложение проверит баланс и снимет 700 → overspend!

Решение:

# Для критичных операций читай с master
user = write_session.query(User).filter(User.id == 1).first()
if user.balance >= 700:
    user.balance -= 700
    write_session.commit()
else:
    raise Exception("Insufficient balance")

3. Сложность с одновременной записью

Минус: нельзя писать в replica и master одновременно (обычно).

Множественный master (multi-master):
         Master 1 ↔ Master 2
           ↓         ↓
        Replica 1  Replica 2

Проблемы:
- Конфликты: что если обе master обновляют один user_id?
- Циклы репликации: Master 1 → Master 2 → Master 1
- Eventual consistency: данные не всегда согласованы

Решение: используй UUID или distributed sequence для ID

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

Минус: нужно мониторить lag, решать проблемы репликации.

# Нужно постоянно проверять
import subprocess

result = subprocess.run(
    ['mysql', '-h', 'replica_host', '-e', 'SHOW SLAVE STATUS'],
    capture_output=True
)

output = result.stdout.decode()
if 'Seconds_Behind_Master: 0' not in output:
    print("WARNING: Replica lagging!")
    # Alert admin, перенаправить трафик
else:
    print("Replica OK")

# Это нужно делать постоянно!

5. Проблемы при failover

Минус: переключение на replica может привести к потере данных.

Сценарий:
1. Master: транзакция X (INSERT user)
2. Replica: еще не получила X (LAG)
3. Master умер → failover на replica
4. Данные из X потеряны!

Решение:
- Используй synchronous replication
- Master ждет, пока replica запишет, прежде чем COMMIT
- Но это медленнее!

PostgreSQL пример:

# Master должен ждать ответа replica
synchronous_commit = remote_apply
synchronous_standby_names = 'standby1'  # Имя replica

Теперь:
- Каждый COMMIT ждет, пока replica применит изменение
- Медленнее, но безопаснее
- Overhead: 5-20% медленнее

6. Хранение + пропускная способность

Минус: replica копирует весь данные, требует хранилища и сети.

Если database = 1 TB:
- Master: 1 TB дискового пространства
- Replica 1: 1 TB (100% дополнительное хранилище)
- Replica 2: 1 TB (еще 100%)
- Total: 3 TB вместо 1 TB

Bandwidth:
- Если пишешь 100 MB/s в master
- Нужно 100 MB/s сети на каждую replica
- 3 replica = 300 MB/s сети

7. Сложность обновлений скрипты

Минус: скрипты репликации могут конфликтовать при ALTER TABLE.

Problema:
DROP COLUMN на master → replica падает (если скрипт ошибочный)
Нужно вручную фиксить

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

Statement-based (SBR)

Мaster логирует: INSERT INTO users VALUES (1, 'John')
Replica выполняет тот же запрос

Проблемы:
- NOW() → разное время на master и replica
- RAND() → разные значения
- UPDATE с LIMIT → может обновить разные строки

Row-based (RBR)

Master логирует: строка (1, 'John') изменилась на (1, 'Jane')
Replica применяет тот же UPDATE

Плюсы:
- Не зависит от содержимого запроса
- Безопаснее для RAND(), NOW()

Минусы:
- Больше логов
- Медленнее для bulk operations (миллионы строк)

Mixed-mode

Употребляет RBR для опасных операций, SBR для безопасных

Сравнение синхронизации

Когда использовать репликацию

✅ Идеально:

• Нужна высокая доступность
• Много читающих операций
• Можешь мириться с кратковременной потерей данных
• Есть операционная команда для мониторинга

❌ Плохо:

• Не нужна HA
• Критичная консистентность (финансовые системы)
• Мало ресурсов на управление

Практический пример: выбор сессии

from enum import Enum
from sqlalchemy.orm import sessionmaker

class SessionType(Enum):
    MASTER = 'master'
    REPLICA = 'replica'

class DatabaseManager:
    def __init__(self):
        self.master_engine = create_engine("postgresql://master/db")
        self.replica_engine = create_engine("postgresql://replica/db")
    
    def get_session(self, session_type: SessionType):
        if session_type == SessionType.MASTER:
            return sessionmaker(bind=self.master_engine)()
        else:
            return sessionmaker(bind=self.replica_engine)()
    
    def get_user(self, user_id: int, use_master=False):
        """Получить пользователя, опционально с master"""
        session_type = SessionType.MASTER if use_master else SessionType.REPLICA
        session = self.get_session(session_type)
        return session.query(User).filter(User.id == user_id).first()
    
    def create_user(self, name: str) -> User:
        """Создать пользователя (всегда на master)"""
        session = self.get_session(SessionType.MASTER)
        user = User(name=name)
        session.add(user)
        session.commit()
        return user
    
    def is_replica_healthy(self):
        """Проверить здоровье replica"""
        try:
            session = self.get_session(SessionType.REPLICA)
            session.execute("SELECT 1")
            return True
        except Exception:
            return False

# Использование
db = DatabaseManager()

# Читаем с replica (может быть lag)
user = db.get_user(1, use_master=False)
print(f"User: {user.name}")

# Если критично, читаем с master
user = db.get_user(1, use_master=True)
print(f"User: {user.name}")

# Пишем всегда в master
new_user = db.create_user("Jane")
print(f"Created: {new_user.id}")

Вывод

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