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_JP" by shot6
Date Mon, 05 Apr 2010 14:55:02 GMT
Dear Wiki user,

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

The "HintedHandoff_JP" page has been changed by shot6.
http://wiki.apache.org/cassandra/HintedHandoff_JP?action=diff&rev1=4&rev2=5

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

  ## page was copied from HintedHandoff
- 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.
+ Hinted handoff(ヒントハンドオフ)とは、あるノードが書き込み失敗の通知を受けたときに、Cassandraが"失敗したノードが復旧したら書き込んだ内容をフォワードしてください"というヒントと共に別のノードに書き込む機能の事をいいます.
+ CassandraはHinted handoffを、
+ (1)一時的にダウンしているノードの復旧までの時間を短縮する
+ (2)一貫性が必須でないところでの可用性を極限まで向上する
  
- 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."
+ ことを目的として使っています.
  
- Thus if we write a hint to B and call the write good because it is written "somewhere,"
there is no way to read the data at any !ConsistencyLevel until A comes back up and B forwards
the data to him.  Historically, only the lowest !ConsistencyLevel of ZERO would accept writes
in this situation; for 0.6, we added !ConsistencyLevel.ANY, meaning, "wait for a write to
succeed anywhere, even a hinted write that isn't immediately readable."
+ ヒントつき書き込みは、!ConsistencyLevelがONE、QUORUM、ALLのときには有効ではありません.
+ 2つのCassandraノード(A, B)を持ち、レプリケーション要素数が1(各キーが1つのノードにしか保存されない)のシンプルな例を考えてみましょう.
+ ノードAがキーK(!ConsistencyLevel.ONE)を書き込みの途中にダウンしたとします.
+ この書き込みは、Wは書き込みのためにブロックしているノード数、Rは読み込みのためにブロックしているノード数としたとき、
+ `W` + `R` > `ReplicationFactor`を満たさないため、失敗になります([[API]]より抜粋).
  
+ それゆえ、この場合Bにヒントを書き込みを行うのは成功するはずです.
+ 何故かというと、Aが復旧するまで如何なる!ConsistencyLevelでもBがデータをフォワードする事はないからです.
+ 昔は!ConsistencyLevelがZEROの場合のみこのような書き込みを許容していましたが、0.6ではこのようなケースも考慮して
+ 新しく!ConsistencyLevel.ANYを作りました.!ConsistencyLevel.ANYの意味は、"ヒント付き書き込みがすぐに読み込み可能にならなくても、どこかで成功した書き込みを待ちますよ"、ということになります.
+ 

Mime
View raw message