Cassandraサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか

乗るしか無い、このビッグウェーブに。
（このエントリとこのエントリの三番煎じです。）

- - - - -

追記
Cassandraはデータ領域のDisk使用量が50%でクリティカルと記載しましたが、いきなりズドンと落ちるとかでは無く、compactionを実行した時にテンポラリーファイル作成します。これは対象のSSTableのサイズに依存します。で、このテンポラリーファイルが作成できなくなる可能性がある閾値が50%です。
http://wiki.apache.org/cassandra/CassandraHardware_JP
から引用

MemtableSSTableで述べているように、コンパクションは最悪の場合、一時的にひとつのボリューム(つまりデータディレクトリ)に対して最大そのデータと同じだけの空き領域を要求します。

- - - - -

まずCassandraでDisk空き領域が減少する可能性があるのはほぼ2つ。アプリケーションログファイルとSSTableファイルの肥大化、増加です。他のファイルもあるけど、この2つに比べたら誤差でしょ（適当
では、ログは適当にやるとしてSSTableファイルが肥大化、増加するのにどんな事が考えられるか。

snapshotを取っていてそれが消えていない
単純に一杯書き込みが発生
自分自身やレプリカファクター的に絡む周辺ノードがrepairやjoinなどのノード間でデータのやり取りをした際に無駄に重複しているデータを持ってしまう
compaction中でtmpファイルが生成されている

辺りがまず考えられます。

ではまず切り分けを行う手順として、まず先人の知恵を元にdfとかduを実行しましょう。で、Cassandraのデータ領域でデータがモリモリ増えているのを確認したら
{prefix}/keyspace/columnfamily/SSTableファイルとか
という階層構造になっているので、どのcolumnfamilyのディレクトリが肥大化しているかチェックしましょう。で次からは

snapshot格納ディレクトリを確認して不要なスナップショットで圧迫していたらnodetool clearsnapshotを実行してまずは不要なスナップショットを削除しましょう。
nodetool ringを実行してノードで持っているデータ量を確認し、そもそも他のノードと比べて肥大化していないか確認する
SSTable格納階層の中にhogehoge-Data.dbという奴の中にtmp-hogehoge-Data.dbというのがあれば該当のデータをcompactionしている最中なのでnodetool compactionstatsでも眺めながら早くcompactionが終わるように神に祈りましょう
誰かがメンテナンスでrepairとかを実行していないかはsysytemログをひたすら眺めるかnodetool netstats辺りを見てみてデータのやりとりが発生していないかを確認しましょう。この時に重複したデータはそのSSTableファイルがcompaction掛かるタイミングで消えるので、気長に待ちましょう。明示的にcompaction掛けるのは禁断の技です。理由としては、それによってSSTableが無駄に肥大化してしまい、次のcomapctionまで非常に時間が掛かってしまって結局同じ事象を繰り返すハメになる為。

で、この辺の切り分けが終わって、純粋なデータ増加の場合はcassandraはノード追加するくらいしか対応方法ありません。ちなみにCassandraは公式ドキュメントにも書いていますがデータ領域については使用量が50%行ったらクリティカルです。その為、データ領域についてはDisk使用量の40%くらいで通常はクリティカルなアラート鳴らす様にしないと、そもそもノードを追加したり強制的にcompactionする作業が出来なくなって詰む可能性があります。

なので、しっかりdfコマンドやduコマンドの使い方を覚えて、さらに普段からしっかりDisk容量監視チェックをしましょうね(・ω<)

oranie's blog

旧:iをgに変えると・・・なんだっけ・・・

Cassandraサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか