MongoDB-implementering i produktionen kan kun virkelig fungere, hvis det rigtige implementeringsmønster overholdes. Implementering af et replikasæt i en enkelt vært garanterer ikke den høje tilgængelighed af data. Håndtering af big data kræver omfattende research og optimale implementeringer, enten ved at kombinere de tilgængelige muligheder eller vælge den med de højest lovende fordele.
Implementeringsmønstre for MongoDB inkluderer:
- Replikasæt med tre medlemmer
- Replikasæt fordelt på to eller flere datacentre.
Replikasæt med tre medlemmer
replikering er en skaleringsstrategi for MongoDB, der forbedrer høj tilgængelighed af data. Et replikasæt involverer:
- En primær node:ansvarlig for alle skrivegennemløbsoperationer og kan også læses fra.
- Sekundære noder:Kan kun bruges til læseoperationer, men kan vælges til primær, hvis den eksisterende fejler. De henter deres dataopdateringer fra en oplog genereret af det primære medlem af sættet.
- Arbiter. Bruges til at lette valget af et primærvalg, hvis der er et lige antal replika-sætmedlemmer. Det er ikke vært for nogen kopi af dataene.
Fordelene ved et replikasæt kan kun opnås med et minimumsantal på tre medlemmer med følgende arkitektur:
Primær-sekundær-sekundær
Dette er det mest anbefalede, da det har en større fejltolerance og adresserer begrænsningerne ved at tilføje et tredje databærende medlem, såsom omkostninger.
Denne implementering vil altid give to komplette kopier udover de primære data, hvilket sikrer høj tilgængelighed. Fejl i den primære vil udløse replikasættet til at vælge en ny primær, og betjeningen genoptages som normalt. Hvis den gamle primære bliver levende vil den blive kategoriseret som et sekundært medlem.
Under valgprocessen signalerer medlemmerne til hinanden gennem et hjerteslag og der er ingen skrivehandlinger, der finder sted i dette tidsrum
Efter valgprocessen antager vi, at arkitekturen skal reformeres som:
Primær-sekundær-arbiter
Dette sikrer, at replikasættet forbliver tilgængeligt, selvom det primære eller sekundære er utilgængeligt ved at lette valgprocessen for en sekundær til en primær. Voldgiftsdommere har ingen kopi af dataene og kræver derfor færre ressourcer at administrere.
En begrænsning med denne implementering er; ingen redundans, da der kun er to databærende medlemmer:primære og sekundære. Dette resulterer i en lavere fejltolerance.
Fejltolerance bør kunne sikre:
- Skrivetilgængelighed: flertallet af stemmeberettigede replikasæt-medlemmer er nødvendige for at opretholde eller vælge den primære, der er ansvarlig for skriveoperationerne.
- Data redundans:skrivning kan anerkendes af flere medlemmer for at undgå rollbacks
Primær-sekundær-arbiter-konfigurationen understøtter kun skrivetilgængelighedsaspektet, således at hvis et enkelt medlem af sættet ikke er tilgængeligt, kan en primær stadig opretholdes.
Men manglende understøttelse af det andet aspekt resulterer i nogle operationelle konsekvenser, hvis det sekundære medlem bliver utilgængeligt:
- Der vil ikke være nogen aktiv replikering, især hvis den sekundære er offline i længere tid. Når den sekundære er offline for længe, kan den falde af oploggen og tvinge en til at synkronisere den igen under genstart.
- Datareundans vil blive saboteret og tvinger skriveoperation til kun at blive anerkendt af den nuværende primære.
- Majority with concern-mulighed vil ikke levere de nyeste data til de tilsluttede applikationer og interne processer. Dette er tilfældet, når din konfiguration forventer, at skrivning anmoder om flertalsbekræftelse og derfor bliver blokeret, indtil de fleste databærende medlemmer er tilgængelige.
- Chunk-migrering mellem shards vil også blive kompromitteret, hvis replikasættet er en del af en sharded klynge.
- Pres på WiredTiger-lagringsmotorens cache, hvis der sker tilbagerulninger, og flertallets forpligtelsespunkt ikke kan rykkes frem.
For at undgå disse konsekvenser kan man vælge en primær-sekundær-sekundær -konfiguration, da den øger fejltolerancen.
Bemærk:Fejltolerance opstår ikke kun i tilfælde af fejl, men også nogle systemoperationer såsom softwareopgradering og normal vedligeholdelse kan tvinge et medlem til at være utilgængelig kortvarigt.
Replikasæt fordelt på to eller flere datacentre
Høj tilgængelighed kan hæves til et andet niveau ved at fordele replikasætmedlemmer på tværs af geografisk adskilte datacentre. Denne tilgang vil øge redundansen udover at sikre høj fejltolerance i tilfælde af, at et datacenter bliver utilgængeligt.
Hvis alle medlemmerne er placeret i et enkelt datacenter, er replikasættet modtageligt for datacenterfejl såsom netværkstransienter og strømafbrydelser.
Det er tilrådeligt at beholde mindst ét medlem i et alternativt datacenter, brug et ulige antal datacentre og vælg en fordeling af medlemmer, der vil tilbyde et flertal til valg eller som minimum give en kopi af dataene i tilfælde af fejl.
Konfigurationen skal sikre, at hvis et datacenter går ned, forbliver replikasættet skrivbart, da de resterende medlemmer kan holde et valg.
Distribuer dine data på mindst tre datacentre.
Medlemmer kan være begrænset til ressourcer eller have netværksbegrænsninger, hvilket gør dem uegnede til at blive primære i tilfælde af failover. Du kan konfigurere disse medlemmer til ikke at blive primære ved at give dem prioritet 0.
Medlemmer i et datacenter kan have en højere prioritet end andre datacentre for at give dem en stemmeprioritet, så de kan vælge primære før medlemmer i andre datacentre.
Alle medlemmer i replikasættet bør kunne kommunikere med hinanden.
Konklusion
Replikeringsfordele kan hæves til en mere lovende status ved at fordele medlemmerne på tværs af en række datacentre. Dette øger væsentligt fejltolerancen udover at sikre dataredundans. Medlemmer af replikasæt, når de er fordelt på to eller flere datacentre, giver fordele i forhold til et enkelt datacenter, såsom:
Hvis et af datacentrene går ned, er data stadig tilgængelige for læsning i modsætning til en enkelt datacenterdistribution.
Skrivehandlinger kan stadig bekræftes, når et datacenter med minoritetsmedlemmer går ned.
Læseoperationer kan stadig være mulige, hvis datacentret med flertalsbestemte medlemmer går ned i modsætning til tilfældet for enkelt datacenter.