Overvejelser for at administrere MongoDB

Nedenfor er et uddrag fra vores hvidbog "MongoDB Management and Automation with ClusterControl", som kan downloades gratis.

Overvejelser ved administration af MongoDB

Indbygget redundans

En nøglefunktion ved MongoDB er dens indbyggede redundans i form af replikering. Hvis du har to eller flere dataknudepunkter, kan de konfigureres som et replikasæt, hvor alle data, der er skrevet til den primære node, replikeres i næsten realtid til de sekundære noder,

sikre flere kopier af dataene. I tilfælde af Primary failover gennemfører de resterende noder i replikasættet et valg og opfordrer vinderen til at blive Primary, en proces, der typisk tager 2-3 sekunder, og skriver til replikasættet kan genoptages. MongoDB bruger også en journal til hurtigere og sikrere skrivninger til serveren eller replikasættet og anvender også en "write concern"-metode, hvorigennem niveauet af skriveredundans
konfigureres.

For manuelt at implementere et replikasæt er trinene på højt niveau som følger:

1. Tildel en enkelt fysisk eller virtuel vært for hver databasenode, og installer MongoDB-kommandolinjeklienten på dit skrivebord. For en redundant replikasætkonfiguration kræves der mindst tre noder, hvoraf mindst to vil være dataknudepunkter. Én node i replikasættet kan konfigureres som en arbiter:dette er en mongod-proces, der kun er konfigureret til at udgøre et beslutningsdygtigt ved at give en stemme ved valget af en Primary, når det kræves. Data replikeres ikke til dommerprocesser.
2. Installer MongoDB på hver node. Nogle Linux-distributioner inkluderer MongoDB Community Edition, men vær opmærksom på, at disse muligvis ikke inkluderer de nyeste versioner. MongoDB Enterprise er kun tilgængelig ved download fra MongoDBs hjemmeside. Lignende funktionalitet til MongoDB Enterprise er også tilgængelig via Percona Server til MongoDB, en drop-in-erstatning for MongoDB Enterprise eller Community Edition.
3. Konfigurer de individuelle mongod.conf-konfigurationsfiler til dit replikasæt ved hjælp af "replikeringsparameteren". Hvis du vil bruge en nøglefil til sikkerhed, skal du også konfigurere denne nu. Bemærk, at brug af nøglefilsikkerhed også muliggør rollebaseret godkendelse, så du skal også tilføje brugere og roller for at bruge serverne. Genstart mongod-processen på hver server.
4. Sørg for forbindelse mellem noder. Du skal sikre, at MongoDB replika sæt noder kan kommunikere med hinanden på port 27017, og også at din klient(er) kan oprette forbindelse til hver af replika sæt noder på den samme port.
5. Brug MongoDB-kommandolinjeklienten, opret forbindelse til en af ​​serverne, og kør rs.initiate() for at initialisere dit replikasæt, efterfulgt af rs.add() for hver ekstra node. rs.conf() kan bruges til at se konfigurationen.

Selvom disse trin ikke er så komplekse som at implementere og konfigurere en MongoDB sharded cluster eller sharding af en relationel database, kan de være besværlige og tilbøjelige til fejl, især i større miljøer.

Skalerbarhed

MongoDB omtales ofte som "webskala" databasesoftware på grund af dens kapacitet til at skalere horisontalt. Ligesom relationelle databaser er det muligt at skalere MongoDB lodret, blot ved at opgradere den fysiske vært, som den er på, med flere CPU-kerner, mere RAM, hurtigere diske eller endda øget bushastighed. Vertikal skalering har dog sine begrænsninger, både hvad angår cost-benefit-forhold og faldende afkast, og teknisk begrænsning. For at løse dette har MongoDB en "auto-sharding"-funktion, der tillader databaser at blive opdelt på tværs af mange værter (eller replikasæt, for redundans). Mens sharding også er muligt på relationelle platforme, med mindre det er designet til ved databasens start, kræver dette omfattende skema- og applikations-redesign, såvel som klientapplikations-redesign, hvilket gør dette til en kedelig, tidskrævende og fejltilbøjelig proces.

MongoDB sharding fungerer ved at introducere en routerproces, hvorigennem klienter opretter forbindelse til den shardede klynge, og konfigurationsservere, som gemmer klyngens metadata, placeringen i klyngen af ​​hvert dokument. Når en klient sender en forespørgsel til routerprocessen, refererer den først til konfigurationsserverne for at få dokumenternes placering, og indhenter derefter forespørgselsresultaterne direkte fra de enkelte servere eller
replikasæt (shards). Skæring udføres pr. indsamling.

