Fejlfinding af en MongoDB Sharded Cluster

I MongoDB involverer store datasæt operationer med høj kapacitet, og dette kan overvælde kapaciteten på en enkelt server . Store arbejdsdatasæt implicerer mere stress på I/O-kapaciteten af ​​diskenheder og kan føre til et problem som f.eks. sidefejl.

Der er hovedsageligt to måder at løse dette på...

1. Lodret skalering stærk> :øget enkelt serverkapacitet. Opnås ved at tilføje mere CPU, RAM og lagerplads, men med en begrænsning, at:tilgængelig teknologi kan begrænse en enkelt maskine fra at være tilstrækkelig kraftfuld til en vis arbejdsbyrde. I praksis er der et maksimum for lodret skalering.
2. Horisontal skalering gennem shading :Dette involverer opdeling af systemdatasæt over flere servere, hvilket reducerer den samlede arbejdsbyrde for en enkelt server. Udvidelse af kapaciteten af ​​implementeringen kræver kun tilføjelse af flere servere til lavere samlede omkostninger end avanceret hardware til en enkelt maskine. Dette kommer dog med en afvejning af, at der vil være en masse kompleksitet i infrastruktur og vedligeholdelse til udrulningen. Kompleksiteten bliver mere sofistikeret ved fejlfinding af den sønderdelte klynge i tilfælde af katastrofe. I denne blog giver vi nogle af de fejlfindingsmuligheder, der kan hjælpe:
3. Valg af Shard Keys og klyngetilgængelighed 
4. Mongos-forekomst bliver utilgængelig
5. Et medlem bliver fraværende fra shard replikasættet
6. Alle medlemmer af et replikasæt er fraværende
7. Gamle konfigurationsdata fører til markørfejl
8. Konfigurationsserveren bliver utilgængelig
9. Lettelse af databasestrengfejl
10. Undgå nedetid ved flytning af konfigurationsservere

Valg af Shard Keys og Cluster Tilgængelighed

Sharding involverer opdeling af data i små grupper kaldet shards for at reducere den samlede arbejdsbyrde for en given gennemstrømning operation. Denne gruppering opnås ved at vælge en optimal nøgle, som hovedsageligt er den vigtigste del før skæring. En optimal nøgle bør sikre:

1. Mongoer kan isolere de fleste forespørgsler til en specifik mongod. Hvis f.eks. flere operationer udsættes for et enkelt shard, vil svigt af det shard kun gøre data forbundet med det fraværende på det tidspunkt. Det er tilrådeligt at vælge en shard-nøgle, der giver flere shards for at reducere mængden af ​​utilgængelige data, hvis shard'en går ned.
2. MongoDB vil være i stand til at dele dataene jævnt mellem bidderne. Dette sikrer, at gennemstrømningsoperationer også vil blive fordelt jævnt, hvilket reducerer chancerne for fejl på grund af mere arbejdsbelastning.
3. Skriv skalerbarhed på tværs af klyngen for at sikre høj tilgængelighed. Hvert skår skal være et replikasæt, idet hvis en bestemt mongod-instans mislykkes, er de resterende replikasætmedlemmer i stand til at vælge et andet medlem til at være det primære og dermed sikre operationel kontinuitet.

Hvis en given shard under alle omstændigheder har en tendens til at fejle, start med at kontrollere, hvor mange gennemløbsoperationer er det udsat for og overvej at vælge en bedre skæringsnøgle for at få flere skærver.

Hvad nu hvis? Mongos-instans bliver fraværende

Tjek først, om du opretter forbindelse til den rigtige port, da du måske har ændret dig ubevidst. For eksempel, implementering med AWS-platformen, er der en sandsynlighed for dette problem på grund af sikkerhedsgrupperne, der muligvis ikke tillader forbindelser på den port. For en øjeblikkelig test, prøv at angive den fulde host:port for at sikre, at du bruger en loopback-grænseflade. Det gode er, at hvis hver applikationsserver har sin egen mongos-instans, kan applikationsserverne fortsætte med at få adgang til databasen. Desuden har mongo-forekomster deres tilstande ændret med tiden og kan genstarte uden nødvendigvis at miste data. Når forekomsten genoprettes, vil den hente en kopi af konfigurationsdatabasen og begynde at dirigere forespørgsler.

Sørg for, at den port, du forsøger at oprette forbindelse til igen, ikke er optaget af en anden proces.

Hvad nu hvis? Et medlem bliver fraværende fra Shard Replica Set

Start med at kontrollere status for shard ved at køre kommandoen sh.status(). Hvis det returnerede resultat ikke har clusterId, er shard'en faktisk ikke tilgængelig. Undersøg altid tilgængelighedsafbrydelser og fejl, og hvis du ikke er i stand til at gendanne det på kortest mulig tid, skal du oprette et nyt medlem for at erstatte det så hurtigt som muligt for at undgå mere datatab.

Hvis et sekundært medlem bliver utilgængeligt, men med aktuelle oplog-indgange, kan det, når det tilsluttes igen, hamle op til seneste indstillede tilstand ved at læse aktuelle data fra oploggen som normal replikeringsproces. Hvis det ikke lykkes at replikere dataene, skal du foretage en indledende synkronisering ved at bruge en af ​​disse to muligheder...

