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 "Operations_JP" by MakiWatanabe
Date Fri, 18 Feb 2011 14:02:19 GMT
Dear Wiki user,

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

The "Operations_JP" page has been changed by MakiWatanabe.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=93&rev2=94

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

  
  移動やデータ格納量の均等化状況は`nodetool`に`streams`引数を与えることで監視できます。
  
- == Consistency ==
- Cassandra allows clients to specify the desired consistency level on reads and writes. 
(See [[API]].)  If R + W > N, where R, W, and N are respectively the read replica count,
the write replica count, and the replication factor, all client reads will see the most recent
write.  Otherwise, readers '''may''' see older versions, for periods of typically a few ms;
this is called "eventual consistency."  See http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
and http://queue.acm.org/detail.cfm?id=1466448 for more.
+ == 整合性 ==
+ Cassandraではreadやwriteにおいて必要な整合性レベルをクライアントが指定できます([[API]]参照)。R、W、Nがそれぞれ読み出したレプリカ数、書き込んだレプリカ数、レプリケーションファクターを示すとすると、R
+ W > N であればすべての read は最新の write を読むことができます。この条件を満たさない場合、タイミングによっては
read は古いデータを返すかもしれません。これは結果整合性"evantual
consistency"と呼ばれています。
  
- See below about consistent backups.
+ 結果整合性の詳細については以下の資料を参照して下さい。
+ http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
+ http://queue.acm.org/detail.cfm?id=1466448
  
+ 整合性のあるバックアップについては後述します。
- === Repairing missing or inconsistent data ===
- Cassandra repairs data in two ways:
  
-  1. Read Repair: every time a read is performed, Cassandra compares the versions at each
replica (in the background, if a low consistency was requested by the reader to minimize latency),
and the newest version is sent to any out-of-date replicas.
-  1. Anti-Entropy: when `nodetool repair` is run, Cassandra computes a Merkle tree of the
data on that node, and compares it with the versions on other replicas, to catch any out of
sync data that hasn't been read recently.  This is intended to be run infrequently (e.g.,
weekly) since computing the Merkle tree is relatively expensive in disk i/o and CPU, since
it scans ALL the data on the machine (but it is is very network efficient).  
+ === 失われたデータや、一貫性のないデータの修復 ===
+ Cassandraは2つの方法でデータ修復を行います:
  
- Running `nodetool repair`:
- Like all nodetool operations, repair is non-blocking; it sends the command to the given
node, but does not wait for the repair to actually finish.  You can tell that repair is finished
when (a) there are no active or pending tasks in the CompactionManager, and after that when
(b) there are no active or pending tasks on o.a.c.concurrent.AE-SERVICE-STAGE, or o.a.c.service.StreamingService.
  
- Repair should be run against one machine at a time.  (This limitation will be fixed in 0.7.)
+  1. Read Repair: readが実行される度、Cassandraはレプリカされたデータ間のバージョン確認を行い、古いデータを持つノードに最新のデータを配布します。クライアントから整合性要求レベルが低いリクエストを受け取った場合は、遅延を最小化するためにバージョン比較はバックグラウンドで実施されます。
+  1. Anti-Entropy:  `nodetool repair`を実行するとCassandraは直近で参照されておらず、同期されていないデータを検出するため、そのノードに格納されているデータのMerkle
treeを計算し、他のレプリカノードと比較します。Merkle treeの計算にはノード上の全データのスキャンが必要であるため、ディスクI/OやCPUを多く消費します(ネットワーク帯域の観点からは効率的です)。
このため`nodetool repair`をあまり頻繁に実行することは設計時に想定されていません。
+ 
+ 
+ `nodetool repair`の実行: 他のnodetool 操作と同様に、repairはノンブロックな操作です。nodetoolは指定されたノードにコマンドを送りますが、リペアが完了するまで待ちません。次の条件が整った時点でリペアが完了したことを知ることができます:
(a) CompactionManagerにアクティブなタスクもペンディングタスクも残っていないこと、次に(b)
o.a.c.concurrent.AE-SERVICE-STAGE、o.a.c.service.StreamingServiceのどちらにもアクティブなタスクもペンディングタスクも残っていないこと。
+ 
+ 
+ リペアは一度に一台のノードで実行すべきです。 (この制限は0.7で取り除かれています。)
  
  === Frequency of nodetool repair ===
  

Mime
View raw message