MongoDB-implementatie in productie kan alleen echt werken als het juiste implementatiepatroon wordt gevolgd. Het implementeren van een replicaset op één host is geen garantie voor de hoge beschikbaarheid van gegevens. Omgaan met big data vereist uitgebreid onderzoek en optimale implementaties, ofwel door de beschikbare opties te combineren of door degene te kiezen met de meest veelbelovende voordelen.
Deployment patronen voor MongoDB omvatten:
- Replicasets met drie leden
- Replica sets verdeeld over twee of meer datacenters.
Replicasets met drie leden
Replicatie is een schaalstrategie voor MongoDB die de hoge beschikbaarheid van gegevens verbetert. Een replicaset omvat:
- Een primair knooppunt:verantwoordelijk voor alle schrijfbewerkingen en kan ook worden gelezen.
- Secundaire knooppunten:kunnen alleen worden gebruikt voor leesbewerkingen, maar kunnen als primair worden gekozen voor het geval de bestaande faalt. Ze verkrijgen hun gegevensupdates van een oplog die is gegenereerd door het primaire lid van de set.
- Arbiter. Gebruikt om de verkiezing van een primaire te vergemakkelijken in het geval er een even aantal replicasetleden is. Het host geen enkele kopie van de gegevens.
Voordelen van een replicaset kunnen alleen worden behaald met een minimum aantal van drie leden met de volgende architectuur:
Primair-Secundair-Secundair
Dit wordt het meest aanbevolen omdat het een grotere fouttolerantie heeft en de beperkingen van het toevoegen van een derde gegevensdragend lid, zoals kosten, aanpakt.
Deze implementatie levert altijd twee volledige kopieën op naast de primaire gegevens, waardoor een hoge beschikbaarheid wordt gegarandeerd. Als de primaire mislukt, wordt de replicaset geactiveerd om een nieuwe primaire te kiezen en wordt de weergave normaal hervat. Als de oude primaire levend wordt, wordt deze gecategoriseerd als een secundair lid.
Tijdens het verkiezingsproces signaleren de leden elkaar door middel van een hartslag en er vinden geen schrijfbewerkingen plaats gedurende deze tijd
Na het verkiezingsproces gaan we ervan uit dat de architectuur wordt hervormd als:
Primaire-Secundaire-Arbiter
Dit zorgt ervoor dat de replicaset beschikbaar blijft, zelfs als de primaire of secundaire niet beschikbaar is, door het verkiezingsproces van een secundaire naar een primaire te vergemakkelijken. Arbiters hebben geen enkele kopie van de gegevens bij zich en hebben daarom minder middelen nodig om te beheren.
Een beperking bij deze implementatie is; geen redundantie omdat er slechts twee gegevensdragende leden zijn:primair en secundair. Dit resulteert in een lagere fouttolerantie.
Fouttolerantie zou moeten kunnen zorgen voor:
- Beschikbaarheid van schrijven: de meerderheid van de leden van de replicaset met stemmen is nodig om de primaire persoon te behouden of te kiezen die verantwoordelijk is voor de schrijfbewerkingen.
- Gegevensredundantie:schrijven kan door meerdere leden worden bevestigd om terugdraaien te voorkomen
De Primary-Secondary-Arbiter-configuratie ondersteunt alleen het schrijfbeschikbaarheidsaspect, zodat als een enkel lid van de set niet beschikbaar is, een primary nog steeds kan worden onderhouden.
Het niet ondersteunen van het tweede aspect heeft echter enkele operationele gevolgen als het secundaire lid niet meer beschikbaar is:
- Er zal geen actieve replicatie zijn, vooral niet als de secundaire lange tijd offline is. Als de secundaire te lang offline is, kan deze van de oplog vallen, waardoor deze tijdens het opnieuw opstarten opnieuw moet worden gesynchroniseerd.
- Dataredundantie wordt gesaboteerd, waardoor de schrijfbewerking alleen door de huidige primaire wordt bevestigd.
- De meest bezorgde optie levert niet de nieuwste gegevens aan de verbonden applicaties en interne processen. Dit is het geval wanneer uw configuratie verwacht dat schrijven om meerderheidsbevestiging vraagt en daarom wordt geblokkeerd totdat de meerderheid van de gegevensdragende leden beschikbaar is.
- Chunkmigratie tussen shards wordt ook aangetast als de replicaset deel uitmaakt van een shardcluster.
- Druk op de cache van de WiredTiger-opslagengine als er een rollback plaatsvindt en het meeste commit-punt niet kan worden vervroegd.
Om deze gevolgen te voorkomen, kan men kiezen voor een Primair-Secundair-Secundair configuratie, omdat dit de fouttolerantie verhoogt.
Opmerking:Fouttolerantie treedt niet alleen op bij een storing, maar ook bij sommige systeembewerkingen, zoals software-upgrades en normaal onderhoud, kan een lid tijdelijk niet beschikbaar zijn.
Replicasets verdeeld over twee of meer datacenters
Hoge beschikbaarheid kan naar een ander niveau worden getild door replicasetleden te verdelen over geografisch verschillende datacenters. Deze aanpak verhoogt de redundantie en zorgt voor een hoge fouttolerantie voor het geval een datacenter niet meer beschikbaar is.
Als alle leden zich in één datacenter bevinden, is de replicaset vatbaar voor datacenterstoringen zoals netwerkstoringen en stroomuitval.
Het is raadzaam om ten minste één lid in een alternatief datacenter te houden, gebruik een oneven aantal datacenters en selecteer een ledenverdeling die een meerderheid biedt voor verkiezing of op zijn minst een kopie van de gegevens verstrekt in geval van mislukking.
De configuratie moet ervoor zorgen dat als een datacenter uitvalt, de replicaset beschrijfbaar blijft, aangezien de overige leden een verkiezing kunnen houden.
Verdeel uw gegevens in ten minste drie datacenters.
Leden kunnen beperkt zijn tot bronnen of netwerkbeperkingen hebben, waardoor ze ongeschikt zijn om primair te worden in geval van failover. Je kunt deze leden configureren om niet primair te worden door ze prioriteit 0 te geven.
Leden in een datacenter kunnen een hogere prioriteit hebben dan andere datacenters om hen een stemprioriteit te geven zodat ze voorrang kunnen kiezen voor leden in andere datacenters.
Alle leden in de replicaset moeten met elkaar kunnen communiceren.
Conclusie
Replicatievoordelen kunnen worden verhoogd tot een meer veelbelovende status door de leden over een aantal datacenters te verdelen. Dit verhoogt in wezen de fouttolerantie en zorgt niet alleen voor gegevensredundantie. Replica Set-leden bieden bij distributie over twee of meer datacenters voordelen ten opzichte van een enkel datacenter, zoals:
Als een van de datacenters uitvalt, zijn de gegevens nog steeds beschikbaar voor uitlezingen, in tegenstelling tot een enkele datacenterdistributie.
Schrijfbewerkingen kunnen nog steeds worden bevestigd wanneer een datacenter met minderheidsleden uitvalt.
Leesbewerkingen kunnen nog steeds mogelijk zijn als het datacenter met meerderheidsstemmers uitvalt, in tegenstelling tot het geval voor een enkel datacenter.