Особенности работы с репликами баз данных в бэкенд-приложениях

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

Ключевые аспекты, которые нужно учитывать:

1. Разделение чтения/записи (Read/Write Splitting)

   • Задача: Направлять все INSERT, UPDATE, DELETE запросы на master-ноду, а SELECT запросы распределять между репликами.
   • Реализация: Обычно реализуется на уровне драйвера БД, прокси-сервера (например, ProxySQL) или в логике самого приложения.

2. Лаг репликации (Replication Lag)

   • Проблема: Данные на репликах появляются с задержкой относительно master-ноды. Чтение с реплики сразу после записи на master может вернуть устаревшие данные (stale read).
   • Решение:
     • Для критически важных чтений (например, проверка баланса после пополнения) выполнять запрос к master-ноде.
     • Мониторить лаг репликации и временно отключать "отстающие" реплики от балансировки.

3. Согласованность данных (Data Consistency)

   • Это прямое следствие лага репликации. Нужно выбирать стратегию согласованности:
     • Сильная согласованность (Strong Consistency): Всегда читать с master. Просто, но не масштабируемо.
     • Конечная согласованность (Eventual Consistency): Читать с реплик, допуская получение устаревших данных. Подходит для большинства некритичных операций (лента новостей, комментарии).
     • Read-your-writes Consistency: Гарантировать, что пользователь увидит свои собственные изменения. Можно реализовать, привязав сессию пользователя к master-ноде на короткое время после записи.

4. Обработка отказов (Failover)

   • Отказ реплики: Приложение должно уметь обнаруживать недоступность реплики и исключать её из пула для чтения.
   • Отказ master-ноды: Требуется автоматический или ручной процесс "продвижения" одной из реплик до нового master. Приложение должно уметь переключиться на новую master-ноду.

5. Балансировка нагрузки и пулы соединений

   • Необходимо эффективно распределять запросы на чтение между доступными репликами (например, по алгоритму Round Robin или Least Connections).
   • Приложение должно поддерживать отдельные пулы соединений для master-ноды и для реплик.

Пример с MongoDB в Go:

Драйвер MongoDB позволяет указать предпочтения чтения (Read Preference), чтобы управлять, куда пойдут запросы.

// Чтение с ближайшей реплики для уменьшения задержки
opts := options.Find().SetReadPreference(readpref.Nearest())
cursor, err := collection.Find(ctx, filter, opts)

// Для критически важного чтения можно явно указать primary
optsPrimary := options.Find().SetReadPreference(readpref.Primary())
cursor, err = collection.Find(ctx, filter, optsPrimary)