[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-05-19 Thread Apache Wiki 
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: Sync to EN#92.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=108&rev2=109

--

  <>
  === トークン選択 ===
  
強いハッシュ関数を使うことによって平均的には!RandomPartitionerのキーはキー空間に均一に分散されますが、もしトークンがキー範囲を均等に分割できていなければノード間のアンバランスが発生するかもしれません。このような場合は!InitialTokenを`i
 * (2**127 / N)`　(i は 0 .. N-1)に設定する必要があるでしょう。Cassandra 
0.7では`cassandra.yaml`で`initial_token`を指定できます。
+ 
+ 
!NetworkTopologyStrategyを使う場合は、それぞれのデータセンター毎に別個にトークンを計算する必要があります。トークンはリング中で一意でなければならないので、2つめのデータセンターではトークンに1を追加、3つめのデータセンターでは2を追加などとするのがよいでしょう。従って2つのデータセンターにまたがる4ノードクラスターを構成する場合、次のようなトークン割り当てになるでしょう。
+ 
+ {{{
+ DC1
+ node 1 = 0
+ node 2 = 85070591730234615865843651857942052864
+ 
+ DC2
+ node 3 = 1
+ node 4 = 85070591730234615865843651857942052865
+ }}}
+ 
+ 
+ それぞれのデータセンターに同数のノードを配置する場合は、データセンターが交互に現れるようにトークンを割り当てるのもよいでしょう。
+ 
+ {{{
+ [DC1] node 1 = 0
+ [DC2] node 2 = 42535295865117307932921825928971026432
+ [DC1] node 3 = 85070591730234615865843651857942052864
+ [DC2] node 4 = 127605887595351923798765477786913079296
+ }}}
+ 
  
  
順序保存パーティショナではキーの分散度合いはアプリケーション依存になります。あなたはできるだけ適切な初期トークンを設定すべきですが（可能なら実データをサンプリングして決定した方がいいでしょう）、後述する能動的な負荷分散設定や、負荷集中箇所へのノード追加などに依存することも多いでしょう。
 
  
@@ -52, +75 @@

  レプリケーションファクターを減らすのは簡単です。レプリケーションファクターを減らした後、余分なレプリカデータを削除するためにcleanupを実行して下さい。
  
  
稼働中のクラスターのレプリケーションファクターを更新するには、cassandra.yamlのことは忘れて下さい。代わりに、'''cassandra-cli'''
 を使用して以下のコマンドを実行して下さい。
+ 
-   update keyspace Keyspace1 with replication_factor = 3;
+  . update keyspace Keyspace1 with replication_factor = 3;
  
  === ネットワークトポロジー ===
  
レプリケーションストラテジーによってデータセンター間のレプリカ配置を制御できますが、これに加えてデータセンター内でどのノードが同じラックに設置されているかをCassandraに認識させることができます。Cassandraはreadやトークン範囲変更のためのデータの移動の際にこの情報を使用して最も近いレプリカを使用します。近接ノード検出の挙動は設定ファイルで差し替え可能な!EndpointSnitchクラスで変更可能です。
@@ -101, +125 @@

  
  以下にトークンを再計算するためのpythonプログラムを示します。この話題についてはCassandra Summit 2010におけるBen 
Blackによるプレゼンテーションでさらに詳しく説明されています。http://www.datastax.com/blog/slides-and-videos-cassandra-summit-2010
  
-   def tokens(nodes):
+  . def tokens(nodes):
-   for x in xrange(nodes): 
+   . for x in xrange(nodes):
-   print 2 ** 127 / nodes * x
+. print 2 ** 127 / nodes * x
  
  Cassandra 0.7.*以降では`nodetool loadbalance`コマンドが用意されています。これは基本的には decomission と 
bootstrap を組み合わせたような機能で、ターゲットのノードに移動先のトークン値を指定する代わりに、auto bootstrap 
と同様のヒューリスティックなアルゴリズムに基づいて新しいトークン値を自動的に選択します。ただし、このコマンドではリング全体の負荷均等化はできません。
  
@@ -144, +168 @@

  このシナリオが発生した場合の対処として少なくとも3つの方法が考えられます。
  
   1. 疑わしいノードを障害ノードとみなし、後述する方法で入れ替えを行います。
-  2. 
削除の喪失を最小限にするため、まずGCGraceSecondsの値をクラスタ全体で増やします（ローリングリスタートが必要です）。すべてのノードでフルリペアを実施した後、GCGraceSecondsを元に戻します。この手法ではtombstoneを可能な限り再配布することになるため、「削除したはずのデータが復活する」現象を最小限にすることができます。
+  1. 
削除の喪失を最小限にするため、まずGCGraceSecondsの値をクラスタ全体で増やします（ローリングリスタートが必要です）。すべてのノードでフルリペアを実施した後、GCGraceSecondsを元に戻します。この手法ではtombstoneを可能な限り再配布することになるため、「削除したはずのデータが復活する」現象を最小限にすることができます。
-  3. もう一つのオプションは、単純に'nodetool 
repair'を全ノードで実施した後、compactionを実行してtombstoneをexpireするすることです。以降はread 
repairと通常の'nodetool 
repair'によってシステムの整合性が回復します。この方法は前の手法よりも実施が容易ですが、より多くの「削除の喪失」が発生することになるでしょう。
+  1. もう一つのオプションは、単純に'nodetool 
repair'を全ノードで実施した後、compactionを実行してtombstoneをexpireするすることです。以降はread 
repairと通常の'nodetool 
repair'によってシステムの整合性が回復します。この方法は前の手法よりも実施が容易ですが、より多くの「削除の喪失」が発生することになるでしょう。
  
  === ノード障害への対処 ===
  
ノードが一時的な停止の後で回復した場合にデータの整合性を回復するには通常のrepair機構で十分でしょう。しかし注意して頂きたいのは、ノードの停止中に更新が実行され、設定されたGCGraceSeconds（標準値は10日）以内にノードのrepairが行われなかった場合は、その期間の削除操作が完全に失われるということです。あなたのアプリケーションが削除をまったく行わないのでない限り、このようなケースでは障害ノードのデータを完全に削除し、再ブートストラップし、従来使用していたトークンについてremovetokenを実行する必要があります（下記を参照）。
@@ -222, +246 @@

  `nodetool 
cfstats`を実行するとカラムファミリごとの概略とクラスタの状態を示す主要な統計情報を取得できます。JMX以外のクライアントを使いたい場合には、JMXからRESTへのブリッジが利用可能です。http://code.google.com/p/polarrose-jmx-rest-bridge/
  
  カラムファミリ単位の主要統計情報には次のような情報が含まれます: '''Read Count、Read Latency、Write Count、Write 
Latency'''
- '''Pending 
Tasks'''を見ると滞留しているタスクを知ることができます。これらの統計情報は`jconsole`のようなJMXクライアントでも確認できます。（JConsoleをファイアウォールの背後のマシンにプロキシするためには
 
[[http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html]]を参照して下さい。）
+ '''Pending 
Tasks'''を見ると滞留しているタスクを知ることができます。これらの統計情報は`jconsole`のようなJMXクライアントでも確認できます。（JConsoleをファイアウォールの背後のマシンにプロキシするためには
 http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html を参照して下さい。）
  
  
スレッドプールのPendingTaskはconsoleのMBeansタブでも確認できます。もし特定のスレッドが滞留している場合、何か問題が発生している可能性があります。例えばROW-MUTATION-STAGEで滞留している場合、流入するwriteリクエストが多すぎて処理が追いついていないことを示します。より精妙な例はFLUSHステージです。FLUSHステージで滞留が発生している場合、Cassandraはwriteを十分に速くメモリに読み込んでいますが、ソート・ディスクへの書き込みで遅延が発生していることを示しています。
  
@@ -260, +284 @@

   * http://mx4j.sourceforge.net/ から mx4j-tools.jar をダウンロードします。
   * mx4j-tools.jar をclasspathに追加します。（lib/ の下など）
   * Cassandraを起動します。
-  * ログにHttp``Atapter started on port 8081のようなメッセージが出力されていることを確認します。
+  * ログにHttpAtapter started on

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-05-11 Thread Apache Wiki 
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: Sync to EN#89.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=107&rev2=108

--

  ## page was copied from Operations
+ 
  <>
  
  == ハードウェア ==
@@ -10, +11 @@

  [[PerformanceTuning_JP|PerformanceTuning]]を参照して下さい。
  
  == スキーマ管理 ==
+ ノードのクロックをntpなどで同期して下さい。クロックが同期していない場合、更新時刻のずれによってスキーマ変更が無効と見なされる可能性があります。
  [[LiveSchemaUpdates_JP|LiveSchemaUpdates]]を参照して下さい。[0.7で導入された機能]
  
  == リング管理 ==
@@ -28, +30 @@

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

  
  * 
これらの議論の帰結として、次のことが言えます。複数のデータセンターを同時に構築しない場合、即ち最初に一つ目のデータセンターを構築し、後で二つ目を追加する場合、二つ目のデータセンターでは徐々にノードを追加していくのではなく、一つ目のデータセンターと同数のノードを一度に設置すべきです。
  
- レプリケーションファクタを稼働中のグラスタで変更することは想定していません。しかし以下のいずれかの方法によりレプリケーションファクタを増やすことができます。
+ 
稼働中のクラスターでレプリケーションファクターを変更することは想定されていませんが、コンセプト的には単純です。CLIからreplication_factorを更新（後述）した後、新しいレプリカ定義に基づいてそれぞれのノードに適切なデータを格納させるために、クラスターの各ノードに対してrepairを実行してください。
  
-  a. ConsistencyLevel.QUORUM または ALL で read 
することにより（どちらを使うかは既存のレプリケーションファクタに依ります）、実データを保持しているノードからデータを複製する
-  a. ダウンタイムを許容できるならanti-entropyを実行する（下記参照）
-  a. もしくはリペアが完了するまで、新たなレプリケーション先への read に対してクライアントに「no data exists」が返る可能性を許容する
- 
+ Repairが完了するまで、3つの選択肢があります。
+  * レプリカ間でデータが整合していることを保証するため、ConsistencyLevel=QUORUMまたはALLでReadを行う
+  * 
より低いConsitencyLevelでReadする代わり、いくつかのリクエストが失敗することを許容する。（ReadRepairが設定されている場合、通常は最初のクエリだけが失敗するはずです）
+  * Repairが完了するまで、サービスのダウンタイムを設ける
  
  レプリケーションストラテジを変更する場合も同じ選択肢が適用されます。
  
- レプリケーションファクタを減らすのは簡単です。レプリケーションファクタを減らした後、余分なレプリカデータを削除するためにcleanupを実行して下さい。
+ レプリケーションファクターを減らすのは簡単です。レプリケーションファクターを減らした後、余分なレプリカデータを削除するためにcleanupを実行して下さい。
+ 
+ 
稼働中のクラスターのレプリケーションファクターを更新するには、cassandra.yamlのことは忘れて下さい。代わりに、'''cassandra-cli'''
 を使用して以下のコマンドを実行して下さい。
+   update keyspace Keyspace1 with replication_factor = 3;
  
  === ネットワークトポロジー ===
  
レプリケーションストラテジーによってデータセンター間のレプリカ配置を制御できますが、これに加えてデータセンター内でどのノードが同じラックに設置されているかをCassandraに認識させることができます。Cassandraはreadやトークン範囲変更のためのデータの移動の際にこの情報を使用して最も近いレプリカを使用します。近接ノード検出の挙動は設定ファイルで差し替え可能な!EndpointSnitchクラスで変更可能です。
@@ -100, +105 @@

for x in xrange(nodes): 
print 2 ** 127 / nodes * x
  
- `nodetool 
loadbalance`は指定ノードに対してトークン選択の項で説明した自動トークン選択ルールに基づいて新たなトークンを決定し、decomissionとbootstrapを実行するコマンドです。このコマンドではリング全体の負荷均等化は行えません。
+ Cassandra 0.7.*以降では`nodetool loadbalance`コマンドが用意されています。これは基本的には decomission と 
bootstrap を組み合わせたような機能で、ターゲットのノードに移動先のトークン値を指定する代わりに、auto bootstrap 
と同様のヒューリスティックなアルゴリズムに基づいて新しいトークン値を自動的に選択します。ただし、このコマンドではリング全体の負荷均等化はできません。
  
- 移動やデータ格納量の均等化状況はnodetoolのnetstats引数(0.7以降)またはstreams 引数(Cassandra 0.6)で監視できます。
+ moveやloadbalance操作の進捗状況は`nodetool netstat`コマンドで確認できます。(Cassandra 0.6.* 以前では 
`streams` コマンドを使用します。)
+ 
  
  == 整合性 ==
  
Cassandraではreadやwriteにおいて必要な整合性レベルをクライアントが指定できます([[API]]参照）。R、W、Nがそれぞれ読み出したレプリカ数、書き込んだレプリカ数、レプリケーションファクターを示すとすると、R
 + W > N であればすべての read は最新の write を読むことができます。この条件を満たさない場合、タイミングによっては read 
は古いデータを返すかもしれません。これは結果整合性"evantual consistency"と呼ばれています。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-04-21 Thread Apache Wiki 
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=106&rev2=107

--

  
  `nodetool 
loadbalance`は指定ノードに対してトークン選択の項で説明した自動トークン選択ルールに基づいて新たなトークンを決定し、decomissionとbootstrapを実行するコマンドです。このコマンドではリング全体の負荷均等化は行えません。
  
- 移動やデータ格納量の均等化状況は`nodetool`に`streams`引数を与えることで監視できます。
+ 移動やデータ格納量の均等化状況はnodetoolのnetstats引数(0.7以降)またはstreams 引数(Cassandra 0.6)で監視できます。
  
  == 整合性 ==
  
Cassandraではreadやwriteにおいて必要な整合性レベルをクライアントが指定できます([[API]]参照）。R、W、Nがそれぞれ読み出したレプリカ数、書き込んだレプリカ数、レプリケーションファクターを示すとすると、R
 + W > N であればすべての read は最新の write を読むことができます。この条件を満たさない場合、タイミングによっては read 
は古いデータを返すかもしれません。これは結果整合性"evantual consistency"と呼ばれています。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-03-11 Thread Apache Wiki 
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: Update links to translated pages.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=101&rev2=102

--

   1. 
安全のため、トークン範囲の変更により担当から外れ、他のノードに移動したデータの自動削除は行われません。追加したノードがレプリカデータを取得し、正しく動作しているのを確認してからすべてのソースノード（同じトークン範囲を担当していたノード）で
 `nodetool cleanup` 
を実行して下さい。cleanupを実行しないかぎり、古いデータもノードの負荷の一部とみなされます。この状態で新たなブートストラップを行うと、新規ノードの自動トークン選択に影響を与えます。
   1. 
新規ノードのブートストラップを行う場合、既存ノードはレプリケーションを始める前にキー空間を分割する必要があります。これにはある程度の時間がかかります。
   1. ブートストラップ中のノードはThriftポートを閉塞するため、 `nodetool`からアクセス不能になります。
-  1. 大量のデータを移動する必要がある場合、ブートストラップは何時間にも及ぶ可能性があります。 
ブートストラップの進捗を確認するには[[Streaming]]を参照して下さい。
+  1. 大量のデータを移動する必要がある場合、ブートストラップは何時間にも及ぶ可能性があります。 
ブートストラップの進捗を確認するには[[Streaming_JP|Streaming]]を参照して下さい。
  
  
!EndpointSnitchが正しく構成されていればCassandraは自律的に近接ノードを判別してデータを転送します。従って対象キー範囲のレプリカノードの一つが同じデータセンターにある限り、追加ノードをプライマリレプリカノードと同じデータセンターに設置する必要性はありません。
  
@@ -88, +88 @@

  === ノードの移動 ===
  `nodetool move`: 
ノードを指定したトークンに移動します。この操作は基本的にはdecommissionとbootstrapを組み合わせたものです。
  
- ブートストラップの進捗確認については, [[Streaming]]を参照して下さい。
+ ブートストラップの進捗確認については, [[Streaming_JP|Streaming]]を参照して下さい。
  
  === 負荷分散 ===
  
単純にノードを追加した場合、クラスタリングのデータ格納バランスは不均等になるでしょう。これを調整して均等な格納バランスを得るためには、すべてのノードのトークンを計算し直し、`nodetool
 move`コマンドによってトークンを割り当て直す必要があります。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-03-11 Thread Apache Wiki 
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=100&rev2=101

--

  
  === nodetool repairの頻度 ===
  
- あなたのアプリケーションが削除をまったく行わないのでない限り、本番環境のクラスタのすべてのノードで定期的に`nodetool 
repair`を実行することは不可欠です。repairの実行間隔の上限はGCGraceSecondsの設定値によって決まります（[[DistributedDeletes|DistributedDelete]]
 
参照）。削除指示されたデータについて「削除の喪失」が発生しないようにするためには、すべてのノードでGCGraceSecondsで指定された期間の間に確実にrepairを実施する必要があります。
+ あなたのアプリケーションが削除をまったく行わないのでない限り、本番環境のクラスタのすべてのノードで定期的に`nodetool 
repair`を実行することは不可欠です。repairの実行間隔の上限はGCGraceSecondsの設定値によって決まります（[[DistributedDeletes_JP|DistributedDelete]]
 
参照）。削除指示されたデータについて「削除の喪失」が発生しないようにするためには、すべてのノードでGCGraceSecondsで指定された期間の間に確実にrepairを実施する必要があります。
  
  
repairの実行スケジュールはよく検討してください。repairに関与するノードでは余分のdiskおよびCPU消費が発生するので、一般的にはrepairの実施を時間的に分散するのが良いでしょう。これによりrepairが多くのノードで同時に実行される可能性を減らすことができます。
  
   GCGraceSeconds以内にnodetool repairが実施されなかった場合の対処 
  
- GCGraceSecondsが経過するまでに`nodetool repair`が一度も実行されない場合、「削除の喪失」が発生する可能性があります 
（[[DistributedDeletes]]参照）。
+ GCGraceSecondsが経過するまでに`nodetool repair`が一度も実行されない場合、「削除の喪失」が発生する可能性があります 
（[[DistributedDeletes_JP|DistributedDelete]]参照）。
  
このようなケースでは、削除したはずのデータが再び現れる可能性に加えて、複数のレプリカノードから返される値に不整合が発生するかもしれません。このような不整合はread
 repairや`nodetool 
repair`では解消されません。後者の問題については[[https://issues.apache.org/jira/browse/CASSANDRA-1316|CASSANDRA-1316]]に詳説されています。
  
  このシナリオが発生した場合の対処として少なくとも3つの方法が考えられます。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-03-11 Thread Apache Wiki 
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: Update links to translated pages.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=99&rev2=100

--

  [[CassandraHardware_JP|CassandraHardware]]を参照して下さい。
  
  == チューニング ==
- PerformanceTuningを参照して下さい。
+ [[PerformanceTuning_JP|PerformanceTuning]]を参照して下さい。
  
  == スキーマ管理 ==
- LiveSchemaUpdatesを参照して下さい。[0.7で導入された機能]
+ [[LiveSchemaUpdates_JP|LiveSchemaUpdates]]を参照して下さい。[0.7で導入された機能]
  
  == リング管理 ==
  
それぞれのCassandraサーバ（ノード）には、そのホストを最初のレプリカ先として使用するキーを決定するためのトークンが割り当てられます。ノードのトークンでソートした場合、あるノードが担当するキー範囲は（前のノードのトークン、自ノードのトークン]です。即ち、「前の」トークン（その値は含まない）から自分のトークン（値を含む）までの間隔です。リングの中で最も小さいトークンを持つノードはそのトークン値以下のキーに加えて、最大のトークンよりも大きいすべてのキーを担当します。これは"範囲ラップ"と呼ばれています。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-03-07 Thread Apache Wiki 
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: Update for 0.7 nodetool.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=98&rev2=99

--

  
  
   1. Read Repair: 
readが実行される度、Cassandraはレプリカされたデータ間のバージョン確認を行い、古いデータを持つノードに最新のデータを配布します。クライアントから整合性要求レベルが低いリクエストを受け取った場合は、遅延を最小化するためにバージョン比較はバックグラウンドで実施されます。
-  1. Anti-Entropy:  `nodetool 
repair`を実行するとCassandraは直近で参照されておらず、同期されていないデータを検出するため、そのノードに格納されているデータのMerkle 
treeを計算し、他のレプリカノードと比較します。Merkle 
treeの計算にはノード上の全データのスキャンが必要であるため、ディスクI/OやCPUを多く消費します（ネットワーク帯域の観点からは効率的です）。 
このため`nodetool repair`をあまり頻繁に実行することは設計時に想定されていません。
+  1. Anti-Entropy:  `nodetool 
repair`を実行すると、直近で参照されておらず、同期されていないデータを検出するため、Cassandraはそのノードに格納されているデータ範囲のMerkle
 treeを計算し、他のレプリカノードと比較します。Merkle 
treeの計算にはノード上の全データのスキャンが必要であるため、ディスクI/OやCPUを多く消費します（ネットワーク帯域の観点からは効率的です）。 
このため`nodetool repair`をあまり頻繁に実行することは設計時に想定されていません。
  
+ `nodetool repair`の実行: 0.7の他のnodetool 操作と同様、repairはブロックします: 
即ち、nodetoolはリペアが完了するまで待ち、その後exitします。リペア対象となるデータセットが大きい場合、リペアには長い時間がかかります。
+ 
複数ノードで同時にリペアをかけても安全です。ただしアプリケーション負荷への影響を最小化する為には、一つのノードのリペアが完了してから次のノードでリペアを開始することをお勧めします。
  
- `nodetool repair`の実行: 他のnodetool 
操作と同様に、repairはノンブロックな操作です。nodetoolは指定されたノードにコマンドを送りますが、リペアが完了するまで待ちません。次の条件が整った時点でリペアが完了したことを知ることができます:
 (a) CompactionManagerにアクティブなタスクもペンディングタスクも残っていないこと、次に(b) 
o.a.c.concurrent.AE-SERVICE-STAGE、o.a.c.service.StreamingServiceのどちらにもアクティブなタスクもペンディングタスクも残っていないこと。
- 
- 
- リペアは一度に一台のノードで実行すべきです。 (この制限は0.7で取り除かれています。)
  
  === nodetool repairの頻度 ===

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-03-07 Thread Apache Wiki 
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=96&rev2=97

--

  
  
   1. Read Repair: 
readが実行される度、Cassandraはレプリカされたデータ間のバージョン確認を行い、古いデータを持つノードに最新のデータを配布します。クライアントから整合性要求レベルが低いリクエストを受け取った場合は、遅延を最小化するためにバージョン比較はバックグラウンドで実施されます。
-  1. Anti-Entropy:  `nodetool 
repair`を実行するとCassandraは直近で参照されておらず、同期されていないデータを検出するため、そのノードに格納されているデータのMerkle 
treeを計算し、他のレプリカノードと比較します。Merkle 
treeの計算にはノード上の全データのスキャンが必要であるため、ディスクI/OやCPUを多く消費します（ネットワーク帯域の観点からは効率的です）。 
このため`nodetool repair`をあまり頻繁に実行することは設計時に想定されていません。
+  1. Anti-Entropy:  `nodetool 
repair`を実行すると、直近で参照されておらず、同期されていないデータを検出するため、Cassandraはそのノードに格納されているデータ範囲のMerkle
 treeを計算し、他のレプリカノードと比較します。Merkle 
treeの計算にはノード上の全データのスキャンが必要であるため、ディスクI/OやCPUを多く消費します（ネットワーク帯域の観点からは効率的です）。 
このため`nodetool repair`をあまり頻繁に実行することは設計時に想定されていません。
  
+ `nodetool repair`の実行: 0.7の他のnodetool 操作と同様、repairはブロックします: 
即ち、nodetoolはリペアが完了するまで待ち、その後exitします。リペア対象となるデータセットが大きい場合、リペアには長い時間がかかります。
+ 
複数ノードで同時にリペアをかけても安全です。ただしアプリケーション負荷への影響を最小化する為には、一つのノードのリペアが完了してから次のノードでリペアを開始することをお勧めします。
- 
- `nodetool repair`の実行: 他のnodetool 
操作と同様に、repairはノンブロックな操作です。nodetoolは指定されたノードにコマンドを送りますが、リペアが完了するまで待ちません。次の条件が整った時点でリペアが完了したことを知ることができます:
 (a) CompactionManagerにアクティブなタスクもペンディングタスクも残っていないこと、次に(b) 
o.a.c.concurrent.AE-SERVICE-STAGE、o.a.c.service.StreamingServiceのどちらにもアクティブなタスクもペンディングタスクも残っていないこと。
- 
- 
- リペアは一度に一台のノードで実行すべきです。 (この制限は0.7で取り除かれています。)
  
  === nodetool repairの頻度 ===

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-20 Thread Apache Wiki 
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: Translation to Japanese completed.
http://wiki.apache.org/cassandra/Operations_JP?action=diff&rev1=95&rev2=96

--

  注意: バージョン0.7より、json2sstableとsstable2jsonはschemaをsystem 
tableからロードできるような環境で実行する必要があります。これはcassandra.yamlファイルがclasspath上に存在し、適切なストレージディレクトリを参照するように構成されていることを意味します。
  
  == 監視 ==
+ 
Cassandraは内部の統計情報をJMXデータとして公開しています。これはJVMの世界では一般的です。程度に差はあるもののOpenNMS、Nagios、MuninでJMXがサポートされています。JMXインターフェースの仕様はJmxInterfaceで解説されています。
- Cassandraは内部の統計情報をJMXデータとして公開しています。これはJVMの世界では一般的です。OpenNMS、Nagios
- Cassandra exposes internal metrics as JMX data.  This is a common standard in 
the JVM world; OpenNMS, Nagios, and Munin at least offer some level of JMX 
support. The specifics of the JMX Interface are documented at JmxInterface.
  
- Running `nodetool cfstats` can provide an overview of each Column Family, and 
important metrics to graph your cluster. Some folks prefer having to deal with 
non-jmx clients, there is a JMX-to-REST bridge available at 
http://code.google.com/p/polarrose-jmx-rest-bridge/
+ `nodetool 
cfstats`を実行するとカラムファミリごとの概略とクラスタの状態を示す主要な統計情報を取得できます。JMX以外のクライアントを使いたい場合には、JMXからRESTへのブリッジが利用可能です。http://code.google.com/p/polarrose-jmx-rest-bridge/
  
- Important metrics to watch on a per-Column Family basis would be: '''Read 
Count, Read Latency, Write Count and Write Latency'''. '''Pending Tasks''' tell 
you if things are backing up. These metrics can also be exposed using any JMX 
client such as `jconsole`.  (See also 
[[http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html]] for how 
to proxy JConsole to firewalled machines.)
+ カラムファミリ単位の主要統計情報には次のような情報が含まれます: '''Read Count、Read Latency、Write Count、Write 
Latency'''
+ '''Pending 
Tasks'''を見ると滞留しているタスクを知ることができます。これらの統計情報は`jconsole`のようなJMXクライアントでも確認できます。（JConsoleをファイアウォールの背後のマシンにプロキシするためには
 
[[http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html]]を参照して下さい。）
  
- You can also use jconsole, and the MBeans tab to look at PendingTasks for 
thread pools. If you see one particular thread backing up, this can give you an 
indication of a problem. One example would be ROW-MUTATION-STAGE indicating 
that write requests are arriving faster than they can be handled. A more subtle 
example is the FLUSH stages: if these start backing up, cassandra is accepting 
writes into memory fast enough, but the sort-and-write-to-disk stages are 
falling behind.
+ 
スレッドプールのPendingTaskはconsoleのMBeansタブでも確認できます。もし特定のスレッドが滞留している場合、何か問題が発生している可能性があります。例えばROW-MUTATION-STAGEで滞留している場合、流入するwriteリクエストが多すぎて処理が追いついていないことを示します。より精妙な例はFLUSHステージです。FLUSHステージで滞留が発生している場合、Cassandraはwriteを十分に速くメモリに読み込んでいますが、ソート・ディスクへの書き込みで遅延が発生していることを示しています。
  
- If you are seeing a lot of tasks being built up, your hardware or 
configuration tuning is probably the bottleneck.
+ 大量のタスクが滞留しているなら、おそらくハードウェアかパラメータチューニングがボトルネックです。
  
- Running `nodetool tpstats` will dump all of those threads to console if you 
don't want to use jconsole. Example:
+ jconsoleを使いたくないのであれば、`nodetool tpstats`を実行することですべてのスレッドをダンプ出力できます。
  
+ 例:
  {{{
  Pool NameActive   Pending  Completed
  FILEUTILS-DELETE-POOL 0 0119
@@ -248, +249 @@

  HINTED-HANDOFF-POOL   0 0154
  }}}
  
- == Monitoring with MX4J ==
- mx4j provides an HTML and HTTP interface to JMX. Starting from version 0.7.0 
cassandra lets you hook up mx4j very easily.
- To enable mx4j on a Cassandra node:
-  * Download mx4j-tools.jar from http://mx4j.sourceforge.net/
-  * Add mx4j-tools.jar to the classpath (e.g. under lib/)
-  * Start cassandra
-  * In the log you should see a message such as Http``Atapter started on port 
8081
-  * To choose a different port (8081 is the default) or a different listen 
address (0.0.0.0 is not the default) edit conf/cassandra-env.sh and uncomment 
#MX4J_ADDRESS="-Dmx4jaddress=0.0.0.0" and #MX4J_PORT="-Dmx4jport=8081"
+ == MX4Jによる監視 ==
+ mx4jはJMXへのHTMLおよびHTTPインターフェースを提供します。Cassandra 0.7.0よりmx4jをより簡単に統合できます。
+ Cassandraノードでmx4jを有効にする手順は次の通りです:
+  * http://mx4j.sourceforge.net/ から mx4j-tools.jar をダウンロードします。
+  * mx4j-tools.jar をclasspathに追加します。（lib/ の下など）
+  * Cassandraを起動します。
+  * ログにHttp``Atapter started on port 8081のようなメッセージが出力されていることを確認します。
+  * 
標準ポート（8081）以外のポートや、標準アドレス（0.0.0.0）以外でlistenしたい場合はconf/cassandra-env.shを編集し、#MX4J_ADDRESS="-Dmx4jaddress=0.0.0.0"
 and #MX4J_PORT="-Dmx4jport=8081" がコメントアウトされている部分を戻して下さい。
  
- Now browse to http://cassandra:8081/ and use the HTML interface.
+ http://cassandra:8081/ にアクセスすればHTMLインターフェースが使用できます。
  
- If you want XML then add &template=identity to the end of any URL, e.g. 
http://cassandra:8081/?&template=identity
+ XMLが必要ならURLの最後に&template=identityを追加して下さい。（例: 
http://cassandra:8081/?&template=identity ）
  
- For more details see https

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-18 Thread Apache Wiki 
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=94&rev2=95

--

  
  リペアは一度に一台のノードで実行すべきです。 (この制限は0.7で取り除かれています。)
  
- === Frequency of nodetool repair ===
+ === nodetool repairの頻度 ===
  
- Unless your application performs no deletes, it is vital that production 
clusters run `nodetool repair` periodically on all nodes in the cluster. The 
hard requirement for repair frequency is the value used for GCGraceSeconds (see 
[[DistributedDeletes]]). Running nodetool repair often enough to guarantee that 
all nodes have performed a repair in a given period GCGraceSeconds long, 
ensures that deletes are not "forgotten" in the cluster.
+ あなたのアプリケーションが削除をまったく行わないのでない限り、本番環境のクラスタのすべてのノードで定期的に`nodetool 
repair`を実行することは不可欠です。repairの実行間隔の上限はGCGraceSecondsの設定値によって決まります（[[DistributedDeletes|DistributedDelete]]
 
参照）。削除指示されたデータについて「削除の喪失」が発生しないようにするためには、すべてのノードでGCGraceSecondsで指定された期間の間に確実にrepairを実施する必要があります。
  
- Consider how to schedule your repairs. A repair causes additional disk and 
CPU activity on the nodes participating in the repair, and it will typically be 
a good idea to spread repairs out over time so as to minimize the chances of 
repairs running concurrently on many nodes.
+ 
repairの実行スケジュールはよく検討してください。repairに関与するノードでは余分のdiskおよびCPU消費が発生するので、一般的にはrepairの実施を時間的に分散するのが良いでしょう。これによりrepairが多くのノードで同時に実行される可能性を減らすことができます。
  
-  Dealing with the consequences of nodetool repair not running within 
GCGraceSeconds 
+  GCGraceSeconds以内にnodetool repairが実施されなかった場合の対処 
  
- If `nodetool repair` has not been run often enough to the pointthat 
GCGraceSeconds has passed, you risk forgotten deletes (see 
[[DistributedDeletes]]). In addition to data popping up that has been deleted, 
you may see inconsistencies in data return from different nodes that will not 
self-heal by read-repair or further `nodetool repair`. Some further details on 
this latter effect is documented in 
[[https://issues.apache.org/jira/browse/CASSANDRA-1316|CASSANDRA-1316]].
+ GCGraceSecondsが経過するまでに`nodetool repair`が一度も実行されない場合、「削除の喪失」が発生する可能性があります 
（[[DistributedDeletes]]参照）。
+ 
このようなケースでは、削除したはずのデータが再び現れる可能性に加えて、複数のレプリカノードから返される値に不整合が発生するかもしれません。このような不整合はread
 repairや`nodetool 
repair`では解消されません。後者の問題については[[https://issues.apache.org/jira/browse/CASSANDRA-1316|CASSANDRA-1316]]に詳説されています。
  
- There are at least three ways to deal with this scenario.
+ このシナリオが発生した場合の対処として少なくとも3つの方法が考えられます。
  
-  1. Treat the node in question as failed, and replace it as described further 
below.
-  2. To minimize the amount of forgotten deletes, first increase 
GCGraceSeconds across the cluster (rolling restart required), perform a full 
repair on all nodes, and then change GCRaceSeconds back again. This has the 
advantage of ensuring tombstones spread as much as possible, minimizing the 
amount of data that may "pop back up" (forgotten delete).
-  3. Yet another option, that will result in more forgotten deletes than the 
previous suggestion but is easier to do, is to ensure 'nodetool repair' has 
been run on all nodes, and then perform a compaction to expire toombstones. 
Following this, read-repair and regular `nodetool repair` should cause the 
cluster to converge.
+  1. 疑わしいノードを障害ノードとみなし、後述する方法で入れ替えを行います。
+  2. 
削除の喪失を最小限にするため、まずGCGraceSecondsの値をクラスタ全体で増やします（ローリングリスタートが必要です）。すべてのノードでフルリペアを実施した後、GCGraceSecondsを元に戻します。この手法ではtombstoneを可能な限り再配布することになるため、「削除したはずのデータが復活する」現象を最小限にすることができます。
+  3. もう一つのオプションは、単純に'nodetool 
repair'を全ノードで実施した後、compactionを実行してtombstoneをexpireするすることです。以降はread 
repairと通常の'nodetool 
repair'によってシステムの整合性が回復します。この方法は前の手法よりも実施が容易ですが、より多くの「削除の喪失」が発生することになるでしょう。
  
- === Handling failure ===
- If a node goes down and comes back up, the ordinary repair mechanisms will be 
adequate to deal with any inconsistent data.  Remember though that if a node 
misses updates and is not repaired for longer than your configured 
GCGraceSeconds (default: 10 days), it could have missed remove operations 
permanently.  Unless your application performs no removes, you should wipe its 
data directory, re-bootstrap it, and removetoken its old entry in the ring (see 
below).
+ === ノード障害への対処 ===
+ 
ノードが一時的な停止の後で回復した場合にデータの整合性を回復するには通常のrepair機構で十分でしょう。しかし注意して頂きたいのは、ノードの停止中に更新が実行され、設定されたGCGraceSeconds（標準値は10日）以内にノードのrepairが行われなかった場合は、その期間の削除操作が完全に失われるということです。あなたのアプリ-ションが削除をまったく行わないのでない限り、このようなケースでは障害ノードのデータを完全に削除し、再ブートストラップし、従来使用していたトークンについてremovetokenを実行する必要があります（下記を参照）。
  
- If a node goes down entirely, then you have two options:
+ ノードが完全に停止し、回復の見込みがない場合は、2つの選択肢があります:
  
-  1. (Recommended approach) Bring up the replacement node with a new IP 
address, and !AutoBootstrap set to true in storage-conf.xml. This will place 
the replacement node in the cluster and find the appropriate position 
automatically. Then the bootstrap proce

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-18 Thread Apache Wiki 
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 ===

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-17 Thread Apache Wiki 
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=91&rev2=92

--

  
  
ブートストラップ中に`nodetool`で監視していると追加したノードがデータストリームの送受信をしていないように見える場合があるかもしれません。これはソースノードが送信ストリーム用のデータをローカルで取り出している最中に発生します。この場合はソースノードに"!AntiCompacting...
 !AntiCompacted"というログが出力されます。
  
- == Moving or Removing nodes ==
- === Removing nodes entirely ===
- You can take a node out of the cluster with `nodetool decommission` to a live 
node, or `nodetool removetoken` (to any other machine) to remove a dead one.  
This will assign the ranges the old node was responsible for to other nodes, 
and replicate the appropriate data there. If `decommission` is used, the data 
will stream from the decommissioned node. If `removetoken` is used, the data 
will stream from the remaining replicas.
+ == ノードの移動と削除 ==
+ === ノードの削除 ===
+ 稼働中のノードをクラスタから取り除くには`nodetool 
decommission`を実行します。停止中のノードをクラスタから取り除くには稼働中のノードで`nodetool 
removetoken`を実行し、削除対象ノードのトークンを指定します。削除されたノードが担当していたキー範囲は稼働中のノードに割り当てられ、データのレプリケートが実施されます。`decommission`を実行した場合はdecomissionされるノードから新しい担当ノードにデータ転送されます。`removetoken`を実施した場合は残存するレプリカノードから新しい担当ノードにデータ転送されます。
  
- No data is removed automatically from the node being decommissioned, so if 
you want to put the node back into service at a different token on the ring, it 
should be removed manually.
+ 
データはdecomissionされるノードから自動削除されません。もしそのノードを別のトークンを指定してクラスタに再接続する場合は、あらかじめ手動でデータを削除して下さい。
  
- === Moving nodes ===
- `nodetool move`: move the target node to a given Token. Moving is essentially 
a convenience over decommission + bootstrap.
+ === ノードの移動 ===
+ `nodetool move`: 
ノードを指定したトークンに移動します。この操作は基本的にはdecommissionとbootstrapを組み合わせたものです。
  
- As with bootstrap, see [[Streaming]] for how to monitor progress.
+ ブートストラップの進捗確認については, [[Streaming]]を参照して下さい。
  
- === Load balancing ===
- If you add nodes to your cluster your ring will be unbalanced and only way to 
get perfect balance is to compute new tokens for every node and assign them to 
each node manually by using nodetool move command.
+ === 負荷分散 ===
+ 
単純にノードを追加した場合、クラスタリングのデータ格納バランスは不均等になるでしょう。これを調整して均等な格納バランスを得るためには、すべてのノードのトークンを計算し直し、`nodetool
 move`コマンドによってトークンを割り当て直すしかありません。
  
- Here's a python program which can be used to calculate new tokens for the 
nodes. There's more info on the subject at Ben Black's presentation at 
Cassandra Summit 2010. 
http://www.datastax.com/blog/slides-and-videos-cassandra-summit-2010
+ 以下にトークンを再計算するためのpythonプログラムを示します。この話題についてはCassandra Summit 2010におけるBen 
Blackによるプレゼンテーションでさらに詳しく説明されています。http://www.datastax.com/blog/slides-and-videos-cassandra-summit-2010
  
def tokens(nodes):
for x in xrange(nodes): 
print 2 ** 127 / nodes * x
  
- There's also `nodetool loadbalance`: essentially a convenience over 
decommission + bootstrap, only instead of telling the target node where to move 
on the ring it will choose its location based on the same heuristic as Token 
selection on bootstrap. You should not use this as it doesn't rebalance the 
entire ring.
+ `nodetool 
loadbalance`は指定ノードに対してトークン選択の項で説明した自動トークン選択ルールに基づいて新たなトークンを決定し、decomissionとbootstrapを実行するコマンドです。このコマンドではリング全体の負荷均等化は行えません。
  
- The status of move and balancing operations can be monitored using `nodetool` 
with the `streams` argument.
+ 移動やデータ格納量の均等化状況は`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 Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-17 Thread Apache Wiki 
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`で監視していると追加したノードがデータストリームの送受信をしていない

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-16 Thread Apache Wiki 
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=88&rev2=89

--

  レプリケーションファクタを減らすのは簡単です。レプリケーションファクタを減らした後、余分なレプリカデータを削除するためにcleanupを実行して下さい。
  
  === ネットワークトポロジー ===
- 
レプリケーションストラテジーによってデータセンター間のレプリカ配置を制御できますが、これに加えてできますが、データセンター内でどのノードが同じラックに設置されているかをCassandraに認識させることができます。Cassandraはreadやレンジ変更のためのデータの移動の際にこの情報を使用して最も近いレプリカを使用します。近接ノード検出の挙動は設定ファイルで差し替え可能な!EndpointSnitchクラスで変更可能です。
+ 
レプリケーションストラテジーによってデータセンター間のレプリカ配置を制御できますが、これに加えてできますが、データセンター内でどのノードが同じラックに設置されているかをCassandraに認識させることができます。Cassandraはreadやトークン範囲変更のためのデータの移動の際にこの情報を使用して最も近いレプリカを使用します。近接ノード検出の挙動は設定ファイルで差し替え可能な!EndpointSnitchクラスで変更可能です。
  
  
!EndpointSnitchはレプリケーションストラテジーに関係していますが、レプリケーションストラテジーそのものとは異なるものです。!RackAwareStrategyが適切にレプリカを配置するには正しく構成されたSnitch
  が必要です。しかしデータセンターを意識したレプリケーションストラテジーを使用しない場合もCassandraはノード間の近接情報を必要としています。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-16 Thread Apache Wiki 
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=87&rev2=88

--

  
  レプリケーションファクタを減らすのは簡単です。レプリケーションファクタを減らした後、余分なレプリカデータを削除するために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.
+ === ネットワークトポロジー ===
+ 
レプリケーションストラテジーによってデータセンター間のレプリカ配置を制御できますが、これに加えてできますが、データセンター内でどのノードが同じラックに設置されているかをCassandraに認識させることができます。Cassandraはreadやレンジ変更のためのデータの移動の際にこの情報を使用して最も近いレプリカを使用します。近接ノード検出の挙動は設定ファイルで差し替え可能な!EndpointSnitchクラスで変更可能です。
  
- !EndpointSnitch is related to, but distinct from, replication strategy 
itself: !RackAwareStrategy needs a properly configured Snitch to place replicas 
correctly, but even absent a Strategy that cares about datacenters, the rest of 
Cassandra will still be location-sensitive.
+ 
!EndpointSnitchはレプリケーションストラテジーに関係していますが、レプリケーションストラテジーそのものとは異なるものです。!RackAwareStrategyが適切にレプリカを配置するには正しく構成されたSnitch
+ が必要です。しかしデータセンターを意識したレプリケーションストラテジーを使用しない場合もCassandraはノード間の近接情報を必要としています。
  
- There is an example of a custom Snitch implementation in 
http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.1/contrib/property_snitch/.
+ カスタムスニッチの実装例が次のリンクで紹介されています。 
http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.6.1/contrib/property_snitch/
  
  == Range changes ==
  === Bootstrap ===

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-15 Thread Apache Wiki 
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=86&rev2=87

--

  
  レプリケーションファクタを稼働中のグラスタで変更することは想定していません。しかし以下のいずれかの方法によりレプリケーションファクタを増やすことができます。
  
-  a ConsistencyLevel.QUORUM または ALL で read 
することにより（どちらを使うかは既存のレプリケーションファクタに依ります）、実データを保持しているノードからデータを複製する
+  a. ConsistencyLevel.QUORUM または ALL で read 
することにより（どちらを使うかは既存のレプリケーションファクタに依ります）、実データを保持しているノードからデータを複製する
-  a ダウンタイムを許容できるならanti-entropyを実行する（下記参照）
+  a. ダウンタイムを許容できるならanti-entropyを実行する（下記参照）
-  a もしくはリペアが完了するまで、新たなレプリケーション先への read に対してクライアントに「no data exists」が返る可能性を許容する
+  a. もしくはリペアが完了するまで、新たなレプリケーション先への read に対してクライアントに「no data exists」が返る可能性を許容する
  
  
  レプリケーションストラテジを変更する場合も同じ選択肢が適用されます。

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-14 Thread Apache Wiki 
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=83&rev2=84

--

  
  クラスタ上で一度データが配置されたら、データの削除・再起動なしにパーティショナを変更することはできません。
  
- === Replication ===
- A Cassandra cluster always divides up the key space into ranges delimited by 
Tokens as described above, but additional replica placement is customizable via 
IReplicaPlacementStrategy in the configuration file.  The standard strategies 
are
+ === レプリケーション ===
+ 
カサンドラクラスタのキー空間は上述したトークンによって複数の区間に分割されますが、追加のレプリカの配置は設定ファイルのIReplicaPlacementStrategyによってカスタマイズできます。標準のストラテジは次の通りです。（レプリケーションファクタをNとします）
  
+ * !RackUnawareStrategy: レプリカはトークンを昇順で並べた場合の「次のN-1個のノード」に配置されます。
-  * !RackUnawareStrategy: replicas are always placed on the next (in 
increasing Token order) N-1 nodes along the ring
-  * !RackAwareStrategy: replica 2 is placed in the first node along the ring 
the belongs in '''another''' data center than the first; the remaining N-2 
replicas, if any, are placed on the first nodes along the ring in the 
'''same''' rack as the first
  
- Note that with !RackAwareStrategy, succeeding nodes along the ring should 
alternate data centers to avoid hot spots.  For instance, if you have nodes A, 
B, C, and D in increasing Token order, and instead of alternating you place A 
and B in DC1, and C and D in DC2, then nodes C and A will have 
disproportionately more data on them because they will be the replica 
destination for every Token range in the other data center.
+ * !RackAwareStrategy: 
二つめのレプリカはリングを順次辿る上でで最初に見つかる「別のデータセンターに設置されているノード」に配置されます。残りのN-2個のレプリカはできる限り一つめのレプリカが格納されたノードと同一のラックに設置されているノードに配置されます。
+ 
+ 
!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.

[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

2011-02-13 Thread Apache Wiki 
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=81&rev2=82

--

  ## page was copied from Operations
  <>
  
- == Hardware ==
- See CassandraHardware
+ == ハードウェア ==
+ CassandraHardwareを参照して下さい。
  
- == Tuning ==
- See PerformanceTuning
+ == チューニング ==
+ PerformanceTuningを参照して下さい。
  
- == Schema management ==
- See LiveSchemaUpdates [refers to functionality in 0.7]
+ == スキーマ管理 ==
+ LiveSchemaUpdatesを参照して下さい。[0.7で導入された機能]
  
- == Ring management ==
- Each Cassandra server [node] is assigned a unique Token that determines what 
keys it is the first replica for.  If you sort all nodes' Tokens, the Range of 
keys each is responsible for is (!PreviousToken, !MyToken], that is, from the 
previous token (exclusive) to the node's token (inclusive).  The machine with 
the lowest Token gets both all keys less than that token, and all keys greater 
than the largest Token; this is called a "wrapping Range."
+ == リング管理 ==
+ 
それぞれのCassandraサーバ（ノード）には、そのホストを最初のレプリカ先として使用するキーを決定するためのトークンが割り当てられます。ノードのトークンでソートした場合、あるノードが担当するキー範囲は（前のノードのトークン、自ノードのトークン]です。即ち、「前の」トークン（その値は含まない）から自分のトークン（値を含む）までの間隔です。リングの中で最も小さいトークンを持つノードはそのトークン値以下のキーに加えて、最大のトークンよりも大きいすべてのキーを担当します。これは"範囲ラップ"と呼ばれています。
  
- (Note that there is nothing special about being the "primary" replica, in the 
sense of being a point of failure.)
+ (障害シナリオでは「プライマリレプリカ」は特別な意味を持たないことに注意して下さい。すべてのレプリカは同等です。）
  
- When the !RandomPartitioner is used, Tokens are integers from 0 to 2**127.  
Keys are converted to this range by MD5 hashing for comparison with Tokens.  
(Thus, keys are always convertible to Tokens, but the reverse is not always 
true.)
+ 
!RandomPartitionerが使用されている場合、トークンは0から2^127までの範囲の整数です。キーはMD5ハッシュによってこの範囲にマップされ、トークンと比較されます。（キー値からトークン空間へは可換ですが、その逆は真ではありません。）
  
- === Token selection ===
- Using a strong hash function means !RandomPartitioner keys will, on average, 
be evenly spread across the Token space, but you can still have imbalances if 
your Tokens do not divide up the range evenly, so you should specify 
!InitialToken to your first nodes as `i * (2**127 / N)` for i = 0 .. N-1. In 
Cassandra 0.7, you should specify `initial_token` in `cassandra.yaml`.
+ === トークン選択 ===
+ 
強いハッシュ関数を使うことによって平均的には!RandomPartitionerのキーはキー空間に均一に分散されますが、もしトークンがキー範囲を均等に分割できていなければノード間のアンバランスが発生するかもしれません。このような場合は!InitialTokenを`i
 * (2**127 / N)`　(i は 0 .. N-1)に設定する必要があるでしょう。Cassandra 
0.7では`cassandra.yaml`で`initial_token`を指定できます。
  
- With order preserving partitioners, your key distribution will be 
application-dependent.  You should still take your best guess at specifying 
initial tokens (guided by sampling actual data, if possible), but you will be 
more dependent on active load balancing (see below) and/or adding new nodes to 
hot spots.
+ 
順序保存パーティショナではキーの分散度合いはアプリケーション依存になります。あなたはできるだけ適切な初期トークンを設定すべきですが（可能なら実データをサンプリングして決定した方がいいでしょう）、下記の述べる能動的な負荷分散設定や、負荷集中箇所へのノード追加などに依存することも多いでしょう。
 
  
- Once data is placed on the cluster, the partitioner may not be changed 
without wiping and starting over.
+ クラスタ上で一度データが配置されたら、データの削除・再起動なしにパーティショナを変更することはできません。
  
  === Replication ===
  A Cassandra cluster always divides up the key space into ranges delimited by 
Tokens as described above, but additional replica placement is customizable via 
IReplicaPlacementStrategy in the configuration file.  The standard strategies 
are