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 01:40:08 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.
The comment on this change is: Translate to Japanese: Range changes.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=89&rev2=90

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

  
  カスタムスニッチの実装例が次のリンクで紹介されています。 http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.1/contrib/property_snitch/
  
- == Range changes ==
- === Bootstrap ===
- Adding new nodes is called "bootstrapping."
+ == トークン範囲の変更 ==
+ === ブートストラップ ===
+ 新規ノードを追加することを「ブートストラップする」といいます。
  
- To bootstrap a node, turn !AutoBootstrap on in the configuration file, and start it.
+ ノードをブートストラップするには設定ファイルで!AutoBootstrapをonにして起動します。
  
- If you explicitly specify an !InitialToken in the configuration, the new node will bootstrap
to that position on the ring.  Otherwise, it will pick a Token that will give it half the
keys from the node with the most disk space used, that does not already have another node
bootstrapping into its Range.
+ !InitialTokenを設定で明示的に指定した場合は、新規ノードはリング中の指定箇所でブートストラップします。!InitialTokenを指定していない場合はリング内で最もディスク使用量が多いノードのトークン範囲を半分に分割した箇所のトークンを自動的に取得します。ただし他のノードが既にそのトークン範囲でブートストラップ中であればその範囲を避けます。
  
- Important things to note:
+ 注意点:
  
-  1. You should wait long enough for all the nodes in your cluster to become aware of the
bootstrapping node via gossip before starting another bootstrap.  The new node will log "Bootstrapping"
when this is safe, 2 minutes after starting.  (90s to make sure it has accurate load information,
and 30s waiting for other nodes to start sending it inserts happening in its to-be-assumed
part of the token ring.)
-  1. Relating to point 1, one can only boostrap N nodes at a time with automatic token picking,
where N is the size of the existing cluster. If you need to more than double the size of your
cluster, you have to wait for the first N nodes to finish until your cluster is size 2N before
bootstrapping more nodes. So if your current cluster is 5 nodes and you want add 7 nodes,
bootstrap 5 and let those finish before boostrapping the last two.
-  1. As a safety measure, Cassandra does not automatically remove data from nodes that "lose"
part of their Token Range to a newly added node.  Run `nodetool cleanup` on the source node(s)
(neighboring nodes that shared the same subrange) when you are satisfied the new node is up
and working. If you do not do this the old data will still be counted against the load on
that node and future bootstrap attempts at choosing a location will be thrown off.
-  1. When bootstrapping a new node, existing nodes have to divide the key space before beginning
replication.  This can take awhile, so be patient.
-  1. During bootstrap, a node will drop the Thrift port and will not be accessible from `nodetool`.
-  1. Bootstrap can take many hours when a lot of data is involved.  See [[Streaming]] for
how to monitor progress.
+  1. 複数ノードの追加を行う場合、一つのブートストラップノードの情報がGossipによってクラスタのすべてのノードに行き渡るまで、次のブートストラップの開始を始めるべきではありません。新規ノードは起動から2分経過し、安全になった状態で"Bootstrapping"とログ出力します。(データ分散状況を確認するのに90秒、他のノードから担当キー範囲のデータの転送が開始されるまでに30秒待ちます。)
+  1. 1に関連しますが、クラスタ内の既存のノード数をNとすると、自動トークン検出によって一度にブートストラップできるノードの数は最大Nです。もしクラスタのノード数を2倍以上に増やしたい場合は、最初に追加するNノードのブートストラップが完了するまで他のノードの追加を待つ必要があります。例えばクラスタが5ノードで構成されており、7ノードを追加したい場合、最初に追加の5ノードのブートストラップが完了するのを待ってから残りの2ノードをブートストラップしなければなりません。
+  1. 安全のため、トークン範囲の変更により担当から外れ、他のノードに移動したデータの自動削除は行われません。追加したノードがレプリカデータを取得し、正しく動作しているのを確認してからすべてのソースノード(同じトークン範囲を担当していたノード)で
`nodetool cleanup` を実行して下さい。cleanupを実行しないかぎり、古いデータもノードの負荷の一部とみなされます。この状態で新たなブートストラップを行うと、新規ノードの自動トークン選択に影響を与えます。
+  1. 新規ノードのブートストラップを行う場合、既存ノードはレプリケーションを始める前にキー空間を分割する必要があります。これにはある程度の時間がかかります。
+  1. ブートストラップ中のノードはThriftポートを閉塞するため、 `nodetool`からアクセス不能になります。
+  1. 大量のデータを移動する必要がある場合、ブートストラップは何時間にも及ぶ可能性があります。
ブートストラップの進捗を確認するには[[Streaming]]を参照して下さい。
  
- Cassandra is smart enough to transfer data from the nearest source node(s), if your !EndpointSnitch
is configured correctly.  So, the new node doesn't need to be in the same datacenter as the
primary replica for the Range it is bootstrapping into, as long as another replica is in the
datacenter with the new one.
+ !EndpointSnitchが正しく構成されていればCassandraは自律的に近接ノードを判別してデータを転送します。従って対象キー範囲のレプリカノードの一つが同じデータセンターにある限り、追加ノードをプライマリレプリカノードと同じデータセンターに設置する必要性はありません。
  
- Bootstrap progress can be monitored using `nodetool` with the `netstats` argument (0.7 and
later) or `streams` (Cassandra 0.6).
+ ブートストラップの進捗は`nodetool`の`netstats`引数(0.7以降)または`streams`
引数(Cassandra 0.6)で監視できます。
  
- During bootstrap `nodetool` may report that the new node is not receiving nor sending any
streams, this is because the sending node will copy out locally the data they will send to
the receiving one, which can be seen in the sending node through the the "AntiCompacting...
AntiCompacted" log messages.
+ ブートストラップ中に`nodetool`で監視していると追加したノードがデータストリームの送受信をしていないように見える場合があるかもしれません。これはソースノードが送信ストリーム用のデータをローカルで取り出している際中に発生します。この場合はソースノードに"!AntiCompacting...
!AntiCompacted"というログが出力されます。
  
  == Moving or Removing nodes ==
  === Removing nodes entirely ===

Mime
View raw message