2014-09-24 17 views
9

Dal documentation:Chiarimenti riparazione nodetool -pr

Uso del -pr nodetool riparazione (-partitioner-range) riparazioni opzione solo l'intervallo primario per quel nodo, l'altra repliche per quell'intervallo devono ancora eseguire il calcolo dell'albero Merkle, causando una compattazione della convalida. Poiché tutte le repliche compattano contemporaneamente, , tutti i nodi potrebbero rispondere lentamente per quella porzione di dati.

Probabilmente non c'è mai un momento in cui sia possibile accettare che tutti i nodi siano lenti per una determinata porzione di dati. Ma mi chiedo: perché fa fare che (o è forse solo un disguido con l'opzione "-par" nella documentazione ?!), quando nodetool repair sembra essere smarter:

Per impostazione predefinita, il il comando di riparazione acquisisce immediatamente un'istantanea di ogni replica e quindi ripara in sequenza ciascuna replica dagli snapshot. Ad esempio, se si dispone di RF = 3 e A, B e C rappresentano tre repliche, questo comando cattura immediatamente un'istantanea di ciascuna replica e quindi ripara sequenzialmente ogni replica dalle istantanee (A < -> B, A < -> C, B < -> C) invece di riparare A, B e C tutti in una volta. Ciò consente allo snitch dinamico di mantenere le prestazioni per l'applicazione tramite le altre repliche, poiché almeno una replica nell'istantanea non è in riparazione.

Tuttavia, il blog datastax addresses this issue:

Questa prima fase può essere intensiva su Io rigido, tuttavia. È possibile attenuarlo in una certa misura con la compattazione (poiché questa fase è quella che chiamiamo compattazione della convalida). A volte ciò non è sufficiente e alcune persone cercano di attenuarla ulteriormente utilizzando l'opzione -pr (-partitioner-range) opzione per la riparazione di nodetool, che ripara solo l'intervallo primario per quel nodo. Sfortunatamente, le altre repliche per quell'intervallo dovranno comunque eseguire il calcolo dell'albero Merkle, causando una compattazione della convalida. Questo può essere un problema, dal momento che tutte le repliche lo faranno allo stesso tempo, probabilmente facendo in modo che siano tutte lente a rispondere per quella porzione di dati. Fortunatamente, c'è modo di aggirare questo usando l'opzione -snapshot.

che potrebbe essere bello, ma in realtà, non esiste alcuna opzione per -snapshotnodetool repair (vedi la pagina di manuale, o il documentation) (è stato rimosso questa opzione ?!)

Quindi nel complesso,

  • Non riesco a utilizzare nodetool repair -pr, a quanto pare, perché ho sempre bisogno almeno di mantenere il sistema abbastanza reattivo per leggere/scrivere con coerenza UNO, senza un ritardo significativo. (Nota: disponiamo di un solo centro dati.) O sto perdendo/fraintendendo qualcosa?
  • Perché è nodetool repair intelligente, mantenendo un nodo reattivo, mentre nodetool repair -pr rende tutti i nodi lenti per una porzione di dati?
  • Dove si trova l'opzione -snapshot: è stata rimossa, mai implementata oppure ora funziona automaticamente in questo modo, anche quando si utilizza nodetool repair -pr?
+2

Sembra sicuro ipotizzare che al momento della stesura del blog (luglio 2013) esistesse un'opzione di istantanea perché i documenti di Cassandra 1.2 parlano di un'opzione nodetool repair -snapshot: http://www.datastax.com/documentation/cassandra/ 1.2/Cassandra/operazioni/ops_repair_nodes_c.html. – catpaws

+1

Questo documento ha alcune informazioni sull'utilizzo di nodetool (opzione -pr non consigliata) e include esempi di utilizzo dell'opzione parallela (par). http://www.datastax.com/documentation/cassandra/2.1/cassandra/tools/toolsRepair.html?scroll=toolsRepair__toolsRepairTypes – catpaws

+0

@catpaws: Grazie, entrambi i tuoi commenti contengono alcune informazioni molto preziose (che in realtà non sono nel 2.0 documentazione)! –

risposta

5

Il blog di seguito affronta questi temi:

http://www.datastax.com/dev/blog/repair-in-cassandra

Un semplice nodetool repair non solo dare il via una riparazione sul nodo stesso, ma anche tutti i nodi che tengono le repliche, se le sue gamme. Mentre questo è ok, è molto costoso e in genere non è un'operazione che eseguirai su un sistema di produzione occupato durante le ore di punta.

Di conseguenza nodetool repair -pr eseguirà una riparazione degli intervalli primari su quel nodo. Dovrai eseguirlo su ogni nodo del cluster come dice il blog. I clienti con sistemi di produzione di grandi dimensioni in genere lo utilizzano in modo scorrevole sul loro cluster.

In un'altra nota Datastax OpsCenter offre lo repair service che esegue sempre più piccole riparazioni di sottofondo, anche se si sta sempre riparando in background tutto il tempo a un livello di risorse inferiore.

Per quanto riguarda le istantanee, l'esecuzione di una riparazione normale richiamerà un'istantanea come lei ha dichiarato, è anche possibile richiamare uno snapshot da soli, usando nodetool snapshot

Spero che questo aiuti!

Problemi correlati