Felsökning av ett MongoDB Sharded Cluster

I MongoDB involverar stora datamängder operationer med hög genomströmning och detta kan överväldiga kapaciteten hos en enda server . Stora arbetsdatauppsättningar innebär mer stress på I/O-kapaciteten hos diskenheter och kan leda till problem som t.ex. Page Faults.

Det finns huvudsakligen två sätt att lösa detta...

1. Vertikal skalning stark> :ökar enstaka serverkapacitet. Uppnås genom att lägga till mer CPU, RAM och lagringsutrymme men med en begränsning att:tillgänglig teknik kan begränsa en enskild maskin från att vara tillräckligt kraftfull för viss arbetsbelastning. I praktiken finns det ett maximum för vertikal skalning.
2. Horisontell skalning genom skärning :Detta innebär att systemdatauppsättningen delas över flera servrar, vilket minskar den totala arbetsbelastningen för en enda server. Att utöka kapaciteten för distributionen kräver bara att man lägger till fler servrar för lägre totalkostnad än avancerad hårdvara för en enda maskin. Detta kommer dock med en avvägning att det kommer att finnas mycket komplexitet i infrastruktur och underhåll för utbyggnaden. Komplexiteten blir mer sofistikerad när man felsöker det sönderdelade klustret i en händelse av katastrof. I den här bloggen ger vi några av de felsökningsmöjligheter som kan hjälpa:
3. Välja Shard Keys och klustertillgänglighet 
4. Mongos-instansen blir otillgänglig
5. En medlem blir frånvarande från replikuppsättningen för skärvor
6. Alla medlemmar i en replikuppsättning är frånvarande
7. Inaktuella konfigurationsdata leder till markörfel
8. Konfigurationsservern blir otillgänglig
9. Åtgärda databassträngfel
10. Undviker driftstopp när du flyttar konfigurationsservrar

Välja Shard Keys och klustertillgänglighet

Sharding innebär att dela upp data i små grupper som kallas shards för att minska den totala arbetsbelastningen för en given genomströmning drift. Denna gruppering uppnås genom att välja en optimal nyckel som främst är den viktigaste delen innan skärning. En optimal nyckel bör säkerställa:

1. Mongos kan isolera de flesta frågor till en specifik mongod. Om till exempel fler operationer utsätts för en enskild skärpa, kommer ett fel på den skärpan endast att göra att data som är associerade med den saknas vid den tidpunkten. Det är tillrådligt att välja en shard-nyckel som ger fler shards för att minska mängden data som inte är tillgänglig i fall shard kraschar.
2. MongoDB kommer att kunna dela upp data jämnt mellan bitarna. Detta säkerställer att genomströmningsoperationer också kommer att fördelas jämnt, vilket minskar risken för misslyckande på grund av mer stress på arbetsbelastningen.
3. Skriv skalbarhet över klustret för att säkerställa hög tillgänglighet. Varje skärva bör vara en replikuppsättning i det att om en viss mongod-instans misslyckas, kan de återstående replikuppsättningsmedlemmarna välja en annan medlem att vara en primär och därmed säkerställa driftskontinuitet.

Om en viss skärva i något fall har en tendens att misslyckas, börja med att kontrollera hur många genomströmningsoperationer är den utsatt för och överväg att välja en bättre skärningsnyckel för att få fler skärvor.

Vad händer om? Mongos-instansen blir frånvarande

Kontrollera först om du ansluter till rätt port eftersom du kan ha ändrats omedvetet. Till exempel, distribution med AWS-plattformen, det finns en sannolikhet för detta problem på grund av säkerhetsgrupperna som kanske inte tillåter anslutningar på den porten. För ett omedelbart test, försök att ange hela host:port för att se till att du använder ett loopback-gränssnitt. Det som är bra är att om varje applikationsserver har sin egen mongos-instans kan applikationsservrarna fortsätta att komma åt databasen. Dessutom har mongo-instanser sina tillstånd ändrade med tiden och kan starta om utan att nödvändigtvis förlora data. När instansen återansluts kommer den att hämta en kopia av konfigurationsdatabasen och börja dirigera frågor.

Se till att porten du försöker återansluta till inte heller är upptagen av en annan process.

Vad händer om? En medlem blir frånvarande från Shard Replica Set

Börja med att kontrollera fragmentets status genom att köra kommandot sh.status(). Om det returnerade resultatet inte har clusterId är skärvan verkligen inte tillgänglig. Undersök alltid tillgänglighetsavbrott och fel och om du inte kan återställa det på kortast möjliga tid, skapa en ny medlem för att ersätta den så snart som möjligt för att undvika mer dataförlust.

Om en sekundär medlem blir otillgänglig men med aktuella oplogposter, när den återansluts kan den komma ikapp med senaste inställda tillståndet genom att läsa aktuella data från oploggen som normal replikeringsprocess. Om det inte lyckas replikera data måste du göra en första synkronisering med något av dessa två alternativ...

