Базы данных
Репликация баз данных
В 2017 году GitLab потерял 300GB данных за 5 минут: администратор случайно запустил rm -rf не на том сервере. Репликация не помогла - удаление реплицировалось мгновенно. Только старый backup (6 часов назад) спас ситуацию. История: без правильной стратегии репликации и backup любой distributed сервис уязвим.
- **Instagram**: PostgreSQL master + 30 replica для чтения фида 2+ млрд пользователей - горизонтальное масштабирование чтения
- **Booking.com**: Percona XtraDB Cluster (Galera multi-master) - 500 MySQL узлов принимают записи без single master bottleneck
- **GitHub**: Orchestrator + GTID для управления 1000+ MySQL серверов, автоматический failover за 30 секунд
Master-Replica репликация
Master-replica (master-slave) репликация: все записи идут на master, replicas копируют изменения через binlog (MySQL) или WAL (PostgreSQL). Читающие запросы распределяются на replicas - горизонтальное масштабирование чтения. Instagram держит десятки PostgreSQL replica для чтения при одном master для записи.
Replication lag - задержка replica от master. Если replica отстаёт на 5 секунд, пользователь который только что написал пост может не увидеть его при перечитывании (stale read). Instagram решает через read-your-writes consistency: запрос читателя после его же записи идёт на master.
Приложение читает профиль пользователя сразу после его обновления. Replica отстаёт на 2 секунды. Что пользователь увидит?
Синхронная vs Асинхронная репликация
Async репликация: master подтверждает запись клиенту не ожидая replica. Минимальный latency, но при падении master - возможна потеря последних N секунд данных. Sync репликация: master ждёт подтверждения от replica перед ответом клиенту. Нет потери данных, но latency растёт пропорционально задержке сети до replica.
| Параметр | Async | Sync |
|---|---|---|
| Latency записи | Низкий (не ждёт replica) | Высокий (round-trip до replica) |
| Потеря данных при crash | Возможна (последние N секунд) | Нет (replica подтвердила) |
| Доступность | Высокая (replica падение = ок) | Ниже (replica падение = запись виснет) |
| Используется в | MySQL async, PostgreSQL default | Galera Cluster, PostgreSQL sync replica |
Airbnb после инцидента (8 секунд потери при failover) перешёл на semi-sync MySQL: хотя бы одна replica подтвердила получение события. Компромисс: +2-5ms latency записи, потеря данных при failover = 0.
Финансовое приложение: списание со счёта должно быть гарантированно подтверждено. Какой тип репликации?
Failover и Promotion
Failover - автоматическое переключение на replica при падении master. Процесс: 1) Обнаружить падение master (heartbeat). 2) Выбрать наиболее актуальную replica. 3) Promotion: replica становится новым master. 4) Перенаправить все connections на новый master. 5) Другие replicas перенацелить на новый master.
Split-brain - опасная ситуация: оба узла думают что они master. Происходит если старый master не упал, но потерял связь (network partition). Решение: fencing (STONITH - Shoot The Other Node In The Head): принудительное выключение старого master через IPMI/облачный API перед promotion.
При failover replica становится новым master. Что нужно сделать со старым master когда он восстановится?
Multi-Master репликация
Multi-master (active-active): все узлы принимают записи. Нет single point of write - любой узел может принять запрос. Проблема: конфликты. Если два пользователя одновременно изменили одну строку на разных master - что победит? Galera Cluster (MySQL) использует certifcation-based conflict detection.
CockroachDB - NewSQL multi-master с автоматическим разрешением конфликтов через MVCC и Raft consensus. Каждый узел принимает записи, конфликты разрешаются детерминированно. Используется Doordash, SpaceX.
Multi-master репликация. Два пользователя одновременно бронируют последний номер в отеле на разных master. Что произойдёт?
Quorum и Consensus
Quorum - минимальное количество узлов, которые должны согласиться для успешной операции. При N узлах и replication factor R: для гарантии видимости нужно W + R > N (W - write quorum, R - read quorum). Cassandra: N=3, W=2, R=2: 2+2>3, любая запись будет видна при чтении с quorum.
Raft vs Paxos: оба достигают consensus, но Raft проще понять и реализовать. etcd, CockroachDB, TiDB, Consul используют Raft. Paxos используется в Google Chubby, Zookeeper (ZAB - Zookeeper Atomic Broadcast, вариант Paxos).
Репликация = резервная копия
Репликация обеспечивает availability и read scaling, но НЕ защищает от удаления данных - DELETE на master реплицируется на все replicas. Нужны отдельные backup стратегии.
Репликация и backup решают разные проблемы. Если DROP TABLE выполнен на master - через секунды таблица удалена на всех replicas. Backup сохраняет исторические снапшоты для восстановления.
Raft кластер из 5 узлов. Сколько узлов могут упасть без потери работоспособности?
Ключевые идеи
- **Async vs Sync**: async = низкий latency + возможная потеря данных; sync = no data loss + выше latency; semi-sync = компромисс
- **Failover**: автоматическая promotion replica в master через Patroni/Orchestrator; split-brain предотвращается fencing
- **Quorum**: W + R > N гарантирует read-your-writes; Raft consensus = основа distributed согласованности
Связанные темы
Репликация - основа для более сложных паттернов масштабирования:
- Шардинг — Репликация масштабирует чтение; шардинг масштабирует запись
- CAP теорема — Выбор sync/async репликации напрямую определяет позицию в CAP
- Резервное копирование — Репликация не заменяет backup - они решают разные проблемы
Вопросы для размышления
- Система требует RPO=0 (нулевая потеря данных). Как настроить репликацию и какой ценой?
- Multi-master vs Master-replica: когда trade-off сложности multi-master оправдан?
- Raft quorum: почему нечётное число узлов (3, 5, 7) предпочтительнее чётного?