web-dev-qa-db-ja.com

トゥームストーン制限に達したときに正確に何が起こるか

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

このテーブルで、クリーンアッププロセス中にノードがダウンしていたために削除された行が再び表示されても問題はないので、gc grace time影響を受ける単一のテーブルの場合、10時間（デフォルトの10日から減少）になり、廃棄された行が比較的速く永久に削除されるようになります。

とにかく、私はtombstone_failure_threshold以下の例外を回避するために非常に高い。 （10億、10万から。）私の質問は、これは必要ですか？どのタイプのクエリが中止されるのかまったくわかりません。挿入、選択、削除？

いくつかのselectが中止されるだけの場合は、それほど大きな問題ではありません。しかし、それは、クエリが途中で停止し、墓石が多すぎる前に収集したライブデータを返すという点で、中断が「上限あり」を意味すると想定しています。

さて、もっと簡単に言えば、 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

cassandratombstone
22
natli

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

具体例：テーブルの行1と3の間にある、クラスター化キー1と3を持つ2つの行と、クラスター化キー2を持つ10万の死んだ行があるとします。ここで、キーが> = 1および<3になるSELECTクエリを発行する場合、予想される2つの行ではなく、100002行をスキャンする必要があります。

さらに悪いことに、Cassandraは、これらの行をスキャンするだけでなく、応答を準備している間、それらをメモリに蓄積する必要があります。これにより、メモリ不足エラーが発生する可能性があります。物事が行き過ぎており、複数のノードがリクエストを処理している場合、ノード全体で複数の障害が発生する可能性があります。これが発生しないように、危険な数のトゥームストーンを検出した場合、サービスはクエリを中止します。あなたはこれをクランクアップすることは自由ですが、Cassandraヒープがこれらの急上昇中に不足しそうな場合、危険です。

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

いくつかのselectが中止されるだけの場合は、それほど大きな問題ではありません。しかし、それは、クエリが途中で停止し、墓石が多すぎる前に収集したライブデータを返すという点で、中断が「上限あり」を意味すると想定しています。

クエリは制限されたセットを返さず、実際にリクエストを完全にドロップします。軽減したい場合は、猶予期間と同じ間隔で大量の行を削除することをお勧めします。そのため、毎週、この大量のトゥームストーンが流入することはありません。

26
Daniel S.

ここに完全なソリューションへのリンクがあります：

アプリケーションに合わせて、または特定のデータにTTLを使用するために、gc_grace_secondsがより頻繁に実行されるように設定して、トゥームストーンをクリーンアップします。たとえば、デフォルトのgc_grace_secondsは864000（10日）です。 TTLデータが6日に設定されている場合は、gc_grace_secondsを604800（7日）に変更して、トゥームストーンをより早く削除することができます。

https://support.datastax.com/hc/en-us/articles/204612559-ReadTimeoutException-seen-when-using-the-Java-driver-caused-by-excessive-tombstones

cqlsh:results> alter table example with gc_grace_seconds = 10000;

よろしく、

ALi

1
Ali Ait-Bachir