Cassandra consuma tutto lo spazio su disco

Question

Ho un cluster Cassandra a nodo singolo, utilizzo il minuto corrente come chiave di partizione e inserisco righe con TTL di 12 ore.

vedo un paio di problema che non può spiegare

1. Il /var/lib/cassandra/data/<key_space>/<table_name> contiene più file, molti di loro sono veramente vecchio (modo vecchi allora 12 ore, qualcosa come 2 giorni)
2. Quando ho provare a eseguire una query in cqlsh ho un sacco di tronchi che sembrano indicare che il mio tavolo contengono un sacco di lapidi

registro:

WARN [SharedPool-Worker-2] 2015-01-26 10:51:39,376 SliceQueryFilter.java:236 - Read 0 live and 1571042 tombstoned cells in <table_name>_name (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:40,472 SliceQueryFilter.java:236 - Read 0 live and 1557919 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:41,630 SliceQueryFilter.java:236 - Read 0 live and 1589764 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:42,877 SliceQueryFilter.java:236 - Read 0 live and 1582163 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:44,081 SliceQueryFilter.java:236 - Read 0 live and 1550989 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:44,869 SliceQueryFilter.java:236 - Read 0 live and 1566246 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:45,582 SliceQueryFilter.java:236 - Read 0 live and 1577906 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:46,443 SliceQueryFilter.java:236 - Read 0 live and 1571493 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:47,701 SliceQueryFilter.java:236 - Read 0 live and 1559448 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 
WARN [SharedPool-Worker-2] 2015-01-26 10:51:49,255 SliceQueryFilter.java:236 - Read 0 live and 1574936 tombstoned cells in <table_name> (see tombstone_warn_threshold). 100 columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808, localDeletion=2147483647} 

Ho provato più strategie di compattazione, compattazione multithread, ho provato a eseguire la compattazione manualmente con nodetool, inoltre, ho provato a forzare la garbage collection con jmx.

Una delle mie ipotesi è che la compattazione non elimina i file lapidi

Qualsiasi idee su come evitare lo spazio su disco di diventare troppo grande, la mia più grande preoccupazione è a corto di spazio, preferisco memorizzare meno (rendendo il ttl più piccolo ma al momento non aiuta)

Answer 1

Suppongo che si stia utilizzando il timestamp come colonna di cluster all'interno di ciascuna partizione quando si dice di utilizzare il minuto come chiave di partizione, insieme a un TTL di 12 ore quando si esegue l'inserimento. Questo creerà le pietre tombali in ogni partizione poiché non si elimina mai l'intera riga (cioè una partizione di un intero minuto).

Supponiamo che il vostro spazio delle chiavi si chiama k1 e il vostro tavolo è chiamato T2, allora è possibile eseguire:

nodetool flush k1 t2 
nodetool compact k1 t2 
sstable2json /var/lib/cassandra/data/k1/t2/k1-t2-jb-<last version>-Data.db 

allora vedrete tutte le lapidi come questo (contrassegnati con una "d" per cancellare):

{"key": "00000003","columns": [["4:","54c7b514",1422374164512000,"d"], ["5:","54c7b518",1422374168501000,"d"], ["6:","54c7b51b",1422374171987000,"d"]]} 

Ora, se si va ed eliminare quella riga (vale a dire eliminare dalla k1.t2 dove key = 3;), poi fare il filo, compatto, e sstable2json ancora una volta, lo vedrai cambiare per:

{"key": "00000003","metadata": {"deletionInfo": {"markedForDeleteAt":1422374340312000,"localDeletionTime":1422374340}},"columns": []} 

Quindi vedi tutte le pietre tombali se ne sono andate e Cassandra deve solo ricordare che l'intera riga è stata cancellata in un certo momento invece di piccoli pezzi e pezzi della riga eliminati in determinati momenti.

Un altro modo per sbarazzarsi delle lapidi è di troncare l'intero tavolo. Quando lo fai, Cassandra ha solo bisogno di ricordare che l'intera tabella è stata troncata in un dato momento, e quindi non ha più bisogno di tenere lapidi prima di quel momento (dal momento che le lapidi sono usate per dire ad altri nodi che certi dati sono stati cancellati, e se puoi dire che l'intera tabella è stata svuotata al momento x, quindi i dettagli prima di questo non contano più).

Quindi, come hai potuto applicare questo nella tua situazione che chiedi. Bene, è possibile utilizzare l'ora e il minuto come chiave di partizione, quindi una volta ogni ora eseguire un cron job per eliminare tutte le righe da 13 ore prima. Quindi alla compattazione successiva, tutte le pietre tombali per quella partizione verranno rimosse.

Oppure tenere una tabella separata per ogni ora e quindi troncare la tabella da 13 ore ogni ora utilizzando un cron job.

Un'altra strategia a volte utile è quella di "riutilizzare" le chiavi di clustering. Ad esempio, se si inseriscono dati una volta al secondo, invece di avere una data/ora di risoluzione elevata come chiave di cluster, è possibile utilizzare l'ora modulo 60 secondi come chiave di clustering e mantenere la data/ora più univoca solo come un campo dati. Quindi all'interno di ogni partizione dei minuti cambierebbe le pietre tombali (o le informazioni obsolete) da ieri in file live oggi, e quindi non accumulerai lapidi per molti giorni.

Quindi spero che questo ti dia qualche spunto per le cose da provare. Di solito quando si imbattono in un problema di pietra tombale, è un segno che è necessario ripensare il proprio schema un po '.

Answer 2

Le pietre tombali verranno conservate per 10 giorni utilizzando la configurazione predefinita. La ragione di ciò è assicurarsi che i nodi offline saranno in grado di recuperare le eliminazioni quando si uniranno nuovamente al cluster. È possibile configurare questo valore impostando l'impostazione gc_grace_seconds.

Answer 3

Ho un problema simile, solo nel mio caso c'era solo una tabella che si rifiutava di restringere (i vecchi file non vengono cancellati e il loro spazio di archiviazione continua a crescere). Ho usato nodetool compactionstats e ho visto che ci sono molte attività di compattazione in sospeso. Un'altra cosa interessante è che ho visto nei compattatori nodetool sempre mostrato compattazioni di compattazione tipo Compattazione per la tabella problematica, ma non di tipo Compensazione lapide, in opposizione alle tabelle che si comportavano bene. Potrebbe essere il problema?