私は3ノードのcassandraクラスタ(ecand2で動作するcassandra 3.5を実行します)を3倍のレプリケーションファクタで使用しています。そこ1人の列の家族であり、それは次のようになります。なぜ、cassandraはシステム上よりもディスク使用量が多いと報告していますか?
CREATE TABLE IF NOT EXISTS history_items (person_id text, id_type text, client_id text, history_item text, activity_ts timestamp, primary key ((person_id, id_type, client_id), activity_ts)) WITH CLUSTERING ORDER BY (activity_ts DESC);
のみ2本に対して実行クエリがある - (読むために(必ず1週間のTTLで)を挿入するために、1つ、および1つは、常に100に制限)。しばらくの間、データセットは着実に増加していました。それはデータの各部分がどれくらいの期間生存しているのかという理由から、1週間後にはそれが横ばいになると予想していましたが、そうではありませんでした。
私は監視のためにグラファイトを使用しています。金曜日、データ量は各ノードの〜17Gからノードあたり〜23-27Gに上昇しました。今日、私はノードが現在ノードあたり〜115G-200Gを報告していることを発見しました! nodetool status
は同様の数字を示していますが、これらのマシンで実際にディスク使用量を調べると、それぞれのディスク使用量は〜20Gしか表示されません。今までは、グラファイト統計(Storage.LoadとTotalDiskSpaceUsedを参照)、nodetool status
、およびdf -h
はすべて同じ数字を示しました。
黒鉛にもnodetool status
でも、カッサンドラが報告しているものと、マシン上に見られるものとの間に大きな違いがあるとは何かを説明できますか?
今日はじめてnodetool repair
を実行していましたが、これはクロールが遅くなりました。現在約6時間稼働しており、nodetool compactionstats
は、「検証」圧縮が48.95%の進捗に達していることを示しています。完了したバイト数は増え続けているように見えますが、遅くて遅いレートでは、進捗率は数時間で増加しませんでした(0.1%でも)。
nodetool repair
はこれに適切な応答をしていましたか?それがそうであるならば、それがそれほど長くかかる原因となるかもしれないスキーマに関する他の問題がありますか?これは時系列データなので、「DateTieredCompactionStrategy」を使用する必要があるようですが、これは私が見ている問題に役立つだろうと私には分かりません。
問題のトラブルシューティングに役立つ可能性のある他の詳細情報を共有してもらいます。
編集: これは約24時間経過しており、「検証」コンパクションはわずか49.02%に達しています。 nodetool status
とグラファイトの両方が使用されている115G-300Gストレージの間に表示されますが、df -h
は〜22Gを示します。
EDIT: ノードを大きなボックス(c4.large - > c4.xlarge)に置き換えても、同様の問題が残ります。各ノードでカサンドラを再起動すると、200G +の間違った報告を修正するように見えたが、nodetool compactionstats
はまだ修復中に、私は理解していないいくつかのことを示しています
[email protected]:~$ nodetool compactionstats -H
pending tasks: 1
- act_hist.product_views: 1
id compaction type keyspace table completed total unit progress
903cc350-58f2-11e6-8721-f377ed1bf63f Validation act_hist product_views 2.48 TB 5.23 TB bytes 47.47%
Active compaction remaining time : 0h00m00s
5TBはどこから来たん? nodetool compactionstats
を通常の(修復ではなく、検証圧縮ではない)圧縮中に実行すると、その数値ははるかに合理的です。
私は最初に増加に気づき、 'nodetool修復 '(nodetool cli)で修復を実行し始めました。 – mike