Cassandra Soglie di avvertimento e guasto di Tombstoning violate

Stiamo eseguendo un server Titan Graph DB supportato da Cassandra come archivio persistente e si sta verificando un problema con il raggiungimento del limite delle soglie di separazione di Cassandra che causa le nostre query di errore/timeout periodico come i dati si accumulano. Sembra che la compattazione non sia in grado di tenere il passo con il numero di pietre tombali aggiunte.Cassandra Soglie di avvertimento e guasto di Tombstoning violate

nostro caso d'uso supporta: throughput

alta di lettura/scrittura.
Alta sensibilità alle letture.
Frequenti aggiornamenti ai valori dei nodi in Titan. causando l'aggiornamento delle righe in Cassandra.

Dati i casi di utilizzo di cui sopra, si sono già ottimizzando Cassandra fare aggressivamente il seguente:

compattazione aggressivo in base alle strategie di compattazione livellate
Uso tombstone_compaction_interval 60 secondi.
Utilizzando tombstone_threshold essere 0,01
Impostazione gc_grace_seconds di essere 1800

Nonostante le seguenti ottimizzazioni, stiamo ancora assistendo le avvertenze nel Cassandra registra simile a: [WARN] (ReadStage: 7510) org .apache.cassandra.db.filter.SliceQueryFilter: Leggi 0 live e 10350 celle distaccate in .graphindex (vedi tombstone_warn_threshold). 8001 colonne è stato richiesto, fette = [00-FF], delInfo = {deletedAt = -9223372036854775808, localDeletion = 2147483647}

Di tanto in tanto il passare del tempo, vediamo anche la soglia di fallimento violato e causa errori.

Il nostro file cassandra.yaml ha il valore tombstone_warn_threshold da 10000 e tombstone_failure_threshold è molto più alto di quello raccomandato a 250000, senza reali vantaggi evidenti.

Qualsiasi aiuto che possa indicarci le configurazioni corrette sarebbe molto apprezzato se c'è spazio per ulteriori ottimizzazioni. Grazie in anticipo per il tuo tempo e aiuto.

fonte

2015-03-10 Rohit

Eliminate frequentemente i dati? Sono a conoscenza del fatto che le pietre tombali non vengono create a meno che i dati non vengano esplicitamente cancellati o scaduti. –

Crediamo che Titan GraphDb, che gestisce tutte le interazioni con Cassandra internamente, stia eseguendo eliminazioni e nuove creazioni per ogni aggiornamento, il che si aggiunge al numero di eliminazioni. – Rohit

Sarebbe bello confermare se fosse così. Potresti abilitare la traccia probabilistica (http://www.datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsSetTraceProbability.html) su uno dei tuoi cassandra nodi per vedere quali sono le eliminazioni? Un'altra possibilità è che le colonne siano scadute (impostate con un TTL), pensi che potrebbe accadere anche qui? –

Le pietre tombali non vengono compresse fino a quando la configurazione gc_grace_seconds su un tavolo non è scaduta per una data pietra tombale. Quindi, anche aumentando l'intervallo di compattazione, le tue pietre tombali non verranno rimosse fino a quando non sarà trascorso gc_grace_seconds, con il valore predefinito di 10 giorni. Potresti provare a sintonizzare gc_grace_seconds su un valore più basso e fare riparazioni più frequentemente (in genere si pianifica di eseguire riparazioni ogni gc_grace_seconds_in_days - 1 giorno).

fonte

2015-03-10 19:54:46

Grazie per aver riavuto Andy. Buon punto che hai menzionato. Stiamo impostando anche Gc grace seconds su 1800. Ho modificato il mio post per riflettere anche questo tentativo da parte nostra. – Rohit

Suoni come la radice del tuo problema è il tuo modello di dati. Hai fatto tutto il possibile per mitigare l'acquisto di TombstoneOverwhelmingException. Dal momento che il tuo modello di dati richiede tali aggiornamenti frequenti che causano la creazione di tombstone, un negozio consistente come Cassandra potrebbe non essere adatto al tuo caso d'uso. Quando abbiamo riscontrato questo tipo di problemi, abbiamo dovuto modificare il nostro modello di dati per adattarci meglio ai punti di forza di Cassandra.

cancella Chi http://www.slideshare.net/planetcassandra/8-axel-liljencrantz-23204252 (diapositive 34-39)

fonte

2015-03-10 20:37:42

Grazie Curtis. Darei un'occhiata a questo e vedere se ci sono cambiamenti che possiamo fare con il modello di dati. Parte del problema è che con l'utilizzo del server di grafica di Titan il modello di dati viene estratto da noi. – Rohit

Ciao @Rohit Puoi avere un'idea di come titan persiste i dati da [qui] (http://s3.thinkaurelius.com/docs/titan/0.5.4/data-model.html). Fondamentalmente quello che dovevamo fare è minimizzare i vertici ei bordi eliminati. –

Le variabili che hai sintonizzati stanno aiutando a expire lapidi, ma vale la pena notare che, mentre lapidi non possono essere eliminati fino gc_grace_seconds, Cassandra non garantisce che lapidi VOLONTÀ essere cancellato a gc_grace_seconds. In effetti, le pietre tombali non vengono compresse finché non viene compattato l'insieme contenente la pietra tombale e, anche in quel caso, non verrà eliminato se c'è un altro oggetto contenente una cella ombreggiata.

Ciò comporta che le pietre tombali possono persistere per un tempo molto lungo, soprattutto se si utilizzano sstables che sono di rado compattati (ad esempio, sstables di STCS molto grandi). Per risolvere questo problema, esistono strumenti come l'endpoint JMX per forceUserDefinedCompaction - se non sei abile nell'utilizzare gli endpoint JMX, esistono strumenti per farlo automaticamente come http://www.encql.com/purge-cassandra-tombstones/

fonte

2015-04-25 20:57:36

Quindi tutti qui hanno ragione. Se ripari e compatti frequentemente, riduci il numero gc_grace_seconds.

Potrebbe anche valere la pena considerare che l'inserimento di null è equivalente a un'eliminazione. Questo aumenterà il numero di lapidi. Invece, ti consigliamo di inserire lo UNSET_VALUE se stai usando istruzioni preparate. Probabilmente è troppo tardi per te, ma se qualcun altro viene qui.

fonte

2017-04-18 18:56:32 Highstead

Cassandra Soglie di avvertimento e guasto di Tombstoning violate

risposta

Problemi correlati