25

cassandra のログ (以下を参照) によると、存在するクエリが多すぎるため、クエリが中止されてtombstonesいます。これは、週に 1 回、カウンターが低すぎる行をクリーンアップ (削除) するために発生しています。これにより、数十万行が「削除」されます（そのようにtombstone. でマークされます）。

クリーンアップ プロセス中にノードがダウンしたために、このテーブルで削除された行が再表示されてもまったく問題はないので、gc grace time影響を受ける単一のテーブルの時間を 10 時間 (デフォルトの 10 日から短縮) に設定しました。廃棄された行は、比較的高速に完全に削除される可能性があります。

とにかく、tombstone_failure_threshold以下の例外を避けるために非常に高く設定する必要がありました. (10 万から 1 億に増加) 私の質問は、これは必要ですか? どのタイプのクエリが中止されるかはまったくわかりません。挿入、選択、削除?

一部の選択が中止されただけであれば、それほど大きな問題ではありません。しかし、それは、クエリが時期尚早に停止し、あまりにも多くの墓石が見つかる前に収集できたライブデータを返すという点で、中止が「制限付き」を意味すると想定しています。

もっと簡単に言うと、tombstone_failure_thresholdを超えるとどうなりますか？

INFO [HintedHandoff:36] 2014-02-12 17:44:22,355 HintedHandOffManager.java (line 323) Started hinted handoff for host: fb04ad4c-xxxx-4516-8569-xxxxxxxxx with IP: /XX.XX.XXX.XX
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,667 SliceQueryFilter.java (line 200) Scanned over 100000 tombstones; query aborted (see tombstone_fail_threshold)
ERROR [HintedHandoff:36] 2014-02-12 17:44:22,668 CassandraDaemon.java (line 187) Exception in thread Thread[HintedHandoff:36,1,main]
org.apache.cassandra.db.filter.TombstoneOverwhelmingException
    at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:201)
    at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122)
    at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80)
    at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72)
    at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297)
    at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
    at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1516)
    at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1335)
    at org.apache.cassandra.db.HintedHandOffManager.doDeliverHintsToEndpoint(HintedHandOffManager.java:351)
    at org.apache.cassandra.db.HintedHandOffManager.deliverHintsToEndpoint(HintedHandOffManager.java:309)
    at org.apache.cassandra.db.HintedHandOffManager.access$300(HintedHandOffManager.java:92)
    at org.apache.cassandra.db.HintedHandOffManager$4.run(HintedHandOffManager.java:530)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)

言及するのを忘れました。Cassandra バージョンの実行2.0.4

4

2 に答える 2

30

行 (または列) の範囲を返すクエリが Cassandra に発行されると、結果セットを収集するためにテーブルをスキャンする必要があります (これはスライスと呼ばれます)。現在、削除されたデータは通常のデータと同じ方法で保存されますが、圧縮されるまで廃棄済みとしてマークされます。しかし、それにもかかわらず、テーブル リーダーはそれをスキャンする必要があります。したがって、大量の墓石が横たわっている場合、表面上は限られたスライスを満たすために、大量の作業を行う必要があります。

具体的な例: クラスタリング キー 1 と 3 を持つ 2 つの行と、テーブルの行 1 と 3 の間にあるクラスタリング キー 2 を持つ 10 万の無効な行があるとします。キーが >= 1 かつ < 3 であるクエリを発行するSELECTと、予想される 2 行ではなく、100002 行をスキャンする必要があります。

さらに悪いことに、Cassandra はこれらの行をスキャンするだけでなく、応答の準備中にメモリに蓄積する必要もあります。これにより、処理が行き過ぎた場合にノードでメモリ不足エラーが発生する可能性があり、複数のノードが要求を処理している場合は、複数の障害が発生してクラスター全体がダウンする可能性さえあります。これが起こらないようにするために、危険な数の廃棄を検出した場合、サービスはクエリを中止します。これを増やすのは自由ですが、これらのスパイク中に Cassandra ヒープが不足しそうになっている場合は危険です。

この例外は、最近の修正で導入され、2.0.2 で最初に利用可能になりました。 これは、変更が対処しようとしていた問題を説明するバグ エントリです。以前は、ノードの 1 つ、または場合によっては複数のノードが突然クラッシュするまでは、すべて問題ありませんでした。

一部の選択が中止されただけであれば、それほど大きな問題ではありません。しかし、それは、クエリが時期尚早に停止し、あまりにも多くの墓石が見つかる前に収集できたライブデータを返すという点で、中止が「制限付き」を意味すると想定しています。

クエリは限定されたセットを返しません。実際にはリクエストを完全に削除します。緩和したい場合は、猶予期間と同じ頻度で行の一括削除を行う価値があるかもしれません。そうすれば、毎週大量の墓石が流入することはありません。

于 2014-02-14T06:46:56.697 に答える