一般に、適切に設計されたクラスターは、触れずにYEARSの間存続できます。私は何年にもわたって実行されたクラスターを持っています。ただし、ここにいくつかのガイドラインがあります。
監視は非常に重要です。
1）レイテンシを監視します。opscenterまたはお気に入りのメトリックツールを使用して、レイテンシを追跡します。待機時間の増加は、GCの一時停止（読み取りワークロードでは書き込みワークロードよりも一般的）、安定した問題など、今後発生する問題の兆候である可能性があります。
2）安定したカウントを監視します。圧縮をオーバーランすると、SSTableの数が増加します（各sstableは1回だけ書き込まれます-削除は、圧縮によって古いsstableを新しいsstableに結合することによって処理されます）。
3）ノードの状態変化（アップ/ダウンなど）を監視します。ノードがバタつくのを見る場合、それは正常ではないので調べてください。
4）ディスクの使用状況を追跡します-従来、50％未満に抑える必要があります（特にSTCS圧縮を使用する場合）。
定期的に行うべき、またはすべきでない基本的なことがいくつかあります。
1）明示的に実行しないでくださいnodetool compact。あなたはそれをやったと言っています、それは致命的ではありませんが、それは非常に大きなsstableを作成します、そしてそれは次に前進する圧縮に参加する可能性が低くなります。必ずしも実行し続ける必要はありませんが、削除/上書きされたデータを取り除くのに役立つ場合があります。
2）nodetool repairは通常推奨gc_grace_secondsされます（デフォルトでは10日）。これがそれほど重要ではないワークロードがあります-修復が必要な最大の理由は、削除マーカー（tombstones）が期限切れになる前に送信されることを確認することです（削除が有効なgc_grace_seconds場合、削除が発生したときにノードがダウンしている場合、データが回復する可能性があります）修理せずに！）削除を発行せず、十分な整合性レベルでクエリを実行する場合（たとえば、QUORUMでの読み取りと書き込み）、実際に修復せずに生活できます。
3）修復する場合は、増分修復の使用を検討し、一度に小さな範囲を修復します。
4）圧縮戦略は重要です。STCSは書き込みに最適で、LCSは読み取りに最適です。DTCSにはいくつかの癖があります。
5）データモデルが重要-インデックス付けされていないクエリが大きなテーブルにヒットするときにRDBMS / SQL環境で問題が発生するのと同様に、Cassandraは非常に大きな行/パーティションで問題が発生する可能性があります。
6）スナップショットは安価です。とても安い。ほぼ瞬時にハードリンクだけで、すぐにディスクスペースをほとんど消費しません。バージョン、特にメジャーバージョンをアップグレードする前に、スナップショットを使用します。
7）削除には注意してください。＃2で示唆したように、deleteはディスク上により多くのデータを作成し、AT LEAST用に解放しませんgc_grace_seconds。
他のすべてが失敗した場合：
製品のCassandraが任意のサイズのクラスターを管理するために専用のヘッドを必要とすることを示唆する記事を見たことがあります-それが必ずしも本当であるかどうかはわかりませんが、懸念がある場合は、サードパーティのコンサルタント（TheLastPickle、Pythian ）または、安心を提供するサポート契約（Datastax）をご利用ください。