Replication и consistency models¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Replication создаёт копии, consistency определяет допустимые наблюдения. Linearizability задаёт single-operation real-time order, serializability — эквивалентность transaction schedules, strict serializability соединяет оба требования. Eventual consistency обещает convergence при прекращении updates и необходимых условиях доставки, а не bounded lag.

flowchart LR
  Client --> Primary
  Primary --> Local[Local durable log]
  Primary -. async or sync .-> Replica
  Replica --> Apply[Apply and query visibility]
  Local --> Ack[ACK depends on configured boundary]

Операция чтения или записи по шагам¶

Primary commit может сначала fsync local WAL, ACK client, позже передать/apply replica. Client читает replica и видит старое значение. Read-your-writes можно обеспечивать primary routing или ожиданием нужной log position; «lag в секундах небольшой» не доказывает наличие конкретной записи.

Консистентность, отказ и восстановление¶

R+W>RF даёт quorum intersection только при соответствующих replica sets/scope. Concurrent writes, sloppy quorum, timestamp ordering и changing membership требуют отдельного анализа. Cassandra LOCAL_QUORUM не global serializability; Redis WAIT не превращает async failover в consensus.

Выбор, эксплуатация и ограничения¶

Sync replication обменивает latency/availability на меньший риск потери; удалённый ACK может означать received, fsynced или applied. DynamoDB MREC/MRSC — разные контракты, а Elasticsearch refresh относится к searchable visibility. Выбирать требуемую гарантию для конкретного чтения/записи.

Типичные ошибки проектирования¶

Считать replica backup; говорить «strong» без scope; путать durable receipt с query visibility. Вопрос: можно ли потерять успешный Redis write? При определённых persistence/failover сценариях да, даже если команда атомарна.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Составьте matrix primary crash, network split и replica promotion для async/sync схем. Укажите fencing, неопределённый client outcome и reconciliation.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.