System Design Cases
Replication
Three replication topologies (single-leader, multi-leader, leaderless quorum) with five scenarios: sync write happy path, async write with risk, replication-lag read-your-writes anomaly, failover sequence via consensus, multi-leader split-brain with conflict resolution.
Репликация: что именно гарантирует подтверждение
Репликация — не одна настройка «надёжности». Нужно отдельно определить: сколько копий существует, какие из них участвуют в подтверждении записи, когда реплика может обслуживать чтение, кто имеет право писать после сбоя и какой результат увидит клиент при потере ответа.
Модель
- Replication factor — число копий диапазона данных.
- Acknowledgement threshold — сколько выбранных реплик должны подтвердить запись до ответа клиенту.
- Replay visibility — применена ли запись на читающей реплике, а не только получена.
- Election — выбор нового лидера из допустимых кандидатов.
- Fencing — техническое лишение старого лидера права писать. Без fencing quorum сам по себе не защищает общий диск или внешний endpoint.
В PostgreSQL список synchronous_standby_names задаёт число ожидаемых ответов. FIRST выбирает заданное число по приоритету; ANY выбирает заданное число из quorum-кандидатов. Остальные standby могут оставаться асинхронными. Это не означает «ждать всех follower».
Сценарии
ANY 1 из двух кандидатов — конкретная учебная конфигурация. Успешный ответ означает, что выполнен именно этот договор подтверждения. Он не обещает, что каждая копия уже применила WAL, а timeout не доказывает rollback.
Асинхронный DR уменьшает latency записи, но оставляет окно потери уже подтверждённых данных при failover. RPO надо измерять из lag и проверять восстановлением, а не объявлять равным нулю.
Read-your-writes обеспечивается маршрутизацией на writer, session token/LSN barrier или ожиданием replay. Сам факт наличия реплики этого не даёт.
Новый лидер должен иметь достаточно актуальный журнал и новый epoch. До переноса endpoint старый writer изолируется storage/network fencing. Повтор мутации после неясного ответа требует operation id.
Выбор режима
| Требование | Возможный режим | Цена и оговорка |
|---|---|---|
| Минимальная write latency | local commit + async replicas | RPO больше нуля при аварии |
| Подтверждённая удалённая копия | synchronous count | network/storage latency на commit path |
| Быстрые масштабируемые чтения | async read replicas | staleness; нужны routing/barriers |
| Высокая доступность writer | quorum election + fencing | сложный control plane и неоднозначные клиентские timeout |
R + W > RF в Dynamo-подобной модели означает пересечение replica sets при дополнительных предпосылках о версиях и repair. Это другой механизм, его нельзя переносить дословно на PostgreSQL standby.
Failure checklist
- Что означает client success и что означает timeout?
- Какая копия может быть кандидатом и как проверяется её log position?
- Чем fenced старый writer?
- Где хранится membership epoch?
- Как клиент дедуплицирует повтор?
- Проверен ли restore, а не только healthy replication status?
Связанные темы
Первичные источники
- PostgreSQL, Log-Shipping Standby Servers: https://www.postgresql.org/docs/current/warm-standby.html
- PostgreSQL, Replication Configuration: https://www.postgresql.org/docs/current/runtime-config-replication.html
- Ongaro and Ousterhout, Raft: https://raft.github.io/raft.pdf
- Apache Cassandra, Dynamo architecture: https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html