4

読み取りと書き込みの両方にクォーラムがある場合、HectorとCassandraを使用して整合性の問題が発生しました。

MultigetSubSliceQueryを使用して、スーパー列の制限サイズ100から行をクエリし、それを読み取ってから削除します。そして、別のことを始めましょう。

前のクエリで削除する必要のある行が、次のクエリからも表示されていることがわかりました。

また、通常の列ファミリーから、1つの列の値をstatus ='FALSE'からstatus='TRUE'に更新しましたが、次にクエリを実行したとき、ステータスはまだ'FALSE'でした。

より詳しく：

  1. 毎回起こっているわけではありません（1 / 10,000）
  2. 2つのクエリ間の時間は約500ミリ秒です（ただし、2秒が経過した1組のクエリが見つかりましたが、それでも一貫性の問題を示しています）
  3. クラスタ時間同期ソリューションとしてntpを使用します。
  4. 6つのノードがあり、レプリケーション係数は3です。

Cassandraは「結果整合性」があるはずであり、Cassandra内での書き込みの前に読み取りが行われない可能性があることを理解しています。でも2秒？！もしそうなら、クォーラムまたは他の整合性レベルの構成を持つことは無意味ではありませんか？

それで、まず第一に、それはカサンドラの正しい振る舞いですか、そうでない場合、さらなる投資のためにどのデータを分析する必要がありますか？

4

4 に答える 4

3

システムログでソースコードを確認したところ、不整合の根本的な原因がわかりました。3つの要因が問題を引き起こします：

  • 異なるノードから同じレコードを作成および更新します
  • ローカルシステム時刻は十分に正確に同期されていません（ただし、NTPを使用しています）
  • 整合性レベルはQUORUMです

ここに問題があります、イベントシーケンスとして以下を取ります

 seqID   NodeA         NodeB          NodeC
 1.      New(.050)     New(.050)      New(.050)
 2.      Delete(.030)  Delete(.030)

最初の作成要求は、ローカルタイムスタンプ00：00：00.050でノードCから送信され、要求が最初にノードAとノードBに記録され、その後ノードCと同期されると想定します。

次に、削除要求がノードAからローカルタイムスタンプ00：00：00.030で送信され、ノードAとノードBに記録されます。

読み取り要求が来ると、Cassandraはバージョン競合マージを実行しますが、マージはタイムスタンプにのみ依存するため、作成後に削除が発生しましたが、ローカル時間同期の問題により、マージの最終結果は「新規」になります。

于 2013-03-06T06:54:01.423 に答える
1

私も同様の問題に直面しました。この問題は、cassandra ドライバーがデフォルトでサーバーのタイムスタンプを使用して最新のクエリを確認するために発生しました。ただし、cassandra ドライバーの最新バージョンでは変更が加えられており、現在はデフォルトでクライアントのタイムスタンプを使用しています。

ここで問題の詳細を説明しました

于 2015-12-03T16:05:03.097 に答える
0

削除された行は、分散削除の仕組みにより、「範囲ゴースト」として表示される場合があります: http://wiki.apache.org/cassandra/FAQ#range_ghostsを参照してください。

CL_QUORUM で個々の列の読み取りと書き込みの両方を行っている場合、時間間隔に関係なく、常に完全な整合性が得られるはずです (ただし、厳密な順序が守られている場合、つまり、読み取りが常に書き込みの後にあることが確実である場合)。これが表示されない場合は、どこかで何かが間違っています。

まず、a) クライアントが NTP に適切に同期していることを確認するか、何らかの方法でクライアント間で時刻をクロスチェックして問題を再現することをお勧めします。b) CL_ALL で問題を再現してみてください。

別の考え-クライアントはNTPと同期されていますか、それともCassandraサーバーノードだけですか? Cassandra はクライアントのタイムスタンプを使用して、どの値が最新であるかを判断することに注意してください。

于 2012-06-25T21:35:00.437 に答える
-1

クライアント/ノードの 1 つでこの問題が発生しています。私がテストしている他の 2 つのクライアント (および他の 2 つのノード) はスムーズに動作します。すべての読み取りとすべての書き込みで QUORUM を使用するテストがあり、すぐに失敗します。実際には、他のプロセスから何も見えないプロセスもあれば、QUORUM を削除した後でもデータが常に見えるプロセスもあります。

私の場合、ログをオンにして、tail -F コマンドで偉業をテストするつもりでした。

tail -F /var/lib/cassandra/log/system.log

ここに示されているエラーが発生しているかどうかを確認します。驚いたことに、テール プロセス自体がエラーを返しました。

tail: inotify cannot be used, reverting to polling: Too many open files

別のスレッドから、これは一部のプロセスがファイルを開くのに失敗することを意味します。つまり、Cassandra ノードは、ディスク上のデータに適切にアクセスできないため、期待どおりに応答していない可能性があります。

これが質問を投稿したユーザーの問題に関連しているかどうかはよくわかりませんが、ファイルの制限に達したかどうかを判断するには、確かに tail -F が良い方法です。

(参考までに、私は同じマシンで 5 つの比較的重いサーバーを実行しているので、この事実についてあまり驚くことではありません。ulimit を増やすことを検討する必要があります。この方法で修正されたら、ここで再度報告します。 .)

ファイル制限と ulimit コマンド ライン オプションの詳細: https://askubuntu.com/questions/181215/too-many-open-files-how-to-find-the-culprit

--------- アップデート 1

念のため、最初に Oracle の Java 1.7.0-11 を使用してテストしました (以下で説明するように、最初に 3,000 の制限を使用しましたが成功しませんでした!) Cassandra テストを実行すると、ほぼ同時に同じエラーがポップアップします (さらにulimit が 3,000 の場合でも、tail -F エラーが表示されます...)

--------- 更新 2

わかった！それはうまくいきました。ulimit を 32,768 に変更したところ、問題はなくなりました。最大値をこれほど高い数値に引き上げる前に、ユーザーごとの制限を拡大して/etc/security/limits.conf実行する必要があったことに注意してください。以前の制限は1024しかなかっsudo sysctl -pたにもかかわらず、どういうわけかデフォルトの上限の 3000 では十分ではありませんでした。

于 2013-01-26T11:49:46.387 に答える