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 PatricioEchague
Date Wed, 03 Aug 2011 21:58:09 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 PatricioEchague:
http://wiki.apache.org/cassandra/HintedHandoff?action=diff&rev1=5&rev2=6

- If a write is made and a replica node for the key 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 replica nodes are alive 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.
+ If a write is made and a replica node for the key is down (and hinted_handoff_enabled ==
true), Cassandra will write a hint to:
+ 
+ '''versions prior to 1.0:''' a live replica node 
+ 
+ '''version 1.0:''' the coordinator node
+ 
+ indicating that the write needs to be replayed to the unavailable node. If !ConsistencyLevel.ANY
was specified, the hint will count towards consistency if no replica nodes are alive for this
key. 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 does NOT 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