Risoluzione dei problemi di un cluster partizionato MongoDB

In MongoDB, set di dati di grandi dimensioni implicano operazioni di throughput elevate e questo potrebbe sovraccaricare la capacità di un singolo server . Set di dati di lavoro di grandi dimensioni implicano uno stress maggiore sulla capacità di I/O dei dispositivi disco e possono causare problemi come Errori di pagina.

Ci sono principalmente due modi per risolvere questo problema...

Ridimensionamento verticale :aumento della capacità del singolo server. Ottenuto aggiungendo più CPU, RAM e spazio di archiviazione ma con una limitazione che:la tecnologia disponibile può impedire a una singola macchina di essere sufficientemente potente per alcuni carichi di lavoro. In pratica, esiste un massimo per il ridimensionamento verticale.

Ridimensionamento orizzontale tramite sharding :Ciò comporta la divisione del set di dati di sistema su più server, riducendo così il carico di lavoro complessivo per un singolo server. L'espansione della capacità della distribuzione richiede solo l'aggiunta di più server per ridurre i costi complessivi rispetto all'hardware di fascia alta per una singola macchina. Tuttavia, questo viene fornito con un compromesso che ci sarà molta complessità nell'infrastruttura e nella manutenzione per l'implementazione. La complessità diventa più sofisticata durante la risoluzione dei problemi del cluster partizionato in caso di emergenza. In questo blog, forniamo alcune delle possibilità di risoluzione dei problemi che potrebbero essere utili:

Selezione di chiavi shard e disponibilità del cluster

L'istanza Mongos non è più disponibile

Un membro diventa assente dal set di repliche di frammenti

Tutti i membri di un set di repliche sono assenti

I dati di configurazione non aggiornati portano a errori del cursore

Il server di configurazione non è disponibile

Correzione dell'errore della stringa del database

Evitare tempi di inattività durante lo spostamento dei server di configurazione

Selezione di chiavi shard e disponibilità del cluster

Lo sharding comporta la divisione dei dati in piccoli gruppi chiamati shard in modo da ridurre il carico di lavoro complessivo per un determinato throughput operazione. Questo raggruppamento si ottiene selezionando una chiave ottimale che è principalmente la parte più importante prima dello sharding. Una chiave ottimale dovrebbe garantire:

Mongos può isolare la maggior parte delle query a un mongod specifico. Se, ad esempio, più operazioni sono soggette a un singolo shard, l'errore di tale shard renderà solo i dati ad esso associati assenti in quel momento. È consigliabile selezionare una chiave shard che fornisca più shard per ridurre la quantità di dati indisponibili in caso di arresto anomalo dello shard.

MongoDB sarà in grado di dividere i dati in modo uniforme tra i blocchi. Ciò garantisce che anche le operazioni di throughput vengano distribuite in modo uniforme, riducendo le possibilità di errori dovuti a un maggiore stress del carico di lavoro.

Scrivi la scalabilità nel cluster per garantire un'elevata disponibilità. Ogni shard dovrebbe essere un set di repliche in quanto se una certa istanza mongod fallisce, i restanti membri del set di repliche sono in grado di eleggere un altro membro come primario, garantendo così la continuità operativa.

Se in ogni caso un determinato shard tende a fallire, inizia controllando quante operazioni di throughput è soggetto e valuta la possibilità di selezionare una chiave di partizionamento orizzontale migliore per avere più partizioni.

E se? L'istanza di Mongos diventa assente

Per prima cosa controlla se ti stai connettendo alla porta giusta poiché potresti essere cambiato inconsapevolmente. Ad esempio, durante la distribuzione con la piattaforma AWS esiste la probabilità che si verifichi questo problema a causa dei gruppi di sicurezza che potrebbero non consentire le connessioni su quella porta. Per un test immediato, prova a specificare host:port completo per assicurarti di utilizzare un'interfaccia di loopback. La cosa buona è che se ogni server delle applicazioni ha la propria istanza mongos, i server delle applicazioni possono continuare ad accedere al database. Inoltre, le istanze mongos hanno il loro stato alterato nel tempo e possono riavviarsi senza necessariamente perdere dati. Quando l'istanza viene riconnessa, recupererà una copia del database di configurazione e inizierà a instradare le query.

Assicurati che anche la porta su cui stai tentando di riconnetterti non sia occupata da un altro processo.

E se? Un membro diventa assente dal set di repliche di frammenti

Inizia controllando lo stato dello shard eseguendo il comando sh.status(). Se il risultato restituito non ha clusterId, lo shard non è effettivamente disponibile. Indaga sempre su interruzioni e guasti della disponibilità e se non riesci a recuperarlo nel più breve tempo possibile, crea un nuovo membro per sostituirlo il prima possibile in modo da evitare ulteriori perdite di dati.

Se un membro secondario diventa non disponibile ma con voci oplog correnti, una volta ricollegato può recuperare il ritardo ultimo stato impostato leggendo i dati correnti dall'oplog come normale processo di replica. Se non riesce a replicare i dati, devi eseguire una sincronizzazione iniziale utilizzando una di queste due opzioni...

