Apache Cassandra: coordinator, replica durability, tunable consistency, hints, and repair

A Cassandra client selects a coordinator. For a write, the coordinator sends the mutation to every replica for the token range; the consistency level controls how many responses are required before success. Each responding replica records the mutation in its own commit log and memtable. A coordinator log is not a substitute for replica durability.

RF=3 with QUORUM requires two replica acknowledgements: floor(RF/2)+1. A minority of one replica is not QUORUM. Intersection (R + W > RF) helps a read contact at least one replica from the acknowledged write set under the same replica-set assumptions, but it is not by itself linearizability, transactional isolation, or perfect clock ordering.

Модель и предпосылки

• CQL consistency is set through the driver/session/statement or shell command, not appended as invalid USING CONSISTENCY syntax to a mutation.
• Hints and read repair are best-effort accelerators. Scheduled anti-entropy repair with Merkle comparisons is required to converge missed replicas within tombstone/repair policy.
• Ordinary writes use timestamp-based last-write-wins. Lightweight transactions use Paxos for linearizable compare-and-set within their documented partition scope.

Проверяемые утверждения

• C1. Writes are sent to all replicas; consistency level controls the acknowledgement count, and RF=3 QUORUM is two.
• C2. Each replica appends to its own commit log and updates a memtable before acknowledging under the storage-engine path.
• C3. Hints are durable best-effort missed-write records and do not replace anti-entropy repair.
• C4. Ordinary conflict resolution is timestamp-based last-write-wins; correctness depends on clock discipline.
• C5. Lightweight transactions use Paxos for linearizable compare-and-set semantics and have a different cost/path from ordinary writes.
• C6. Consistency level is a request/driver setting; Cassandra mutation grammar does not support an INSERT ... USING CONSISTENCY ... clause.

Исполняемые сценарии

Write QUORUM with RF=3. The coordinator sends to all three replicas and succeeds after two replicas durably acknowledge.

Read QUORUM and reconcile. The coordinator compares enough replica responses and returns the winning current value under Cassandra timestamp rules.

Hinted handoff and later repair. A hint shortens inconsistency while a replica is down, but scheduled repair remains the convergence backstop.

Paxos lightweight compare-and-set. A conditional single-partition mutation uses the LWT consensus path rather than ordinary quorum write semantics.

Ошибки проектирования

• Не пишите INSERT ... USING CONSISTENCY QUORUM: consistency level задаётся вне CQL mutation syntax.
• Не отвечайте QUORUM после одного replica ACK при RF=3.
• Не считайте hint гарантией delivery; target может отсутствовать дольше hint window.
• Не используйте устаревшие read_repair_chance настройки как текущую гарантию convergence; планируйте repair.
• Не полагайтесь на client timestamps без строгой clock/ordering policy: поздний timestamp может переиграть более новое business intent.

Границы гарантии

• LOCAL_QUORUM и QUORUM имеют разный multi-DC scope; replication strategy и snitch/topology входят в расчёт.
• Logged batch обеспечивает atomic batch delivery semantics, но не serializable isolation произвольных multi-partition updates.
• Tombstone grace, repair cadence, replacement и backup/restore должны быть согласованы, иначе удалённые данные могут воскреснуть или потеряться.

Связанные материалы

Официальные и первичные источники

1. Apache Cassandra: Dynamo architecture
2. Apache Cassandra: Storage engine
3. Apache Cassandra: Hinted handoff
4. Apache Cassandra: Repair
5. Apache Cassandra: Consistency guarantees and LWT
6. Apache Cassandra CQL DML reference