La distribuzione di MongoDB in produzione può funzionare davvero solo se viene rispettato il modello di distribuzione corretto. La distribuzione di un set di repliche in un singolo host non garantisce l'elevata disponibilità dei dati. La gestione dei big data richiede ricerche approfondite e implementazioni ottimali, combinando le opzioni disponibili o scegliendo quella con i vantaggi più promettenti.
I modelli di distribuzione per MongoDB includono:
- Set di repliche a tre membri
- Set di repliche distribuiti su due o più data center.
Tre set di repliche di membri
La replica è una strategia di ridimensionamento per MongoDB che migliora l'elevata disponibilità dei dati. Un set di repliche prevede:
- Un nodo primario:responsabile di tutte le operazioni di throughput di scrittura e può anche essere letto.
- Nodi secondari:possono essere usati solo per operazioni di lettura ma possono essere eletti a primari in caso di guasto di quello esistente. Ottengono gli aggiornamenti dei dati da un oplog generato dal membro principale del set.
- Arbitro. Utilizzato per facilitare l'elezione di una primaria nel caso in cui vi sia un numero pari di membri del set di repliche. Non ospita alcuna copia dei dati.
I vantaggi di un set di repliche possono essere raggiunti solo con un numero minimo di tre membri con la seguente architettura:
Primario-Secondario-Secondario
Questo è il più consigliato poiché ha una maggiore tolleranza agli errori e risolve i limiti dell'aggiunta di un terzo membro di rilevamento dati, ad esempio i costi.
Questa distribuzione fornirà sempre due copie complete oltre ai dati primari, garantendo così un'elevata disponibilità. L'errore del primario attiverà il set di repliche per eleggere un nuovo primario e l'operazione di elaborazione riprenderà normalmente. Se la vecchia primaria diventa attiva, verrà classificata come membro secondario.
Durante il processo elettorale, i membri si scambiano un segnale non ci sono operazioni di scrittura in corso durante questo periodo
Dopo il processo elettorale assumiamo l'architettura da riformare come:
Arbitro primario-secondario
Ciò assicura che il set di repliche rimanga disponibile anche se il primario o il secondario non sono disponibili, facilitando il processo di elezione di un secondario a un primario. Gli arbitri non portano con sé alcuna copia dei dati, quindi richiedono meno risorse da gestire.
Una limitazione con questa distribuzione è; nessuna ridondanza poiché ci sono solo due membri portatori di dati:primario e secondario. Ciò si traduce in una minore tolleranza agli errori.
La tolleranza ai guasti dovrebbe essere in grado di garantire:
- Disponibilità di scrittura: la maggioranza dei membri del set di repliche votanti è necessaria per mantenere o eleggere il principale responsabile delle operazioni di scrittura.
- Ridondanza dei dati:la scrittura può essere riconosciuta da più membri per evitare rollback
La configurazione Primary-Secondary-Arbiter supporta l'aspetto della disponibilità in scrittura solo in modo tale che se un singolo membro del set non è disponibile, è ancora possibile mantenere un primario.
Tuttavia, il mancato supporto del secondo aspetto comporta alcune conseguenze operative se il membro secondario diventa non disponibile:
- Non ci sarà replica attiva soprattutto se il secondario è offline per molto tempo. Quando il secondario è offline per troppo tempo, potrebbe cadere dall'oplog costringendo a risincronizzarlo durante il riavvio.
- La ridondanza dei dati verrà sabotata forzando il riconoscimento dell'operazione di scrittura solo dal database primario corrente.
- L'opzione Maggioranza con preoccupazione non fornirà i dati più recenti alle applicazioni connesse e ai processi interni. Questo è il caso in cui la tua configurazione prevede che le scritture richiedano il riconoscimento della maggioranza, quindi viene bloccata fino a quando la maggior parte dei membri con dati non sarà disponibile.
- La migrazione dei blocchi tra gli shard sarà compromessa anche se il set di repliche fa parte di un cluster suddiviso.
- Pressione sulla cache del motore di archiviazione WiredTiger se si verificano rollback e il punto di commit della maggior parte non può essere avanzato.
Per evitare queste conseguenze, si può optare per una configurazione Primaria-Secondaria-Secondaria in quanto aumenta la tolleranza agli errori.
Nota:la tolleranza ai guasti non si verifica solo in caso di guasto, ma anche alcune operazioni di sistema come l'aggiornamento del software e la normale manutenzione potrebbero costringere un membro a non essere disponibile per breve tempo.
Set di repliche distribuiti su due o più data center
L'elevata disponibilità può essere elevata a un altro livello distribuendo i membri del set di repliche in data center geograficamente distinti. Questo approccio aumenterà la ridondanza oltre a garantire un'elevata tolleranza ai guasti nel caso in cui un data center non sia disponibile.
Se tutti i membri si trovano in un unico data center, il set di repliche è soggetto a guasti del data center come transitori di rete e interruzioni di corrente.
È consigliabile mantenere almeno un membro in un data center alternativo, utilizzare un numero dispari di data center e selezionare una distribuzione di membri che offra la maggioranza per l'elezione o almeno fornisca una copia dei dati in caso di fallimento.
La configurazione dovrebbe garantire che, in caso di guasto di un data center, il set di repliche rimanga scrivibile poiché i membri rimanenti possono tenere un'elezione.
Distribuisci i tuoi dati almeno su tre data center.
I membri possono essere limitati alle risorse o avere vincoli di rete, rendendoli quindi inadatti a diventare primari in caso di failover. Puoi configurare questi membri in modo che non diventino primari assegnando loro la priorità 0.
I membri in un data center possono avere una priorità maggiore rispetto ad altri data center per dare loro una priorità di voto in modo che possano eleggere primari prima dei membri in altri data center.
Tutti i membri del set di repliche dovrebbero essere in grado di comunicare tra loro.
Conclusione
I vantaggi della replica possono essere elevati a uno stato più promettente distribuendo i membri su una serie di data center. Ciò essenzialmente aumenta la tolleranza agli errori oltre a garantire la ridondanza dei dati. I membri del set di repliche, se distribuiti su due o più data center, offrono vantaggi rispetto a un singolo data center come:
Se uno dei data center si guasta, i dati sono ancora disponibili per le letture, a differenza della distribuzione di un singolo data center.
Le operazioni di scrittura possono ancora essere riconosciute ogni volta che un data center con membri di minoranza si interrompe.
Le operazioni di lettura possono essere ancora possibili se il data center con i membri a maggioranza votante non funziona a differenza del caso del data center singolo.
