Cassandra Repliche Down durante la riparazione di nodetool?

Question

Sto sviluppando uno script automatizzato per la riparazione di nodetool che dovrebbe essere eseguito in qualsiasi fine settimana su tutti i 6 nodi di Cassandra. Abbiamo 3 in DC1 e 3 in DC2. Voglio solo capire lo scenario peggiore. Cosa succederebbe se la connettività tra DC1 e DC2 venisse persa o un paio di repliche prima o durante una riparazione di nodetool. Potrebbe essere un problema di rete, un aggiornamento di rete (che di solito accade nei fine settimana) o qualcos'altro. Comprendo che la riparazione di nodetool calcola un albero Merkle per ogni intervallo di dati su quel nodo e lo confronta con le versioni su altre repliche. Quindi se la loro non è la connettività tra le repliche come si comporterebbe una riparazione di nodetool? Riparerà davvero i nodi. Devo rieseguire la riparazione dello strumento del nodo dopo che tutti i nodi sono attivi e la connettività è stata ripristinata. Saranno loro effetti collaterali di questo evento? Mi sono divertito, ma non ho trovato molti dettagli. Ogni suggerimento sarebbe di grande aiuto.

Grazie.

Answer 1

Diciamo che stai usando vnodes, che di default significa che ogni nodo ha 256 intervalli, ma l'idea è la stessa.

Se il problema di rete si verifica dopo l'avvio della riparazione di nodetool, nei registri verrà visualizzato che alcuni intervalli sono stati riparati correttamente e altri no. L'errore dirà che la riparazione dell'intervallo è fallita perché il nodo "192.168.1.1 è morto" qualcosa del genere.

Se l'errore di rete si verifica prima dell'avvio della riparazione di nodetool, tutti gli intervalli falliscono con lo stesso errore.

In entrambi i casi sarà necessario eseguire un'altra riparazione di nodetool dopo che il problema di rete è stato risolto.

Non conosco la quantità di dati che hai in quei 6 nodi, ma nella mia esperienza se il cluster è in grado di gestirlo è meglio eseguire la riparazione di nodetool una volta alla settimana in un giorno diverso della settimana. Ad esempio, puoi riparare il nodo 1 di domenica, il nodo 2 di lunedì e così via. Se si dispone di una piccola quantità di dati o di aggiunte/aggiornamenti durante un giorno non sono molti, è possibile persino eseguire una riparazione una volta al giorno. Quando si ha un cluster già riparato e si esegue la riparazione di nodetool più spesso ci vorrà molto meno tempo per finire, ma ancora una volta se ci sono troppi dati in esso potrebbe non essere possibile.

Per quanto riguarda gli effetti collaterali è possibile notare solo una differenza nei dati se si utilizza il livello di coerenza 1, se accade che si esegue una query sul nodo "non riparato" i dati saranno diversi da quello sul "riparato" "nodi. Puoi risolvere questo problema aumentando il livello di coerenza a 2 per esempio, poi di nuovo se 2 nodi sono "non riparati" e la query che esegui viene risolta usando quei 2 nodi vedrai di nuovo una differenza. Hai un compromesso qui poiché l'opzione migliore per evitare questa "differenza" nelle query è di avere il livello di coerenza = fattore di replica, che porta un altro problema quando 1 dei nodi è inattivo l'intero cluster è inattivo e tu inizia a ricevere timeout sulle tue query.

Spero che aiuti!

Answer 2

Sono disponibili diverse opzioni di riparazione, è possibile sceglierne una a seconda dell'utilizzo dell'applicazione. Se si utilizza DSE Cassandra, si consiglia di pianificare la riparazione OpsCenter che esegue la riparazione incrementale fornendo una durata inferiore a gc_grace_seconds.

seguito sono diverse opzioni di riparazione fare:

1. predefinite (None): riparerà tutti i 3 campi di partizione: 1 primarie e 2 repliche di proprietà del nodo su cui è stato eseguito. Saranno coinvolti un totale di 5 nodi, 2 nodi risolveranno 1 intervallo di partizioni, 2 nodi fisseranno 2 intervalli di partizioni, 1 nodo fisserà 3 intervalli di partizioni.
2. -par: eseguirà l'operazione sopra descritta in parallelo.
3. -pr: risolverà solo l'intervallo di partizione primario per il nodo su cui è stato eseguito. Se si utilizza la coerenza di scrittura di EACH_QUORUM, utilizzare anche l'opzione -local per ridurre il traffico CC incrociato.

Suggerirei di andare con l'opzione 3 se si è già in produzione per evitare qualsiasi impatto sulle prestazioni dovuto alla riparazione.

Se si desidera leggere la riparazione in modo più dettagliato si prega di dare un'occhiata a questo here