Una checklist per lo sviluppo e le operazioni per MongoDB

Le liste di controllo per il funzionamento e lo sviluppo di MongoDB hanno lo scopo di aiutare gli amministratori di database a evitare problemi nell'ambiente di produzione di MongoDB. Una lista di controllo per lo sviluppo dovrebbe affrontare problemi come...

1. Progettazione dello schema
2. Durata dei dati
3. Replica
4. Drive 
5. Sharding 

Una lista di controllo delle operazioni, invece, indirizzi...

1. Replica
2. Filesystem 
3. Sharding
4. Hardware
5. Journaling (WiredTiger Storage Engine) 
6. Configurazioni del sistema operativo 
7. Distribuzione su hardware cloud 
8. Monitoraggio
9. Backup e bilanciamento del carico

Prima di avviare un progetto è consigliabile lavorare su un elenco di controllo operativo e di sviluppo per consentire il corretto funzionamento di  MongoDB in produzione. Questo articolo spiega l'elenco di controllo per il funzionamento e lo sviluppo prima di distribuire MongoDB.

Elenco di controllo delle operazioni MongoDB

Replica

Tutti i set di membri di replica che non sono nascosti devono essere forniti in modo identico per quanto riguarda disco, RAM, configurazione di rete e CPU.

Le dimensioni di Oplog devono essere configurate correttamente per soddisfare le esigenze operative in modo tale che:

• Per evitare la necessità di una risincronizzazione completa, la finestra dell'applicazione oplog di replica dovrebbe coprire i normali tempi di inattività e la finestra di manutenzione.
• Per ripristinare un membro del set di repliche, la finestra oplog di replica dovrebbe sempre coprire il tempo necessario.

Il set di produzione come minimo dovrebbe incorporare tre nodi contenenti dati che vengono eseguiti con il journaling abilitato. Inoltre, le scritture dovrebbero essere emesse con w:"maggioranza" preoccupazione di scrittura allo scopo di garantire la disponibilità e la durabilità dei dati.

La distribuzione dovrebbe contenere un numero dispari di membri votanti per facilitare il processo di votazione ogni volta che il nodo primario nel cluster si guasta.

Invece di utilizzare indirizzi IP che potrebbero richiedere la modifica delle configurazioni a causa della modifica dell'IP, si consiglia l'uso di nomi host DNS logici.

Assicurati che le istanze mongod abbiano 0 o 1 voti.

Tutte le istanze di Mongod dovrebbero essere completamente e bidirezionalmente connesse in modo tale che vi sia facilità di comunicazione dei dati tra i nodi coinvolti.

Diario

Questa è una strategia di scrittura anticipata dei file journal su disco utilizzata per garantire la durabilità dei dati in caso di errore. Per questo motivo, in tutte le istanze dovrebbe essere abilitato il journaling, specialmente quando si tratta di carichi di lavoro ad alta intensità di scrittura.

Tuttavia, tieni presente che ciò influisce sui rinforzi in stile snapshot poiché i record che costituiscono lo stato del database rimarranno su volumi partizionati.

File system

Non utilizzare unità News File System (NFS) per dbPath. Le unità NFS possono causare una destabilizzazione delle prestazioni. Le unità virtuali VMware sono consigliate per l'utilizzo da parte degli utenti VMware.

Assicurati che le partizioni del tuo disco siano allineate con le tue configurazioni RAIDON.

Per gli utenti Linux/Unix, si consiglia l'uso di XFS. XFS è noto per funzionare meglio con MongoDB.

Per gli utenti del sistema operativo Windows, si consiglia il file system NTFS. Dovresti evitare di utilizzare qualsiasi file system FAT.

Distribuzione su hardware cloud

Windows Azure:modificare il TCP keepalive (tcp_keepalive_time) a 100-120. Anche il timeout fuori marcia TCP nel servizio di bilanciamento dello stack di Azure è moderato per il comportamento del pool di associazioni di MongoDB

Usa MongoDB 2.6.4 o versioni successive su framework con storage a latenza elevata, come Windows Azure, poiché queste versioni incorporano miglioramenti di esecuzione per tali framework.

Sharding

Posiziona i tuoi server di configurazione su hardware dedicato per un'esecuzione ideale in cluster estesi.

Assicurati che l'hardware disponga di RAM sufficiente per contenere i record di informazioni interamente in memoria e di uno spazio di archiviazione dedicato.

Implementa i router mongos in conformità con le linee guida per l'impostazione della generazione.

Sincronizza gli orologi su tutti i componenti del tuo cluster partizionato utilizzando NTP.

