Шардирование и репликация БД

Репликация

Репликация — это механизм синхронизации данных между несколькими серверами БД для обеспечения отказоустойчивости и повышения доступности чтения.

Основные виды репликации:

• Master-Slave (Single Leader) — один мастер принимает записи, слейвы реплицируют данные. Чтение можно распределять между слейвами.
• Master-Master (Multi Leader) — несколько мастеров принимают записи, реплицируют изменения друг другу. Сложнее разрешать конфликты.
• Peer-to-Peer — все узлы равноправны, каждый может принимать записи.

Синхронная vs асинхронная репликация:

• Синхронная — подтверждение записи после репликации на все узлы. Гарантирует консистентность, но увеличивает latency.
• Асинхронная — подтверждение сразу после записи на мастер. Быстрее, но возможна потеря данных при падении мастера.

Типичные проблемы:

• Split-brain при сетевых разделениях
• Задержки репликации (replication lag) — чтение устаревших данных со слейвов
• Конфликты при multi-master репликации

Шардирование

Шардирование (Sharding) — горизонтальное разделение данных по нескольким серверам (шардам) на основе ключа шардирования.

Стратегии шардирования:

• Range-based — данные распределяются по диапазонам ключей (например, user_id 1-1000 на шард 1, 1001-2000 на шард 2). Просто, но возможен дисбаланс нагрузки.
• Hash-based — хеш от ключа шардирования определяет шард. Равномерное распределение, но сложно добавлять шарды.
• Directory-based — отдельный сервис (lookup service) хранит маппинг ключ-шард. Гибко, но добавляет точку отказа и latency.

Выбор ключа шардирования:

• Должен обеспечивать равномерное распределение данных
• Должен соответствовать типичным паттернам запросов
• Плохой выбор: автоинкрементный ID (все новые записи на один шард)

Проблемы шардирования:

• Cross-shard запросы — дорогие и медленные
• Resharding — перераспределение данных при добавлении/удалении шардов
• Распределенные транзакции — сложность обеспечения ACID
• Hot spots — неравномерная нагрузка на отдельные шарды

Комбинирование

На практике часто используют оба подхода:

• Репликация внутри каждого шарда для отказоустойчивости
• Шардирование для горизонтального масштабирования

Пример архитектуры: 3 шарда, каждый с master и 2 replica — всего 9 серверов.

Практические рекомендации

1. Начинайте с репликации — она проще и покрывает большинство сценариев
2. Шардируйте только когда — один сервер не справляется с нагрузкой или объемом данных
3. Избегайте cross-shard транзакций — пересмотрите модель данных
4. Мониторьте replication lag — особенно при чтении со слейвов
5. Автоматизируйте resharding — ручное перераспределение данных чревато ошибками

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

• Read replicas — если проблема только в чтении
• Caching layer (Redis, Memcached) — снижает нагрузку на БД
• NewSQL (CockroachDB, YugabyteDB) — автоматическое шардирование и репликация "из коробки"