Apache Cassandraでの墓石の経験
墓石の検出と防止
墓石は、ログおよび特定のメトリックを監視することによって検出できます。 それらの寿命は、テーブル設定gc_grace_secondsによって定義されます。
チューンテーブル設定
- gc_grace_seconds
gc_grace_secondsのデフォルト設定は864000(10日)です。 私たちにとっては、その値を345600（4日）に下げることは理にかなっていました。 猶予期間を変更する場合は、その期間内に修復を実行するようにしてください。
既存のテーブルの値を変更するか、次のように新しいテーブルを作成するだけです:
テーブルキースペースを作成します。テーブル名とGC_GRACE_SECONDS=345600;
テーブルキースペースを変更します。GC_GRACE_SECONDSを指定したテーブル名= 345600;
- TTL
TTLが定義された時間範囲を通過すると、行が削除され、値が墓石に変換されます。 デフォルトでは、行/値は期限切れになりません。
墓石の問題を経験している間、私たちはテーブルの生存時間を増やす必要があることを理解しました。 この値を1½daysに設定することにより、書き込みジョブの失敗は、テーブルからすべてのデータを一度に削除する効果がありました。 更新が欠落しているため、すべての行に墓石がマークされていました。 値を高く設定すると、時間内にジョブを再実行し、大量の墓石の不要な作成を避けることができます。
- tombstone_warn_threshold
tombstone threshold警告はデフォルトで1.000に設定されており、単一のクエリで1.000を超える墓石がスキャンされた場合にログに表示されます。
- tombstone_failure_threshold
単一のクエリで100.000個のtombstonesがスキャンされると、tombstoneの失敗しきい値に達します。 この場合、クエリは中止され、影響を受けるテーブルのデータをクエリできなくなります。
これらのしきい値の設定は変更できますが、これを大きくするとノードのメモリが不足する可能性があることに注意してください。
定期的な修理を実行
Cassandraは高いフォールトトレランスを備えており、ノードが一時的に使用できなくても良好に動作します。 ただし、ノードの障害が発生した後にnodetool repairを実行することをお勧めします。 あなたはすべてのコストでデータの損失を回避したい場合は特に。
修復処理中、使用できなかったノードは、ダウンタイム中に発生した書き込みを受信します。
gc_grace_seconds内で定期的に修復を実行するのが良いアプローチです。
修復を自動的に実行するには、いくつかの方法があります。 そのうちの一つはCassandra Reaperです。 このツールは、修理をスケジュールすることが容易になり、素敵なUIが付属しています。
Configure and run compaction
最終的に墓石を削除してディスク領域を解放するには、compactionをトリガーする必要があります。 さまざまな種類の圧縮があります。 マイナー圧縮は、すべてのsstableに対して圧縮を実行し、Cassandraで自動的に実行されます。 これは、猶予期間よりも古いすべての墓石を削除します。 すべてのsstableに対して手動で圧縮をトリガーする場合、それは主圧縮と呼ばれます。 圧縮はノードごとに個別にトリガーする必要があることに注意してください。 また、指定されたsstableのグループだけでユーザー定義の圧縮を実行するオプションもあります。
C*でデータを圧縮すると、通常、sstableを単一の新しいsstableにマージすることを意味します。 複数の行で読み取りを実行する場合、より多くのsstableをスキャンする必要があるため、プロセスが遅くなります。 これが起こらないようにするには、圧縮を定期的に実行する必要があります。
圧縮を手動で開始するには、nodetool compactを使用できます。 キースペースまたはテーブルを指定しない場合、圧縮はすべてのキースペースおよびテーブルで実行されます。
nodetool compact keyspace tablename
このコマンドは、指定されたテーブルの圧縮を開始します。 テーブルに対してどの圧縮戦略が構成されているかを把握し、それを代替戦略と比較する必要があります。 別の戦略がニーズをよりよく満たしているかどうかを確認したい場合は、DataStaxのドキュメントをチェックしてください。
モニターテーブルメトリック
1. Nodetool
NodetoolはCassandraのコマンドラインインターフェイスです。 これは、クラスターのパフォーマンスについてもっと理解したい場合に便利です。 DataStaxが提供する可能性のあるコマンドのリスト全体をチェックすることができます。
Nodetoolコマンドは、ノードごとに個別に実行する必要があります。 KubernetesでC*を実行するので、実行中のCassandra podのシェルを次のように開くことができます:
kubectl exec-it cassandra-0-n推奨bash
その時点から、nodetoolを使用してテーブルに関するさまざまな情報を取得できます。 Nodetool tablestatsコマンドを実行すると、個々のキースペースまたはテーブルの統計情報を出力できます:
“スライスあたりの平均墓石”と”スライスあたりの最大墓石”の値は、過去五分間にクエリごとにスキャンされた墓石の数を教えてくれます。 この値が非常に高い場合は、そのテーブルに対してより頻繁に圧縮を実行する必要がある場合があります。
2. SSTable Tools
SSTable Toolsを実行する前に、Cassandraを停止する必要があります。 Sstableutilコマンドは、特定のテーブルに存在するsstableファイルのリストを提供します。 これらのファイルに対してsstablemetadataを実行すると、TTLやドロップ可能な墓石の見積もりなど、指定されたテーブルに関する有用な情報が提供されます。
3. PrometheusとGrafana
C*のモニタリングはPrometheusとGrafanaで設定されています。 Tombstones thresholdの警告を受け取った後、ダッシュボードにパネルを追加して、各テーブルのtombstone動作のアイデアを提供することにしました。
Cassandraには、クエリごとにスキャンされた墓石のヒストグラムを示す’TombstoneScannedHistogram’というテーブルメトリックがあります。 99パーセンタイルを表示することで、何かが正しくないかどうかがわかります。