1. Starta om mongod med en tom datakatalog och låt MongoDB:s normala initiala synkroniseringsfunktion återställa data. Det här tillvägagångssättet tar dock lång tid att kopiera data men ganska rakt fram.
2. Starta om värddatorn med en kopia av en ny datakatalog från en annan medlem i replikuppsättningen. Snabb process men med komplicerade steg

Den initiala synkroniseringen gör det möjligt för MongoDB att...

1. Klona alla tillgängliga databaser utom lokal databas. Se till att målmedlemmen har tillräckligt med diskutrymme i den lokala databasen för att tillfälligt lagra oplog-posterna under en tid som data kopieras.
2. Tillämpa  alla ändringar i datamängden använda oploggen från källan. Processen kommer endast att slutföras om statusen för repliken övergår från STARTUP2 till SEKUNDÄR.

Vad händer om? Alla medlemmar i en replikuppsättning är frånvarande

Data som lagras i en shard  kommer att vara otillgänglig om alla medlemmar i en replikuppsättning shard blir frånvarande. Eftersom de andra skärvorna förblir tillgängliga är läs- och skrivoperationer fortfarande möjliga förutom att applikationen kommer att serveras med partiella data. Du måste undersöka orsaken till avbrotten och försöka återaktivera fragmentet så snart som möjligt. Kontrollera vilken frågeprofilerare eller förklara metoden vad som kan ha lett till det problemet.

Vad händer om? Inaktuella konfigurationsdata leder till markörfel

Ibland kan en mongos-instans ta lång tid att uppdatera metadatacachen från konfigurationsdatabasen vilket leder till att en fråga returnerar varningen: 

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

Det här felet kommer alltid att visas tills mongos-instanserna uppdaterar sina cacher. Detta bör inte spridas tillbaka till applikationen. För att fixa detta måste du tvinga instansen att uppdateras genom att köra fluRouterConfig.

För att tömma cachen för en specifik samlingskörning

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

För att tömma cacheminnet för en specifik databaskörning 

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

Kör för att tömma cacheminnet för alla databaser och deras samlingar:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Vad händer om? Konfigurationsservern blir otillgänglig

Konfigurationsserver kan i detta fall betraktas som den primära medlemmen från vilken sekundära noder replikerar sina data. Om den blir frånvarande måste de tillgängliga sekundära noderna välja en bland sina medlemmar för att bli den primära. För att undvika att hamna i en situation där du kanske inte har en konfigurationsserver, överväg att distribuera replikuppsättningsmedlemmarna över två datacenter eftersom...

• Om ett datacenter går ner kommer data fortfarande att vara tillgängliga för läsning snarare än inga operationer om du använde ett enda datacenter .
• Om datacentret som omfattar minoritetsmedlemmar går ner, kan replikuppsättningen fortfarande tjäna både skriv- och läsoperationer.

Det är tillrådligt att fördela medlemmar över minst tre datacenter.

En annan distributionsmöjlighet är att fördela de databärande medlemmarna jämnt över de två datacentren och återstående medlemmar i molnet.

Åtgärda databassträngsfel

Från och med MongoDB 3.4 stöds inte SCCC-konfigurationsservrar för speglade mongod-instanser. Om du behöver uppgradera ditt delade kluster till version 3.4 måste du konvertera konfigurationsservrar från SCCC till CSRS.

Undviker driftstopp när du flyttar konfigurationsservrar

Nedtid kan inträffa som ett resultat av vissa faktorer som strömavbrott eller nätverksfrekvenser, vilket resulterar i fel på en konfigurationsserver till klustret. Använd CNAME för att identifiera den servern för att döpa om eller omnumrera under återanslutning. Om kommandot moveChunk commit misslyckas under migreringsprocessen kommer MongoDB att rapportera felet:

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

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

Detta betyder att skärvan inte heller har kopplats till konfigurationsdatabasen och därför kommer den primära att avsluta denna medlem för att undvika datainkonsekvens. Du måste lösa chunk-migreringsfelet självständigt genom att konsultera MongoDB-supporten. Se också till att tillhandahålla några stabila resurser som nätverk och ström till klustret.

Slutsats

Ett MongoDB fragmenterat kluster minskar arbetsbelastningen som en enskild server skulle ha utsatts för, vilket förbättrar prestanda av genomströmningsverksamheten. Om vissa parametrar inte konfigureras korrekt, som att välja en optimal skärvnyckel, kan det dock skapa en belastningsobalans, varför vissa skärvor slutar att misslyckas.

Förutsatt att konfigurationen görs korrekt kan vissa oundvikliga bakslag som strömavbrott också inträffa. För att fortsätta stödja din applikation med minimal stilleståndstid, överväg att använda minst 3 datacenter. Om en misslyckas kommer de andra att vara tillgängliga för att stödja läsoperationer om den primära är bland de drabbade medlemmarna. Uppgradera även ditt system till minst version 3.4 eftersom det stöder fler funktioner.