Garantire una rete bidirezionale completa tra mongos, mongod e config server.

Utilizza i CNAME per riconoscere i tuoi server di configurazione nel cluster in modo da poter rinominare e rinumerare i tuoi server di configurazione senza tempi di inattività.

Monitoraggio

Puoi utilizzare strumenti come MongoDB Cloud Manager, ClusterControl o un altro framework di monitoraggio per visualizzare le metriche chiave del database e impostare allarmi. Incorpora avvisi per le metriche:

• Code
• Finestra oplog replica
• Affermazioni
• Errori di pagina
• Ritardo di replica

Monitoraggio delle metriche hardware per i tuoi server. Prestare particolare attenzione allo spazio disponibile su disco, all'utilizzo del disco, alla CPU

Hardware

Utilizza unità RAID10 e SSD per prestazioni ideali.

SAN e virtualizzazione:

Assicurati che ciascuna delle istanze mongod abbia effettuato il provisioning di IOPS per il suo dbPath o abbia la sua unità fisica di richiesta o LUN.

Evita l'evidenziazione dinamica della memoria, come il rigonfiamento della memoria, durante l'esecuzione in ambienti virtuali.

Evita di impostare tutti i gruppi di copie sulla stessa SAN, poiché la SAN può essere un singolo punto di delusione.

Bilanciamento del carico

Progettare sistemi di bilanciamento del carico per abilitare "sessioni permanenti" o "affinità client" con un timeout adeguato per le connessioni esistenti.

Evita di inserire bilanciatori di carico tra il cluster MongoDB o i componenti del set di repliche.

Backup

Pianifica test intermittenti del processo di backup e ripristino per avere a portata di mano indicatori di tempo e confermarne l'utilità.

Configurazione del sistema operativo

Finestre

Considera la disattivazione degli aggiornamenti NTFS "ora dell'ultimo accesso".

Formatta i dischi NTFS utilizzando la dimensione dell'unità di allocazione predefinita di 4096 byte.

Linux

Spegni le grandi pagine trasparenti.

Esegui modifiche alle impostazioni del lettore dei dadi in cui sono archiviati i file del database. Il readahead del motore di archiviazione WiredTiger deve essere impostato tra 8 e 32.

Se utilizzi tuning su RHEL / CentOS, devi personalizzare il tuo profilo modificato. Numerosi profili ottimizzati forniti con RHEL/CentOS possono influire negativamente sull'esecuzione con le impostazioni predefinite. Personalizza il profilo sintonizzato che hai scelto su:

Disabilita pagine enormi semplici.

Imposta readahead tra 8 e 32 in ogni caso di capacità media sort.

Utilizza gli scheduler del disco noop o di scadenza per le unità SSD.

Utilizza lo scheduler del disco noop per le unità virtualizzate nelle VM guest.

Disabilita NUMA o imposta vm.zone_reclaim_mode su 0 ed esegui le occorrenze mongod con l'interleaving dei nodi.

Regola i valori ulimit sul tuo hardware in modo che corrispondano al tuo caso d'uso. Nel caso in cui diverse occorrenze mongod o mongos siano in esecuzione sotto lo stesso client, ridimensionare i valori ulimit allo stesso modo.

Progettare handle di record adeguati (fs.file-max), vincolo pid parte (kernel.pid_max), thread massimo per processo (kernel.threads-max) e numero massimo di aree di contorno di memoria per processo (vm.max_map_count) per l'invio. Per framework espansivi, i seguenti valori forniscono un ottimo punto di partenza:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Assicurati che nel tuo framework sia configurato lo spazio di scambio.

Allude alla documentazione del tuo sistema operativo per i punti di interesse sul corretto dimensionamento.

 Assicurati che il keep-alive TCP predefinito del sistema sia impostato correttamente. Un valore di 300 spesso offre prestazioni superiori per i set di repliche e i cluster partizionati.

Elenco di controllo per lo sviluppo di MongoDB

Replica

Utilizza un numero dispari di persone votanti per garantire che le elezioni continuino in modo efficace. Avrai fino a 7 votanti. Nel caso in cui tu abbia un numero pari di persone votanti e vincoli, come il costo, impediscano di includere un altro secondario per essere un membro votante, sarai in grado di includere un arbitro per garantire un numero dispari di voti.

Garantisci che i tuoi secondari rimangano aggiornati utilizzando strumenti di monitoraggio e indicando un'adeguata preoccupazione di scrittura.

Non utilizzare letture ausiliarie per scalare il throughput di lettura complessivo.

Progettazione di schemi

