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 -------------------------------------------------- <<Anchor(Token_selection)>> === トークン選択 === 強いハッシュ関数を使うことによって平均的には!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 port 8081のようなメッセージが出力されていることを確認します。 * 標準ポート（8081）以外のポートや、標準アドレス（0.0.0.0）以外でlistenしたい場合はconf/cassandra-env.shを編集し、#MX4J_ADDRESS="-Dmx4jaddress=0.0.0.0" and #MX4J_PORT="-Dmx4jport=8081" がコメントアウトされている部分を戻して下さい。 http://cassandra:8081/ にアクセスすればHTMLインターフェースが使用できます。
