In generale, un cluster ben progettato può vivere per ANNI senza essere toccato. Ho avuto cluster che hanno funzionato per anni senza mani. Tuttavia, ecco alcune linee guida:
Il monitoraggio è estremamente importante:
1) Monitorare le latenze. Usa opscenter o i tuoi strumenti di misurazione preferiti per tenere traccia delle latenze. Le latenze in aumento possono essere segni di problemi in arrivo, tra cui pause GC (più comuni nei carichi di lavoro in lettura rispetto ai carichi di lavoro in scrittura), problemi instabili e simili.
2) Monitorare i conteggi impostabili. I conteggi SSTable aumenteranno se si supera la compattazione (ogni sstable viene scritta esattamente una volta - le eliminazioni vengono gestite combinando i vecchi sstable in nuovi sstable attraverso la compattazione).
3) Monitorare i cambiamenti di stato del nodo (su / giù, ecc.). Se vedi che i nodi si agitano, investiga, poiché non è normale.
4) Tieni traccia del tuo utilizzo del disco - tradizionalmente, devi rimanere sotto il 50% (specialmente se usi la compattazione STCS).
Ci sono alcune cose di base che dovresti e non dovresti fare regolarmente:
1) Non eseguire esplicitamente nodetool compact. Dici che l'hai fatto, non è fatale, ma crea scale molto grandi, che quindi hanno meno probabilità di partecipare alla compattazione andando avanti. Non è necessario continuare a eseguirlo, ma a volte può essere utile eliminare i dati cancellati / sovrascritti.
2) nodetool repairè in genere raccomandato ogni gc_grace_seconds(10 giorni per impostazione predefinita). Esistono carichi di lavoro in cui questo è meno importante: il motivo principale per cui è NECESSARIO riparare è assicurarsi che i marker di eliminazione ( tombstones) vengano trasmessi prima della scadenza (vivono per gc_grace_seconds, se un nodo è inattivo quando si verifica l'eliminazione, i dati potrebbero tornare alla vita senza la riparazione!). Se non si eseguono cancellazioni e si esegue una query con un livello di coerenza sufficiente (ad esempio, legge e scrive su QUORUM), puoi effettivamente vivere una vita senza riparazioni.
3) Se hai intenzione di riparare, prendi in considerazione l'uso della riparazione incrementale e ripara piccoli intervalli alla volta.
4) Le strategie di compattazione contano molto. STCS è ottimo per le scritture, LCS è ottimo per le letture. DTCS ha alcune stranezze.
5) I modelli di dati contano - proprio come gli ambienti RDBMS / SQL si mettono nei guai quando le query non indicizzate colpiscono tabelle di grandi dimensioni, Cassandra può essere problematico con file / partizioni molto grandi.
6) Le istantanee sono economiche. Molto a buon mercato. Quasi istantanei, solo collegamenti reali, non costano quasi immediatamente spazio su disco. Utilizzare lo snapshot prima di aggiornare le versioni, in particolare le versioni principali.
7) Prestare attenzione con le eliminazioni. Come suggerito in # 2, delete crea più dati sul disco e non li libera per ALMENO gc_grace_seconds.
Quando tutto il resto fallisce:
Ho visto articoli che suggeriscono che Cassandra in prod richiede un responsabile dedicato per gestire qualsiasi cluster di dimensioni: non so che sia necessariamente vero, ma se sei preoccupato, potresti voler assumere un consulente di terze parti (TheLastPickle, Pythian ) o avere un contratto di supporto (Datastax) per darti un po 'di tranquillità.