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 Tue, 15 Feb 2011 15:49:58 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=85&rev2=86

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

  クラスタ上で一度データが配置されたら、データの削除・再起動なしにパーティショナを変更することはできません。
  
  === レプリケーション ===
- Cassandraクラスタのキー空間は上述したトークンによって複数の区間に分割されますが、追加のレプリカの配置は設定ファイルのIReplicaPlacementStrategyによってカスタマイズできます。標準のストラテジは次の通りです。(レプリケーションファクタをNとします)
+ カサンドラクラスタのキー空間は上述したトークンによって複数の区間に分割されますが、追加のレプリカの配置は設定ファイルのIReplicaPlacementStrategyによってカスタマイズできます。標準のストラテジは次の通りです。(レプリケーションファクタをNとします)
  
  * !RackUnawareStrategy: レプリカはトークンを昇順で並べた場合の「次のN-1個のノード」に配置されます。
  
@@ -35, +35 @@

  
  !RackAwareStrategyを使用する際はデータ配置の偏りを避けるため、リング上で隣接するノードは異なるデータセンターに配置するべきであることに注意してください。例えばノードA、B、C、Dからなるリングがあり、この順番でトークンが設定されているとします。ここでノードA、Bがデータセンター1.、ノードC、Dがデータセンター2に配置されている場合、ノードA、Cは常に「他のデータセンターで最初に見つかるノード」になります。このためノードA、CにはB、Dより多くのデータが蓄積されるでしょう。
  
-  * The corollary to this is, if you want to start with a single DC and add another later,
when you add the second DC you should add as many nodes as you have in the first rather than
adding a node or two at a time gradually.
+ * これらの議論の帰結として、次のことが言えます。複数のデータセンターを同時に構築しない場合、即ち最初に一つ目のデータセンターを構築し、後で二つ目を追加する場合、二つ目のデータセンターでは徐々にノードを追加していくのではなく、一つ目のデータセンターと同数のノードを一度に設置すべきです。
  
- Replication factor is not really intended to be changed in a live cluster either, but increasing
it may be done if you (a) read at ConsistencyLevel.QUORUM or ALL (depending on your existing
replication factor) to make sure that a replica that actually has the data is consulted, (b)
are willing to accept downtime while anti-entropy repair runs (see below), or (c) are willing
to live with some clients potentially being told no data exists if they read from the new
replica location(s) until repair is done.
+ レプリケーションファクタを稼働中のグラスタで変更することは想定していません。しかし以下のいずれかの方法によりレプリケーションファクタを増やすことができます。
  
- The same options apply to changing replication strategy.
+  a ConsistencyLevel.QUORUM または ALL で read することにより(どちらを使うかは既存のレプリケーションファクタに依ります)、実データを保持しているノードからデータを複製する
+  a ダウンタイムを許容できるならanti-entropyを実行する(下記参照)
+  a もしくはリペアが完了するまで、新たなレプリケーション先への
read に対してクライアントに「no data exists」が返る可能性を許容する
  
- Reducing replication factor is easily done and only requires running cleanup afterwards
to remove extra replicas.
+ 
+ レプリケーションストラテジを変更する場合も同じ選択肢が適用されます。
+ 
+ レプリケーションファクタを減らすのは簡単です。レプリケーションファクタを減らした後、余分なレプリカデータを削除するためにcleanupを実行して下さい。
  
  === Network topology ===
  Besides datacenters, you can also tell Cassandra which nodes are in the same rack within
a datacenter.  Cassandra will use this to route both reads and data movement for Range changes
to the nearest replicas.  This is configured by a user-pluggable !EndpointSnitch class in
the configuration file.

Mime
View raw message