I dati in MongoDB contengono un pattern dinamico. Le raccolte non mantengono la struttura del rapporto. Ciò incoraggia il miglioramento iterativo e il polimorfismo. In ogni caso, le raccolte spesso conservano archivi con strutture estremamente omogenee.

Decidi l'insieme di raccolte di cui avrai bisogno e gli indici necessari per supportare le tue query. Con il caso speciale dell'indice _id, devi creare tutti gli indici espressamente:MongoDB non crea naturalmente altri indici diversi da _id.

Garantire che il piano dello schema supporti l'ordinamento della distribuzione:nel caso in cui si intenda utilizzare cluster partizionati per il ridimensionamento orizzontale, pianificare lo schema in modo da incorporare una chiave shard avanzata. La chiave shard influenza l'esecuzione in lettura e scrittura decidendo in che modo MongoDB segmenta i dati. Non è possibile modificare la chiave shard una volta impostata.

Assicurati che il piano dello schema non dipenda da cluster indicizzati che crescono in lunghezza senza limiti. Normalmente, l'esecuzione ottimale può essere ottenuta quando tali cluster indicizzati hanno meno di 1000 componenti.

Considera i limiti di stima del documento durante la progettazione dello schema. Il limite della stima del documento BSON è di 16 MB per documento. Se hai bisogno di rapporti più grandi, usa GridFS.

Driver

Fai uso del pool di associazioni. La maggior parte dei driver MongoDB supporta il pool di associazioni. Modifica le dimensioni del pool di associazioni in base al tuo caso d'uso, a partire dal 110-115% del numero normale di richieste di database simultanee.

Assicurati che le tue applicazioni gestiscano gli errori di scrittura e lettura temporali durante le elezioni dei set di repliche.

Garantisci che le tue applicazioni gestiscano le richieste non riuscite e riprova se appropriato. I driver non

Riprova naturalmente le richieste non riuscite.

Utilizza la logica di backoff esponenziale per i tentativi di richiesta del database.

Utilizza cursor.maxTimeMS() per le letture e wtimeout per le scritture nel caso in cui desideri limitare il periodo di esecuzione per le operazioni del database.

Durata dei dati

Assicurati che il tuo set di repliche incorpori almeno tre hub contenenti dati con w:majority compose preoccupazione. Sono necessari tre hub di supporto dati per la solidità dei dati di un'ampia serie di repliche.

Garantire che tutte le istanze utilizzino il journaling.

Sharding

Garantisci che la tua chiave shard trasmetta il carico in modo uniforme sui tuoi shard.

Utilizza operazioni mirate per carichi di lavoro che sono stati ridimensionati con il numero di shard.

Per MongoDB 3.6 e versioni successive, i dati secondari non restituiscono più dati orfani a meno che non utilizzi il problema di lettura "disponibile" (che è il problema di lettura predefinito per le letture sui secondari quando non sono correlati a sessioni causalmente affidabili).

A partire da MongoDB 3.6, tutti i membri del set di repliche shard mantengono i metadati dei blocchi, consentendo loro di filtrare gli orfani quando non utilizzano "disponibile". Pertanto, le richieste non mirate o trasmesse che non utilizzano "disponibile" possono essere eseguite in modo sicuro su qualsiasi membro e non restituiranno informazioni orfane.

Il problema di lettura "accessibile" può restituire documenti orfani da membri ausiliari poiché non verifica la presenza di metadati del blocco revisionati. In ogni caso, nel caso in cui la restituzione di documenti orfani sia irrilevante per un'applicazione, il problema di lettura "disponibile" fornisce il minor numero di letture di inattività possibile tra i diversi problemi di lettura.

Pre-dividere e regolare manualmente i blocchi quando si incorporano set di dati espansivi in ​​una nuova raccolta partizionata senza hash. La pre-suddivisione e la regolazione fisica consentono allo stack di incorporamento di essere disperso tra i frammenti, espandendo l'esecuzione per il carico iniziale.

Conclusione 

La gestione dell'elenco di controllo delle operazioni e dello sviluppo è un passaggio cruciale che gli sviluppatori devono incorporare quando utilizzano MongoDB in produzione. Sono considerazioni chiave perché migliorano il flusso delle attività per un progetto in produzione. L'ambiente di produzione MongoDB richiede funzionalità di database stabili e affidabili perché il database in produzione memorizza i dati di lavoro nel mondo reale. L'integrità dei dati dipende dalla stabilità del database, che è abilitato garantendo che tutti gli elementi dell'elenco di controllo operativo e di sviluppo vengano elaborati prima della produzione.