1

4 つの VM にわたって CentOS 6.4 にセットアップしたばかりの 4 ノードの Cassandra (1.2) クラスターを試しています。最初に、レプリケーション ファクターが 3 のキースペースを作成し、その中にいくつかのテーブルを作成し、それぞれに少数の行を入力しました。すべて Cqlsh を使用しました。単純な INSERT、SELECT、および UPDATE は正常に機能しているように見えました。

次に、いくつかのノードを無作為に切断して、クラスターの機能が動作していることを確認しました。2 つのノードがオフラインである間に、いくつかの SELECT を実行すると、正しい結果が返されました。その後、「nodetool getendpoints」によると、オフライン ノードと Cqlsh が実行されているローカル ノードでホストされている既存の行を更新しようとしました。2 つのノードをオンラインに戻した後、更新された行に対して SELECT を実行しても、更新されたデータ値が返されませんでした。少し待って再度 SELECT を試みましたが、それでも元のデータが返され続けました。次のことも試しましたが、どれも更新されたデータを返しませんでした:

  1. UPDATE を数回再実行する
  2. 同じ行の別の列を更新 - フィールドは更新されませんでした
  3. クラスタ内の 4 つのノードすべてを再起動する

別の行の同じ列の UPDATE は正常に機能します。これは、上記の #2 とともに、これが行データの問題であると考えさせます。

次のスニペットは、一見成功したように見える UPDATE の前後に元のデータを返す SELECT を示しています。

cqlsh:demo> select email, active from users where email = 'john.doe@bti360.com';

email               | active
--------------------+--------
john.doe@bti360.com |   True

cqlsh:demo> update users set active = false where email = 'john.doe@bti360.com';

cqlsh:demo> select email, active from users where email = 'john.doe@bti360.com';

email               | active
--------------------+--------
john.doe@bti360.com |   True

私は Cassandra を初めて使用するので、何かが欠けている可能性があります。ここで何が起こっているのかを明らかにするのに役立つ提案やトラブルシューティングのヒント (チェックするファイルまたは実行するコマンド) は大歓迎です。

4

2 に答える 2

6

これは、サーバー間のクロックの不一致によって説明できます。更新のタイムスタンプは、クライアントから更新を受け取るサーバーによって設定されます。サーバーが同期していない場合、古い更新のタイムスタンプが新しいため、後続の書き込みが上書きされるこのような動作が発生する可能性があります。

調べるには、まずサーバーの時計を確認します。クロックが同じになるように、常に Cassandra サーバー間で NTP を実行する必要があります。

これが実際の問題かどうかは、WRITETIME を使用してタイムスタンプを取得することで確認できます。

select WRITETIME(active) from users where email = 'john.doe@bti360.com';

これはエポックからのマイクロ秒です。別の行に値を書き込み、そのタイムスタンプを取得します。それよりも早い場合は、これが原因です。

于 2013-06-12T16:15:46.507 に答える
0

Richard が言及した時刻同期以外に、私が考えることができる 1 つの理由は、QUORUM または ALL ではなく、ANY または ONE の一貫性です。ただし、QUORUM または ALL を使用し、ダウンしているノードが多すぎると、読み取りと書き込みでタイムアウトが発生します。

ただし、一貫性が ONE であっても、最終的にはデータの一貫性が保たれるはずです。一貫性がとれるまでにかかる時間は指定されていませんが、私の側では、それは本当に速いようです.

于 2016-06-03T18:54:58.147 に答える