Репликация: что именно гарантирует подтверждение

Репликация — не одна настройка «надёжности». Нужно отдельно определить: сколько копий существует, какие из них участвуют в подтверждении записи, когда реплика может обслуживать чтение, кто имеет право писать после сбоя и какой результат увидит клиент при потере ответа.

Модель

• 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.

Выбор режима

R + W > RF в Dynamo-подобной модели означает пересечение replica sets при дополнительных предпосылках о версиях и repair. Это другой механизм, его нельзя переносить дословно на PostgreSQL standby.

Failure checklist

1. Что означает client success и что означает timeout?
2. Какая копия может быть кандидатом и как проверяется её log position?
3. Чем fenced старый writer?
4. Где хранится membership epoch?
5. Как клиент дедуплицирует повтор?
6. Проверен ли restore, а не только healthy replication status?

Связанные темы

[CONCEPT]consistent-hashing

[CONCEPT]idempotency

Первичные источники

• 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