Overwegingen bij het beheren van MongoDB

Hieronder vindt u een fragment uit onze whitepaper "MongoDB Beheer en Automatisering met ClusterControl", dat gratis kan worden gedownload.

Overwegingen voor het beheren van MongoDB

Ingebouwde redundantie

Een belangrijk kenmerk van MongoDB is de ingebouwde redundantie, in de vorm van replicatie. Als u twee of meer gegevensknooppunten hebt, kunnen deze worden geconfigureerd als een replicaset, waarin alle gegevens die naar het primaire knooppunt worden geschreven, in bijna realtime worden gerepliceerd naar de secundaire knooppunten,

zorgen voor meerdere kopieën van de gegevens. In het geval van primaire failover voeren de resterende knoop punten in de replicaset een verkiezing uit en promoveren de winnaar tot primair, een proces dat doorgaans 2-3 seconden duurt, en het schrijven naar de replicaset kan worden hervat. MongoDB gebruikt ook een journaal voor snellere, veiligere schrijfacties naar de server of replicaset, en maakt ook gebruik van een 'write concern'-methode waarmee het niveau van schrijfredundantie wordt
geconfigureerd.

Om een ​​replicaset handmatig te implementeren, zijn de stappen op hoog niveau als volgt:

1. Wijs een enkele fysieke of virtuele host toe aan elk databaseknooppunt en installeer de MongoDB-opdrachtregelclient op uw bureaublad. Voor een redundante replicasetconfiguratie zijn minimaal drie knooppunten vereist, waarvan ten minste twee gegevensknooppunten. Eén node in de replicaset kan worden geconfigureerd als arbiter:dit is een mongod-proces dat alleen is geconfigureerd om een ​​quorum te vormen door indien nodig een stem uit te brengen bij de verkiezing van een Primary. Gegevens worden niet gerepliceerd naar arbiterprocessen.
2. Installeer MongoDB op elk knooppunt. Sommige Linux-distributies bevatten MongoDB Community Edition, maar houd er rekening mee dat deze mogelijk niet de nieuwste versies bevatten. MongoDB Enterprise is alleen beschikbaar door te downloaden van de MongoDB-website. Gelijkaardige functionaliteit als MongoDB Enterprise is ook beschikbaar via Percona Server voor MongoDB, een drop-in vervanging voor MongoDB Enterprise of Community Edition.
3. Configureer de individuele mongod.conf-configuratiebestanden voor uw replicaset met behulp van de "replicatieparameter". Als u een sleutelbestand voor beveiliging wilt gebruiken, configureert u dit nu ook. Merk op dat het gebruik van sleutelbestandsbeveiliging ook op rollen gebaseerde authenticatie mogelijk maakt, dus u zult ook gebruikers en rollen moeten toevoegen om de servers te gebruiken. Herstart het mongod-proces op elke server.
4. Zorg voor connectiviteit tussen knooppunten. U moet ervoor zorgen dat MongoDB-replicasetknooppunten met elkaar kunnen communiceren op poort 27017, en ook dat uw client(s) verbinding kunnen maken met elk van de replicasetknooppunten op dezelfde poort.
5. Gebruik de MongoDB-opdrachtregelclient, maak verbinding met een van de servers en voer rs.initiate() uit om uw replicaset te initialiseren, gevolgd door rs.add() voor elk extra knooppunt. rs.conf() kan worden gebruikt om de configuratie te bekijken.

Hoewel deze stappen niet zo complex zijn als het implementeren en configureren van een MongoDB-shardcluster of het sharden van een relationele database, kunnen ze lastig en foutgevoelig zijn, vooral in grotere omgevingen.

Schaalbaarheid

MongoDB wordt vaak aangeduid als "webscale" databasesoftware, vanwege de mogelijkheid om horizontaal te schalen. Net als relationele databases is het mogelijk om MongoDB verticaal te schalen, simpelweg door de fysieke host waarop het zich bevindt te upgraden met meer CPU-kernen, meer RAM, snellere schijven of zelfs hogere bussnelheid. Verticale schaalvergroting kent echter zijn grenzen, zowel in termen van kosten-batenverhouding en afnemende meeropbrengsten, als in termen van technische beperking. Om dit aan te pakken, heeft MongoDB een "auto-sharding" -functie, waarmee databases kunnen worden opgesplitst over meerdere hosts (of replicasets, voor redundantie). Hoewel sharding ook mogelijk is op relationele platforms, tenzij ontworpen voor bij aanvang van de database, vereist dit een groot herontwerp van schema's en toepassingen, evenals herontwerp van clienttoepassingen, waardoor dit een vervelend, tijdrovend en foutgevoelig proces is.

MongoDB-sharding werkt door een routerproces te introduceren, waardoor clients verbinding maken met het shard-cluster, en configuratieservers, die de clustermetadata opslaan, de locatie in het cluster van elk document. Wanneer een client een query indient bij het routerproces, verwijst deze eerst naar de configuratieservers om de locaties van de documenten te verkrijgen en verkrijgt vervolgens de queryresultaten rechtstreeks van de individuele servers of replicasets (shards). Sharding wordt per collectie uitgevoerd.

