Di seguito è riportato un estratto dal nostro whitepaper "MongoDB Management and Automation with ClusterControl" che può essere scaricato gratuitamente.
Considerazioni per l'amministrazione di MongoDB
Ridondanza integrata
Una caratteristica fondamentale di MongoDB è la sua ridondanza incorporata, sotto forma di replica. Se hai due o più nodi di dati, possono essere configurati come un set di repliche, in cui tutti i dati scritti sul nodo primario vengono replicati quasi in tempo reale sui nodi secondari,
Set di repliche MongoDB
garantendo più copie dei dati. Nel caso del failover primario, i nodi rimanenti nel set di repliche effettuano un'elezione e promuovono il vincitore come primario, un processo che in genere richiede 2-3 secondi e può riprendere le scritture nel set di repliche. MongoDB utilizza anche un journal per scritture più rapide e sicure sul server o sul set di repliche e impiega anche un metodo di "richiesta di scrittura" attraverso il quale il livello di ridondanza della scrittura è
configurato.
Per distribuire manualmente un set di repliche, i passaggi di alto livello sono i seguenti:
- Assegna un singolo host fisico o virtuale per ciascun nodo del database e installa il client della riga di comando MongoDB sul desktop. Per una configurazione del set di repliche ridondante, sono necessari almeno tre nodi, di cui almeno due saranno nodi di dati. Un nodo nel set di repliche può essere configurato come arbitro:questo è un processo mongod configurato solo per creare un quorum fornendo un voto nell'elezione di una Primaria quando richiesto. I dati non vengono replicati nei processi dell'arbitro.
- Installa MongoDB su ogni nodo. Alcune distribuzioni Linux includono MongoDB Community Edition, ma tieni presente che queste potrebbero non includere le ultime versioni. MongoDB Enterprise è disponibile solo tramite download dal sito Web di MongoDB. Funzionalità simili a MongoDB Enterprise sono disponibili anche tramite Percona Server per MongoDB, un sostituto drop-in di MongoDB Enterprise o Community Edition.
- Configura i singoli file di configurazione mongod.conf per il tuo set di repliche, utilizzando il "parametro di replica". Se utilizzerai un file chiave per la sicurezza, configuralo ora anche. Tieni presente che l'utilizzo della sicurezza dei file delle chiavi consente anche l'autenticazione basata sui ruoli, quindi dovrai anche aggiungere utenti e ruoli per utilizzare i server. Riavvia il processo mongod su ciascun server.
- Garantire la connettività tra i nodi. Devi assicurarti che i nodi del set di repliche MongoDB possano comunicare tra loro sulla porta 27017 e anche che i tuoi client possano connettersi a ciascuno dei nodi del set di repliche sulla stessa porta.
- Utilizzando il client della riga di comando MongoDB, connettiti a uno dei server ed esegui rs.initiate() per inizializzare il tuo set di repliche, seguito da rs.add() per ogni nodo aggiuntivo. rs.conf() può essere utilizzato per visualizzare la configurazione.
Sebbene questi passaggi non siano così complessi come la distribuzione e la configurazione di un cluster con partizionamento orizzontale MongoDB o il partizionamento orizzontale di un database relazionale, possono essere onerosi e soggetti a errori, soprattutto in ambienti più grandi.
Scalabilità
MongoDB viene spesso definito software di database "scala web", a causa della sua capacità di ridimensionamento orizzontale. Come i database relazionali, è possibile ridimensionare MongoDB verticalmente, semplicemente aggiornando l'host fisico su cui risiede con più core CPU, più RAM, dischi più veloci o persino una maggiore velocità del bus. Il ridimensionamento verticale ha tuttavia i suoi limiti, sia in termini di rapporto costi-benefici e rendimenti decrescenti, sia di limitazione tecnica. Per risolvere questo problema, MongoDB ha una funzione di "sharding automatico", che consente ai database di essere suddivisi su molti host (o set di repliche, per ridondanza). Sebbene lo sharding sia possibile anche su piattaforme relazionali, a meno che non sia progettato per l'avvio del database, ciò richiede un'importante riprogettazione dello schema e dell'applicazione, nonché una riprogettazione dell'applicazione client, il che rende questo processo noioso, dispendioso in termini di tempo e soggetto a errori.
Lo sharding di MongoDB funziona introducendo un processo router, attraverso il quale i client si connettono al cluster frammentato, e server di configurazione, che memorizzano i metadati del cluster, la posizione nel cluster di ciascun documento. Quando un client invia una query al processo del router, prima fa riferimento ai server di configurazione per ottenere le posizioni dei documenti, quindi ottiene i risultati della query direttamente dai singoli server o
set di repliche (shard). Lo sharding viene effettuato in base alla raccolta.
Un parametro di fondamentale importanza in questo caso, ai fini delle prestazioni, è la "chiave shard", un campo indicizzato o un campo composto che esiste in ogni documento in una raccolta. È questo che definisce la distribuzione della scrittura tra gli shard di una raccolta. Pertanto, una chiave shard scelta male può avere un effetto molto dannoso sulle prestazioni. Ad esempio, una chiave shard basata esclusivamente su serie temporali può comportare che tutte le scritture vengano inviate a un singolo nodo per periodi di tempo estesi. Tuttavia, una chiave shard con hash, pur distribuendo uniformemente le scritture tra gli shard, può influire sulle prestazioni di lettura poiché un set di risultati viene recuperato da molti nodi.
MongoDB Sharded ClusterSeveralnines Diventa un DBA MongoDB - Portare MongoDB in produzioneScopri cosa devi sapere per distribuire, monitorare, gestisci e ridimensiona MongoDBDownload gratuitamente Arbitri
Un arbitro MongoDB è un processo mongod che è stato configurato non per fungere da nodo di dati, ma per fornire solo la funzione di votazione quando un set di repliche deve essere eletto Primario, per rompere i pareggi e proteggersi da un voto diviso. Un arbitro non può diventare Primario, in quanto non detiene una copia dei dati né accetta scritture. Sebbene sia possibile avere più di un arbitro in un set di repliche, generalmente non è consigliabile.
Elezioni MongoDB e processo arbitrale Membri del set di repliche ritardate
I membri del set di repliche ritardate aggiungono un ulteriore livello di ridondanza, mantenendo uno stato che è un numero fisso di secondi indietro rispetto al Primario. Poiché i membri ritardati sono un "backup in sequenza" o uno snapshot "storico" in esecuzione del set di dati, possono aiutare a recuperare da vari tipi di errori umani.
I membri ritardati sono membri del set di repliche "nascosti", invisibili alle applicazioni client e quindi non possono essere interrogati direttamente. Inoltre potrebbero non diventare primari durante le normali operazioni e devono essere riconfigurati manualmente nel caso in cui debbano essere utilizzati per il ripristino da un errore.
Nodo secondario ritardato MongoDB Backup
Il backup di un set di repliche o di un cluster partizionato viene eseguito tramite l'utilità della riga di comando "mongodump". Se utilizzato con il parametro --oplog, crea un dump del database che include un oplog, per creare uno snapshot point-in-time dello stato di un'istanza mongod. Utilizzando mongorestore con il parametro --replayOplog, puoi quindi ripristinare completamente lo stato dei dati al momento del completamento del backup, evitando incoerenze.
Per requisiti di backup più avanzati, è disponibile uno strumento di terze parti chiamato "mongodbconsistent-backup", anch'esso basato sulla riga di comando, che fornisce backup completamente coerenti dei cluster partizionati, una procedura complessa, dato che i database partizionati sono distribuiti su più host.
Monitoraggio
Sul mercato sono disponibili numerosi strumenti commerciali, sia ufficiali che non ufficiali, per il monitoraggio di MongoDB. Questi strumenti, in generale, sono utilità di gestione di un singolo prodotto, incentrate esclusivamente su MongoDB. Molti si concentrano solo su alcuni aspetti specifici, come la gestione della raccolta in un'architettura MongoDB esistente, o sui backup o sulla distribuzione. Senza un'adeguata pianificazione, ciò può portare a una situazione in cui è necessario distribuire e gestire una proliferazione di strumenti aggiuntivi nel tuo ambiente.
Gli strumenti a riga di comando forniti con MongoDB, "mongotop" e "mongostat" possono fornire una vista dettagliata delle prestazioni degli ambienti e possono essere utilizzati per diagnosticare problemi. Inoltre, il client della riga di comando "mongo" di MongoDB può anche eseguire "rs.status()" - o in un cluster partizionato "sh.status() - per visualizzare lo stato dei set di repliche o dei cluster e dei relativi host membri. Il comando "db.stats()" restituisce un documento che affronta l'uso della memoria e i volumi di dati, e i loro equivalenti per le raccolte, così come altre chiamate per accedere a molte metriche interne.
Sinossi
Questa è stata una breve sinossi delle considerazioni per l'amministrazione di MongoDB. Anche a un livello così alto, tuttavia, dovrebbe essere immediatamente ovvio che mentre è possibile amministrare un set di repliche o un cluster partizionato dalla riga di comando utilizzando gli strumenti disponibili, questo non è scalabile in un ambiente con molti set di repliche o con una grande produzione cluster frammentato. In ambienti di dimensioni medio-grandi che comprendono molti host
e database, diventa rapidamente impossibile gestire tutto con strumenti e script da riga di comando. Sebbene sia possibile sviluppare strumenti e script interni per implementare e mantenere l'ambiente, ciò aggiunge l'onere della gestione del nuovo sviluppo, dei sistemi di controllo delle revisioni e dei processi. Un semplice aggiornamento di un server di database può diventare un processo complesso se sono necessarie modifiche agli strumenti per supportare nuove versioni di database
server.
Ma senza strumenti e script interni, come possiamo automatizzare e gestire i cluster MongoDB? Scarica il whitepaper per scoprire come fare!
