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 + <<TableOfContents()>> == ハードウェア == @@ -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"と呼ばれています。