Een uiterst belangrijke parameter hier, voor prestatiedoeleinden, is de "shard-sleutel", een geïndexeerd veld of samengesteld veld dat in elk document in een verzameling voorkomt. Het is dit dat de schrijfdistributie over shards van een verzameling definieert. Als zodanig kan een slecht gekozen Shard-sleutel een zeer nadelig effect hebben op de prestaties. Een puur op tijdreeks gebaseerde shardsleutel kan er bijvoorbeeld toe leiden dat alle schrijfbewerkingen voor langere tijd naar één enkel knooppunt gaan. Een gehashte shard-sleutel, die schrijfbewerkingen gelijkmatig over shards verdeelt, kan echter van invloed zijn op de leesprestaties, aangezien een resultaatset van veel knooppunten wordt opgehaald.

Arbiters

Een MongoDB-arbiter is een mongod-proces dat is geconfigureerd om niet te fungeren als een gegevensknooppunt, maar om alleen de functie van stemmen te bieden wanneer een primaire replicaset moet worden gekozen, om banden te verbreken en te waken tegen een gesplitste stemming. Een arbiter mag niet primair worden, omdat hij geen kopie van de gegevens heeft of schrijfbewerkingen accepteert. Hoewel het mogelijk is om meer dan één arbiter in een replicaset te hebben, wordt dit over het algemeen niet aanbevolen.

Vertraagde Replica Set-leden

Leden van vertraagde replicasets voegen een extra niveau van redundantie toe, waardoor een status behouden blijft die een vast aantal seconden achter de Primary ligt. Omdat vertraagde leden een "rollende back-up" of een lopende "historische" momentopname van de dataset zijn, kunnen ze helpen bij het herstellen van verschillende soorten menselijke fouten.

Vertraagde leden zijn "verborgen" replicasetleden, onzichtbaar voor clienttoepassingen en kunnen dus niet rechtstreeks worden opgevraagd. Ze mogen ook niet primair worden tijdens normale bewerkingen en moeten handmatig opnieuw worden geconfigureerd in het geval dat ze moeten worden gebruikt om te herstellen van een fout.

Back-ups

Het maken van een back-up van een replicaset of shard-cluster wordt uitgevoerd via het opdrachtregelhulpprogramma 'mongodump'. Wanneer gebruikt met de --oplog parameter, creëert dit een dump van de database die een oplog bevat, om een ​​momentopname te maken van de status van een mongod-instantie. Door mongorestore te gebruiken met de parameter --replayOplog, kunt u de gegevensstatus volledig herstellen op het moment dat de back-up voltooid was, om inconsistentie te voorkomen.

Voor meer geavanceerde back-upvereisten is er een tool van een derde partij genaamd "mongodbconsistent-backup" - ook gebaseerd op de opdrachtregel - beschikbaar die volledig consistente back-ups van sharded clusters biedt, een complexe procedure, aangezien sharded-databases over meerdere hosts worden gedistribueerd.

Bewaking

Er zijn een aantal commerciële tools, zowel officiële als niet-officiële, op de markt beschikbaar voor het monitoren van MongoDB. Deze tools zijn over het algemeen hulpprogramma's voor het beheer van één product en zijn uitsluitend gericht op MongoDB. Veel richten zich alleen op bepaalde specifieke aspecten, zoals collectiebeheer in een bestaande MongoDB-architectuur, of op back-ups, of op deployment. Zonder een goede planning kan dit leiden tot een situatie waarin een wildgroei aan aanvullende tools in uw omgeving moet worden ingezet en beheerd.

De opdrachtregelprogramma's die bij MongoDB, "mongotop" en "mongostat" worden geleverd, kunnen een gedetailleerd beeld geven van de prestaties van uw omgeving en kunnen worden gebruikt om problemen te diagnosticeren. Bovendien kan MongoDB's "mongo"-opdrachtregelclient ook "rs.status()" uitvoeren - of in een shard-cluster "sh.status() - om de status van replicasets of clusters en hun aangesloten hosts te bekijken. De opdracht "db.stats()" retourneert een document dat betrekking heeft op opslaggebruik en gegevensvolumes, en hun equivalenten zijn voor verzamelingen, evenals andere aanroepen om toegang te krijgen tot veel interne statistieken.

Synopsis

Dit is een korte samenvatting van overwegingen voor het beheer van MongoDB. Zelfs op zo'n hoog niveau moet het echter meteen duidelijk zijn dat hoewel het mogelijk is om een ​​replicaset of sharded cluster vanaf de opdrachtregel te beheren met behulp van beschikbare tools, dit niet schaalt in een omgeving met veel replicasets of met een grote productie gespleten cluster. In middelgrote tot grote omgevingen met veel hosts
en databases, wordt het al snel onhaalbaar om alles te beheren met opdrachtregelprogramma's en scripts. Hoewel interne tools en scripts kunnen worden ontwikkeld om de omgeving te implementeren en te onderhouden, voegt dit de last toe van het beheer van nieuwe ontwikkelingen, revisiecontrolesystemen en processen. Een eenvoudige upgrade van een databaseserver kan een complex proces worden als er wijzigingen in de tooling nodig zijn om nieuwe database
serverversies te ondersteunen.

Maar hoe automatiseren en beheren we MongoDB-clusters zonder interne tools en scripts? Download de whitepaper om te leren hoe!