1

3 ノードのクラスターがあり、replicate_factor も 3 です。整合性レベルは、書き込みクォーラム、読み取りクォーラムです。トラフィックには 3 つの主要なステップがあります

  • 作成：
    • 行キー: xxxx
    • カラム: status=new, requests="xxxxx"
  • アップデート：
    • 行キー: xxxx
    • カラム: status=executing, requests="xxxxx"
  • 消去：
    • 行キー: xxxx

1 つのノードがダウンすると、整合性構成に従って機能し、最終的なステータスはすべての要求が終了して削除されます。

そのため、cassandra クライアントを実行して結果を一覧表示する場合 (整合性クォーラムも設定します)。空（行キーだけ残っている）と表示されますが、これは正しいです。

しかし、デッド ノードを開始すると、ヒント付きハンドオフ モデルがデータをこのノードに書き戻します。そのため、作成、更新、削除がたくさんあります。

GC またはコンパクションが原因でわかりません。他の 2 つのノードでのレコードの削除は機能していないようです。また、cassandra クライアントを使用してデータを一覧表示すると (一貫性のクォーラムも)、削除された行が列の値とともに再び表示されます。リカバリ ノードにより、履歴が再度再生されます。

また、クライアントを使用してデータを数回確認すると、データが変更されていることがわかります。ハンドオフのリプレイ操作が示唆されているようで、削除されたデータが表示されてから消えます。

ヒント付きのハンドオフが完了するまで、この手順を外部から見えないようにする方法はありますか?

私が望むのは、最終的なステータスの同期です。一時的なステータスは古く、また正しくありません。外部から見られることはありません。

列の削除ではなく、行の削除が原因ですか? それとも圧縮？

4

1 に答える 1

1

ログと構成を確認したところ、2 つの理由が原因であることがわかりました。

  1. GC 猶予秒数

    ヘクター クライアントを使用して cassandra に接続しています。各列ファミリーの GC 猶予秒数のデフォルト値はZeroです。そのため、ヒント付きハンドオフが一時値を再生すると、他の 2 つのノードのトゥームストーンが圧縮によって削除されます。そして、クライアントは一時的な値を取得します。

  2. 二次索引

    最初の問題を修正した後でも、cassandra クライアントから一時的な結果を取得できます。そして、「get my_cf where column_one='value'」のようなコマンドを使用してデータをクエリすると、一時的な値が再び表示されます。しかし、生のキーを使用してレコードを再度クエリすると、それは消えました。クライアントからは、常に行キーを使用してデータを取得しているため、一時的な値を取得できませんでした。

    そのため、セカンダリ インデックスは整合性構成によって制限されていないようです。

    そして、GC猶予秒を10日に変更すると。私たちの問題は解決しましたが、インデックス クエリを使用する場合は依然として奇妙な動作です。

于 2013-10-15T05:14:07.403 に答える