Vores seneste udgivelse af ClusterControl forvandler nogle af de mest besværlige MongoDB-opgaver til kun 15 sekunders job. Nye funktioner er blevet tilføjet for at give dig mere kontrol over din klynge og udføre topologiændringer:
- Konverter et MongoDB-replikasæt til en shard MongoDB-klynge
- Tilføj og fjern shards
- Tilføj shard-routere til en shard MongoDB-klynge
- Træd ned eller frys en node
- Nye MongoDB-rådgivere
Vi vil beskrive disse tilføjede funktioner i dybden nedenfor.
Konverter et MongoDB ReplicaSet til en Sharded MongoDB Cluster
Da de fleste MongoDB-brugere starter med et replicaSet til at gemme deres database, er dette den mest brugte type klynge. Hvis du tilfældigvis løber ind i skaleringsproblemer, kan du skalere dette replikaSet ved enten at tilføje flere sekundære dele eller skalere ud ved sharding. Du kan konvertere et eksisterende replicaSet til en sharded cluster, men dette er en lang proces, hvor du nemt kan lave fejl. I ClusterControl har vi automatiseret denne proces, hvor vi automatisk tilføjer Configservers, shard-routere og aktiverer sharding.
For at konvertere et replikaSet til en splittet klynge kan du blot udløse det via rullemenuen med handlinger:
Dette åbner en to-trins dialog om, hvordan man konverterer dette til et skår. Det første trin er at definere, hvor Configserver og shard-routere skal installeres til:
Det andet trin er, hvor dataene skal gemmes, og hvilke konfigurationsfiler der skal bruges til Configserveren og shard-routeren.
Når shard-migreringsjobbet er afsluttet, viser klyngeoversigten nu shards i stedet for replicaSet-forekomster:
Efter konvertering til en shard klynge kan nye shards tilføjes.
Tilføj eller fjern Shards fra en Sharded MongoDB-klynge
Tilføjelse af Shards
Da et MongoDB-shard teknisk set er et replicaSet, involverer tilføjelse af et nyt shard også implementeringen af et nyt replicaSet. Inden for ClusterControl implementerer vi først et nyt replicaSet og føjer det derefter til den shardede klynge.
Fra ClusterControl-brugergrænsefladen kan du nemt tilføje nye shards med en to-trins guide, der åbnes fra handlingsrullemenuen:
Her kan du definere topologien for det nye shard.
Når det nye shard er blevet tilføjet til klyngen, begynder MongoDB shard-routeren at tildele nye bidder til det, og balanceren vil automatisk balancere alle shards over alle shards.
Fjernelse af Shards
Fjernelse af shards er lidt sværere end at tilføje et shard, da dette involverer at flytte dataene til de andre shards, før selve shard fjernes. For alle data, der er blevet sønderdelt over alle shards, vil dette være et job udført af MongoDB balanceren.
Imidlertid skal enhver ikke-shard database/samling, der blev tildelt dette shard som dets primære shard, flyttes til et andet shard og laves til dets nye primære shard. Til denne proces skal MongoDB vide, hvor disse ikke-shardede databaser/samlinger skal flyttes hen.
I ClusterControl kan du blot fjerne dem via rullemenuen handlinger:
Dette giver dig mulighed for at vælge det shard, du ønsker at fjerne, og det shard, du ønsker at migrere alle primære databaser til:
Jobbet, der fjerner shard, vil derefter udføre lignende handlinger som beskrevet tidligere:det vil flytte alle primære databaser til det udpegede shard, aktivere balanceren og derefter vente på, at det flytter alle data fra shard.
Når alle data er blevet fjernet, vil det fjerne shard fra brugergrænsefladen.
Tilføjelse af yderligere MongoDB Shard-routere
Når du begynder at skalere din applikation ved hjælp af en MongoDB sharded cluster, kan du finde ud af, at du har brug for yderligere shard-routere.
Tilføjelse af yderligere MongoDB shard routere er en meget enkel proces med ClusterControl, bare åbn Add Node dialogen fra handlings rullemenuen:
Dette vil tilføje en ny shard-router til klyngen. Glem ikke at indstille den korrekte standardport (27017) på routeren.
Afslut server
Hvis du ønsker at udføre vedligeholdelse på den primære node i et replikaSet, er det bedre at få det først til at "træde ned" på en yndefuld måde, før du tager den offline. At trappe ned en primær betyder dybest set, at værten stopper med at være en primær og bliver en sekundær og ikke er kvalificeret til at blive en primær i et bestemt antal sekunder. Noderne i MongoDB replicaSet med stemmestyrke vil vælge en ny primær med den nedtrappede primære ekskluderet i det indstillede antal sekunder.
I ClusterControl har vi tilføjet step down-funktionaliteten som en handling på siden Nodes. For at træde ned skal du blot vælge dette som en handling fra rullemenuen:
Efter at have indstillet antallet af sekunder for nedtrapning og bekræftelse, vil den primære træde ned, og en ny primær vil blive valgt.
Frys en node
Denne funktionalitet ligner step down-kommandoen:dette gør en bestemt node ude af stand til at blive primær i et bestemt antal sekunder. Det betyder, at du kan forhindre, at en eller flere sekundære noder bliver primære, når du trapper ned på den primære, og tvinge en bestemt node til at blive den nye primære på denne måde.
I ClusterControl har vi tilføjet fryseknudefunktionaliteten som en handling på siden Noder. For at fryse en node skal du blot vælge dette som en handling fra rullemenuen:
Efter at have indstillet antallet af sekunder og bekræftet, vil noden ikke være kvalificeret som primær i det indstillede antal sekunder.
Nye MongoDB-rådgivere
Rådgivere er miniprogrammer, der giver råd om specifikke databasespørgsmål. Vi har tilføjet tre nye rådgivere til MongoDB. Den første beregner replikeringsvinduet, den anden overvåger replikeringsvinduet, og den tredje kontrollerer for ikke-delte databaser/samlinger.
MongoDB Replication Lag Advisor
Replikationsforsinkelse er meget vigtig at holde øje med, hvis du skalerer ud læsninger ved at tilføje flere sekundære. MongoDB vil kun bruge disse sekundære, hvis de ikke halter for langt bagud. Hvis den sekundære har replikeringsforsinkelse, risikerer du at udlevere forældede data, der allerede er blevet overskrevet på den primære.
For at kontrollere replikeringsforsinkelsen er det tilstrækkeligt at oprette forbindelse til den primære og hente disse data ved hjælp af replSetGetStatus-kommandoen. I modsætning til MySQL holder den primære styr på replikeringsstatussen for dens sekundære.
Vi har implementeret denne kontrol i en rådgiver i ClusterControl for at sikre, at din replikeringsforsinkelse altid bliver overvåget.
MongoDB Replication Window Advisor
Ligesom replikeringsforsinkelsen er replikeringsvinduet en lige så vigtig metrik at se på. Lagrådgiveren informerer os allerede om antallet af sekunder en sekundær node er bag den primære/master. Da oploggen er begrænset i størrelse, medfører det følgende risici at have slavelag:
- Hvis en node halter for langt bagud, er den muligvis ikke i stand til at indhente det, da de transaktioner, der er nødvendige for at indhente det, ikke længere er i den primære oplog.
- En haltende sekundær node er mindre begunstiget i et MongoDB-valg til et nyt primærvalg. Hvis alle sekundære halter bagud i replikering, vil du have et problem, og en med mindst forsinkelse vil blive gjort til primær.
- Sekundærer, der halter bagud, er mindre begunstiget af MongoDB-driveren, når læsninger skaleres ud med MongoDB, det tilføjer også en højere arbejdsbyrde på de resterende sekundære.
Hvis vi ville have en sekundær node bagud med et par minutter (eller timer), ville det være nyttigt at have en rådgiver, der informerer os, hvor meget tid vi har tilbage, før vores næste transaktion vil blive droppet fra oploggen. Tidsforskellen mellem første og sidste post i oploggen kaldes replikeringsvinduet. Denne metrik kan oprettes ved at hente de første og sidste elementer fra oploggen og beregne forskellen mellem deres tidsstempler.
I MongoDB-skallen er der allerede en funktion tilgængelig, der beregner replikeringsvinduet for dig. Denne funktion er imidlertid indbygget i kommandolinjeskallen, så enhver ekstern forbindelse, der ikke bruger kommandolinjeskallen, vil ikke have denne indbyggede funktion. Derfor har vi lavet en rådgiver, der holder øje med replikeringsvinduet og advarer dig, hvis du overskrider en forudindstillet tærskel.
MongoDB un-sharded Databaser and Collections Advisor
Ikke-shardede databaser og samlinger vil blive tildelt til en standard primær shard af MongoDB shard-routeren. Dette betyder, at databasen eller samlingen er begrænset til størrelsen af denne primære shard, og hvis den skrives til i store mængder, kan den opbruge al resterende diskplads på et shard. Når dette sker, vil shard åbenbart ikke længere fungere. Derfor er det vigtigt at holde øje med alle eksisterende databaser og samlinger og scanne konfigurationsdatabasen for at validere, at de er blevet aktiveret til sharding.
For at forhindre dette i at ske, har vi oprettet en u-delt database og indsamlingsrådgiver. Denne rådgiver scanner hver database og samling og advarer dig, hvis den ikke er blevet sønderdelt.
ClusterControl forbedrede MongoDB-vedligeholdelsen
Vi har taget et stort skridt ved at tilføje alle forbedringerne til ClusterControl til MongoDB replicaSets og sharded clusters. Dette forbedrer brugervenligheden for MongoDB betydeligt og gør det muligt for DBA'er, sysops og devops at vedligeholde deres klynger endnu bedre!