cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "HintedHandoff" by RobertColi
Date Tue, 13 Apr 2010 22:51:38 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "HintedHandoff" page has been changed by RobertColi.
The comment on this change is: clarification regarding how cassandra chooses where to write
a hint. thx to the IRC crew for the help with specific terms!.
http://wiki.apache.org/cassandra/HintedHandoff?action=diff&rev1=3&rev2=4

--------------------------------------------------

- Hinted handoff means that if a node that should receive a write is down, Cassandra will
send that write to another node with a "hint" saying that when the destination node becomes
available again, the write should be forwarded there.  Cassandra uses hinted handoff as a
way to (1) reduce the time required for a temporarily failed node to become consistent again
with live ones and (2) provide extreme write availability when consistency is not required.
+ If a node which should receive a write is down, Cassandra will write a hint to a live replica
node indicating that the write needs to be replayed to the unavailable node. If no live replica
nodes exist for this key, and !ConsistencyLevel.ANY was specified, the coordinating node will
write the hint locally. Cassandra uses hinted handoff as a way to (1) reduce the time required
for a temporarily failed node to become consistent again with live ones and (2) provide extreme
write availability when consistency is not required.
  
  A hinted write is NOT sufficient to count towards !ConsistencyLevel requirements of ONE,
QUORUM, or ALL.  Take the simple example of a cluster of two nodes, A and B, and a replication
factor of 1 (each key is stored on one node).  Suppose node A is down while we write key K
to it with !ConsistencyLevel.ONE.  Then we must fail the write: recall from the [[API]] page
that "if `W` + `R` > `ReplicationFactor`, where W is the number of nodes to block for on
write, and R the number to block for on reads, you will have strongly consistent behavior;
that is, readers will always see the most recent write."
  

Mime
View raw message