1. Genstart mongod med en tom datamappe og lad MongoDBs normale indledende synkroniseringsfunktion gendanne dataene. Denne tilgang tager dog lang tid at kopiere dataene, men ret ligetil.
2. Genstart værtsmaskinen med en kopi af en nylig datamappe fra et andet medlem i replikasættet. Hurtig proces, men med komplicerede trin

Den indledende synkronisering vil gøre det muligt for MongoDB at...

1. Klon alle tilgængelige databaser undtagen lokal database. Sørg for, at målmedlemmet har nok diskplads i den lokale database til midlertidigt at gemme oplog-posterne i en periode, hvor dataene kopieres.
2. Anvend  alle ændringer på datasættet ved at bruge oploggen fra kilden. Processen vil kun være fuldført, hvis status for replikaen skifter fra STARTUP2 til SEKUNDÆR.

Hvad nu hvis? Alle medlemmer af et replikasæt er fraværende

Data, der opbevares i et shard vil være utilgængelig, hvis alle medlemmer af et replikasæt-shard bliver fraværende. Da de andre shards forbliver tilgængelige, er læse- og skriveoperationer stadig mulige, bortset fra at applikationen vil blive serveret med delvise data. Du bliver nødt til at undersøge årsagen til afbrydelserne og forsøge at genaktivere shard så hurtigt som muligt. Tjek hvilken forespørgselsprofiler eller forklaringsmetode, hvad der kunne have ført til det problem.

Hvad nu hvis? Forældede konfigurationsdata fører til markørfejl

Nogle gange kan en mongos-instans tage lang tid at opdatere metadatacachen fra konfigurationsdatabasen, hvilket fører til en forespørgsel, der returnerer advarslen: 

could not initialize cursor across all shards because : stale config detected

Denne fejl vil altid blive præsenteret, indtil mongo-forekomsterne opdaterer deres cache. Dette bør ikke forplante sig tilbage til applikationen. For at rette dette skal du tvinge instansen til at opdatere ved at køre fluRouterConfig.

For at tømme cachen for en specifik indsamlingskørsel

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

For at tømme cache for en specifik databasekørsel 

db.adminCommand({ flushRouterConfig: "<db>" } )

Kør for at tømme cache for alle databaser og deres samlinger:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Hvad nu hvis? Konfigurationsserver bliver utilgængelig

Konfigurationsserver kan i dette tilfælde betragtes som det primære medlem, hvorfra sekundære noder replikerer deres data. Hvis det bliver fraværende, skal de tilgængelige sekundære noder vælge en blandt deres medlemmer for at blive den primære. For at undgå at komme i en situation, hvor du måske ikke har en konfigurationsserver, kan du overveje at distribuere replikasættets medlemmer på tværs af to datacentre siden...

• Hvis et datacenter går ned, vil data stadig være tilgængelige for læsning i stedet for ingen operationer, hvis du brugte et enkelt datacenter .
• Hvis datacenteret, der involverer minoritetsmedlemmer, går ned, kan replikasættet stadig betjene både skrive- og læseoperationer.

Det er tilrådeligt at fordele medlemmer på mindst tre datacentre.

En anden distributionsmulighed er at fordele de databærende medlemmer jævnt på tværs af de to datacentre og resterende medlemmer i skyen.

Rettelse af databasestrengfejl

Fra MongoDB 3.4 understøttes SCCC-konfigurationsservere ikke for spejlede mongod-forekomster. Hvis du skal opgradere din sharded cluster til version 3.4, skal du konvertere konfigurationsservere fra SCCC til CSRS.

Undgå nedetid ved flytning af konfigurationsservere

Nedetid kan forekomme som følge af nogle faktorer såsom strømafbrydelse eller netværksfrekvenser, hvilket resulterer i fejl på en konfigurationsserver til klyngen. Brug CNAME til at identificere den server til omdøbning eller omnummerering under genforbindelse. Hvis moveChunk commit-kommandoen mislykkes under migreringsprocessen, vil MongoDB rapportere fejlen:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

Dette betyder, at shard heller ikke er blevet forbundet til konfigurationsdatabasen, så den primære vil afslutte dette medlem for at undgå datainkonsistens. Du skal løse chunk-migreringsfejlen uafhængigt ved at konsultere MongoDB-supporten. Sørg også for at give nogle stabile ressourcer som netværk og strøm til klyngen.

Konklusion

En MongoDB sharded cluster reducerer arbejdsbyrden, som en enkelt server ville have været udsat for, og forbedrer dermed ydeevnen af gennemstrømningsoperationer. Men undladelse af at konfigurere nogle parametre korrekt som at vælge en optimal shard-nøgle kan skabe en belastningsubalance, hvorfor nogle shards ender med at fejle.

Forudsat at konfigurationen er udført korrekt, kan nogle uundgåelige tilbageslag, såsom strømafbrydelser, også forekomme. For at fortsætte med at understøtte din applikation med minimal nedetid skal du overveje at bruge mindst 3 datacentre. Hvis en fejler, vil de andre være tilgængelige for at understøtte læseoperationer, hvis den primære er blandt de berørte medlemmer. Opgrader også dit system til mindst version 3.4, da det understøtter flere funktioner.