Riavvia mongod con una directory di dati vuota e lascia che la normale funzione di sincronizzazione iniziale di MongoDB ripristini i dati. Tuttavia, questo approccio richiede molto tempo per copiare i dati, ma è abbastanza semplice.

Riavvia la macchina host con una copia di una directory di dati recente da un altro membro nel set di repliche. Processo rapido ma con passaggi complicati

La sincronizzazione iniziale consentirà a MongoDB di...

Clone tutti i database disponibili tranne il banca dati locale. Assicurati che il membro di destinazione disponga di spazio su disco sufficiente nel database locale per archiviare temporaneamente i record oplog per la durata della copia dei dati.

Applica tutte le modifiche al set di dati usando l'oplog dalla fonte. Il processo sarà completo solo se lo stato della replica passa da STARTUP2 a SECONDARY.

E se? Tutti i membri di un set di repliche sono assenti

I dati contenuti in uno shard non saranno disponibili se tutti i membri di uno shard del set di repliche diventano assenti. Poiché gli altri shard rimangono disponibili, le operazioni di lettura e scrittura sono ancora possibili, tranne per il fatto che l'applicazione verrà servita con dati parziali. Dovrai indagare sulla causa delle interruzioni e provare a riattivare lo shard il prima possibile. Controlla quale profilatore di query o il metodo di spiegazione che potrebbe aver portato a quel problema.

E se? I dati di configurazione obsoleti portano a errori del cursore

A volte un'istanza mongos può impiegare molto tempo per aggiornare la cache dei metadati dal database di configurazione portando alla restituzione di una query l'avviso:

could not initialize cursor across all shards because : stale config detected

Questo errore verrà sempre presentato fino a quando le istanze mongos non aggiorneranno le loro cache. Questo non dovrebbe propagarsi all'applicazione. Per risolvere questo problema, devi forzare l'aggiornamento dell'istanza eseguendo fluRouterConfig.

Per svuotare la cache per un'esecuzione di una raccolta specifica

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Per svuotare la cache per un'esecuzione specifica del database

db.adminCommand({ flushRouterConfig: "<db>" } )

Per svuotare la cache per tutti i database e le relative raccolte, esegui:

db.adminCommand("flushRouterConfig") db.adminCommand( { flushRouterConfig: 1 } )

E se? Il server di configurazione diventa non disponibile

Il server di configurazione in questo caso può essere considerato come il membro primario da cui i nodi secondari replicano i propri dati. Se diventa assente, i nodi secondari disponibili dovranno eleggerne uno tra i propri membri per diventare il primario. Per evitare di entrare in una situazione in cui potresti non disporre di un server di configurazione, considera la possibilità di distribuire i membri del set di repliche tra due data center dal momento che...

Se un data center non funziona, i dati saranno comunque disponibili per le letture anziché per nessuna operazione se hai utilizzato un singolo data center .

Se il data center che comprende membri di minoranza si interrompe, il set di repliche può comunque servire sia operazioni di scrittura che di lettura.

È consigliabile distribuire i membri su almeno tre data center.

Un'altra possibilità di distribuzione consiste nel distribuire uniformemente i membri portanti dati tra i due data center e i membri rimanenti in la nuvola.

Correzione dell'errore della stringa del database

A partire da MongoDB 3.4, i server di configurazione SCCC non sono supportati per le istanze mongod con mirroring. Se devi aggiornare il tuo cluster partizionato alla versione 3.4, devi convertire i server di configurazione da SCCC a CSRS.

Evitare i tempi di inattività quando si spostano i server di configurazione

I tempi di inattività possono verificarsi a causa di alcuni fattori come interruzioni di alimentazione o frequenze di rete, con conseguente errore di un server di configurazione nel cluster. Utilizzare CNAME per identificare quel server per la ridenominazione o la rinumerazione durante la riconnessione. Se il comando di commit moveChunk non riesce durante il processo di migrazione, MongoDB segnalerà l'errore:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"

Ciò significa che anche lo shard non è stato connesso al database di configurazione, quindi il primary terminerà questo membro per evitare l'incoerenza dei dati. È necessario risolvere l'errore di migrazione del blocco in modo indipendente consultando il supporto MongoDB. Assicurati inoltre di fornire alcune risorse stabili come rete e alimentazione al cluster.

Conclusione

Un cluster sharded MongoDB riduce il carico di lavoro a cui sarebbe stato sottoposto un singolo server, migliorando così le prestazioni delle operazioni di throughput. Tuttavia, la mancata configurazione corretta di alcuni parametri, come la selezione di una chiave shard ottimale, può creare uno squilibrio del carico, quindi alcuni shard finiscono per non funzionare.

Presupponendo che la configurazione sia stata eseguita correttamente, potrebbero verificarsi anche alcune inevitabili battute d'arresto come interruzioni di corrente. Per continuare a supportare la tua applicazione con tempi di inattività minimi, considera l'utilizzo di almeno 3 data center. Se uno fallisce, gli altri saranno disponibili per supportare le operazioni di lettura se il primario è tra i membri interessati. Aggiorna anche il tuo sistema almeno alla versione 3.4 poiché supporta più funzionalità.