En kritisk vigtig parameter her, af hensyn til ydeevnen, er "shard key", et indekseret felt eller sammensat felt, der findes i hvert dokument i en samling. Det er dette, der definerer skrivefordelingen på tværs af shards af en samling. Som sådan kan en dårligt valgt shard-nøgle have en meget skadelig effekt på ydeevnen. For eksempel kan en rent tidsseriebaseret shard-nøgle resultere i, at alle skrivninger går til en enkelt node i længere perioder. Dog kan en hashed shard-nøgle, mens den fordeler skrivninger jævnt på tværs af shards, påvirke læseydelsen, da et resultatsæt hentes fra mange noder.

Dommere

En MongoDB-arbiter er en mongod-proces, der er konfigureret til ikke at fungere som en dataknude, men kun at give funktionen til at stemme, når et replikasæt Primary skal vælges, for at bryde båndene og beskytte sig mod en delt afstemning. En dommer må ikke blive Primær, da den ikke har en kopi af dataene eller accepterer skrivninger. Selvom det er muligt at have mere end én dommer i et replikasæt, anbefales det generelt ikke.

Forsinkede replikasætmedlemmer

Medlemmer af forsinkede replikasæt tilføjer et ekstra niveau af redundans og opretholder en tilstand, der er et fast antal sekunder efter den primære. Da forsinkede medlemmer er en "rullende backup" eller et kørende "historisk" øjebliksbillede af datasættet, kan de hjælpe med at komme sig efter forskellige typer menneskelige fejl.

Forsinkede medlemmer er "skjulte" replikasætmedlemmer, usynlige for klientapplikationer og kan derfor ikke forespørges direkte. De bliver muligvis heller ikke Primære under normale operationer og skal omkonfigureres manuelt i tilfælde af, at de skal bruges til at genoprette efter fejl.

Sikkerhedskopier

Sikkerhedskopiering af et replikasæt eller sharded cluster udføres via kommandolinjeværktøjet "mongodump". Når det bruges med parameteren --oplog, opretter dette et dump af databasen, der inkluderer en oplog, for at skabe et øjebliksbillede af tilstanden af ​​en mongod-instans. Ved at bruge mongorestore med --replayOplog-parameteren kan du derefter fuldstændigt gendanne datatilstanden på det tidspunkt, hvor sikkerhedskopieringen blev fuldført, og undgå inkonsistens.

Til mere avancerede sikkerhedskopieringskrav er et tredjepartsværktøj kaldet "mongodbconsistent-backup" - også kommandolinjebaseret - tilgængeligt, som giver fuldt konsistente sikkerhedskopier af sharded clusters, en kompleks procedure, da sharded databaser er fordelt på tværs af flere værter.

Overvågning

Der er en række kommercielle værktøjer, både officielle og uofficielle, tilgængelige på markedet til overvågning af MongoDB. Disse værktøjer er generelt enkelte produktstyringsværktøjer, der udelukkende fokuserer på MongoDB. Mange fokuserer kun på visse specifikke aspekter, såsom samlingsstyring i en eksisterende MongoDB-arkitektur eller på sikkerhedskopier eller på implementering. Uden ordentlig planlægning kan dette føre til en situation, hvor en udbredelse af yderligere værktøjer skal implementeres og administreres i dit miljø.

Kommandolinjeværktøjerne leveret med MongoDB, "mongotop" og "mongostat" kan give en detaljeret visning af dit miljøs ydeevne og kan bruges til at diagnosticere problemer. Derudover kan MongoDBs "mongo"-kommandolinjeklient også køre "rs.status()" - eller i en sharded cluster "sh.status() - for at se status for replikasæt eller -klynger og deres medlemsværter. Kommandoen "db.stats()" returnerer et dokument, der adresserer lagringsbrug og datamængder, og deres er ækvivalenter til samlinger, såvel som andre kald for at få adgang til mange interne metrics.

Synopsis

Dette har været en kort synopsis af overvejelser om at administrere MongoDB. Selv på et så højt niveau skulle det dog umiddelbart være indlysende, at selvom det er muligt at administrere et replikasæt eller en sharded cluster fra kommandolinjen ved hjælp af tilgængelige værktøjer, skaleres dette ikke i et miljø med mange replikasæt eller med en stor produktion sønderdelt klynge. I mellemstore til store miljøer, der omfatter mange værter
og databaser, bliver det hurtigt umuligt at administrere alt med kommandolinjeværktøjer og scripts. Mens interne værktøjer og scripts kan udvikles til at implementere og vedligeholde miljøet, tilføjer dette byrden med at administrere ny udvikling, revisionskontrolsystemer og processer. En simpel opgradering af en databaseserver kan blive en kompleks proces, hvis værktøjsændringer er nødvendige for at understøtte nye database
serverversioner.

Men hvordan automatiserer og administrerer vi MongoDB-klynger uden interne værktøjer og scripts? Download hvidbogen for at lære hvordan!