[Cassandra Wiki] Update of "Operations_JP" by MakiWatanabe

[Apache Wiki <wi...@apache.org>]

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の頻度 ===