2013-03-12 10 views
6

Abbiamo un cluster Cassandra con un singolo token per nodo, 22 nodi totali, il carico medio per nodo è 500Gb. Ha SimpleStrategy per lo spazio chiavi principale e SimpleSnitch.Come migrare il cluster a singolo token in un nuovo cluster vnodes senza tempi di inattività?

Abbiamo bisogno di migrare tutti i dati nel nuovo datacenter e chiudere il vecchio senza tempi di fermo. Il nuovo cluster ha 28 nodi. Voglio avere i vnodes su di esso.

Sto pensando al seguente processo:

  1. migrare le vecchie cluster per vnodi
  2. Imposta il nuovo cluster con vnodi
  3. aggiungere nodi dal nuovo cluster a quello vecchio e attendere riequilibra tutto
  4. clienti passare al nuovo cluster
  5. Rimuovere le autorizzazioni nodi dal cluster precedente una ad una

Ma ci sono molti dettagli tecnici. Prima di tutto, dovrei mescolare il vecchio cluster dopo la migrazione di vnodes? Quindi, qual è il modo migliore per passare a NetworkTopologyStrategy e a GossipingPropertyFileSnitch? Voglio passare a NetworkTopologyStrategy perché il nuovo cluster ha 2 diversi rack con switch di alimentazione/rete separati.

+1

consiglio pro: provalo prima in un ambiente di prova/non di produzione. – Schildmeijer

+0

sì, questo è quello che sto facendo ora – relgames

risposta

5

devo mescolare il vecchio cluster dopo la migrazione di vnodes?

Non è necessario. Se si passa da un token per nodo a 256 (il valore predefinito), ciascun nodo dividerà il suo intervallo in 256 intervalli adiacenti di uguali dimensioni. Ciò non influisce sulla vita dei dati. Ma ciò significa che quando si esegue il bootstrap in un nuovo nodo nel nuovo DC, esso rimarrà bilanciato durante tutto il processo.

qual è il modo migliore per passare a NetworkTopologyStrategy e a GossipingPropertyFileSnitch?

La difficoltà è che la commutazione della strategia di replica non è generalmente sicura poiché i dati devono essere spostati nel cluster. NetworkToplogyStrategy (NTS) posizionerà i dati su diversi nodi se gli dirai che i nodi si trovano in rack diversi. Per questo motivo, è necessario passare a NTS prima di aggiungere i nuovi nodi.

Ecco un metodo per fare questo, dopo aver aggiornato il cluster precedente a vnodi (sopra il punto 1):

1a. Elencare tutti i nodi esistenti come in DC0 nel file delle proprietà. Elenca i nuovi nodi come in DC1 e nei loro rack corretti.

1b. Modificare la strategia di replica in NTS con le opzioni DC0: 3 (o qualsiasi sia il fattore di replica corrente) e DC1: 0.

Quindi per aggiungere i nuovi nodi, seguire la procedura qui: http://www.datastax.com/docs/1.2/operations/add_replace_nodes#adding-a-data-center-to-a-cluster. Ricordarsi di impostare il numero di token su 256 poiché sarà 1 per impostazione predefinita.

Nel passaggio 5, è necessario impostare il fattore di replica per DC0 su 0, ovvero modificare le opzioni di replica su DC0: 0, DC1: 3. Ora questi nodi non vengono utilizzati, quindi la rimozione delle autorizzazioni non invierà alcun flusso di dati, ma dovresti farlo comunque piuttosto che spegnerli in modo che vengano rimossi dal ring.

Nota un rischio è che le scritture eseguite a un livello di coerenza basso nei vecchi nodi potrebbero andare perse. Per evitare questo, è possibile scrivere su CL.LOCAL_QUORUM dopo aver effettuato il passaggio al nuovo controller di dominio. C'è ancora una piccola finestra in cui le scritture potrebbero andare perse (tra i passaggi 3 e 4). Se è importante, è possibile eseguire la riparazione prima di rimuovere i vecchi nodi per garantire perdite o scrivere ad un livello di coerenza elevato.

+0

_le scritture fatte a un livello di coerenza basso ai vecchi nodi potrebbero perdersi_ Puoi spiegare perché? Non so se è importante, ma non sovrascriviamo i vecchi valori, aggiungiamo sempre nuovi dati. Questo è il modo in cui lo vedo: 1. DC0 e DC1 sono attivi, i client utilizzano DC0, il flusso di dati è DC0 -> DC1 2. Switch: i client utilizzano DC1, il flusso di dati è DC0-> DC1 e DC1- > DC0 3. I vecchi dati vengono trasferiti a DC1, il flusso è solo DC1-> DC0 4. Impostare DC0: 0, nessun trasferimento di dati tra DC0 e DC1 Effettivamente vedo che alcune letture da DC1 al punto 2 potrebbero non vedere dati che sono ancora solo in DC0, ma possiamo convivere con questo. Ma non è perso. – relgames

+0

Durante il passaggio 3, anche se il client è connesso a un nodo in DC1, non è garantito scrivere un valore in un nodo in DC1 a livelli di coerenza bassi. Per esempio. se si scrive in CL.ONE, tutte le repliche in DC1 potrebbero non riuscire (ad esempio perché troppo occupate in modo da eliminare la scrittura) e la scrittura finisce solo su un nodo in DC0. Quando si imposta DC0: 0, questa scrittura viene persa anche se è stata confermata dal client. – Richard

+0

Qualche idea sul perché Datastax sta dicendo non farlo più? http://datastax.com/documentation/cassandra/2.0/cassandra/configuration/configVnodesProduction_t.html - anche qui http://www.datastax.com/dev/blog/upgrading-an-existing-cluster-to-vnodes- 2 – chrislovecnm

-1

Se si sta tentando di migrare a un nuovo cluster con vnodes, non sarebbe necessario modificare il partizionatore. I documenti dicono che non è una buona idea migrare i dati tra diversi partizionatori.

+0

No, la scelta del partizionatore è indipendente dai vnode. – Richard