Problemen met een MongoDB Sharded-cluster oplossen

Shardsleutels en beschikbaarheid van clusters selecteren

Sharding omvat het verdelen van gegevens in kleine groepen, shards genaamd, om de algehele werklast voor een bepaalde doorvoer te verminderen operatie. Deze groepering wordt bereikt door een optimale sleutel te selecteren die voornamelijk het belangrijkste onderdeel is vóór sharding. Een optimale sleutel moet zorgen voor:

1. Mongo's kunnen de meeste zoekopdrachten naar een specifieke mongod isoleren. Als er bijvoorbeeld meer bewerkingen worden onderworpen aan een enkele shard, zal het falen van die shard er alleen voor zorgen dat de gegevens die eraan verbonden zijn op dat moment afwezig zijn. Het is raadzaam om een ​​Shard-sleutel te selecteren die meer shards geeft om de hoeveelheid onbeschikbare gegevens te verminderen in het geval dat de Shard crasht.
2. MongoDB kan de gegevens gelijkmatig over de chunks verdelen. Dit zorgt ervoor dat de doorvoerbewerkingen ook gelijkmatig worden verdeeld, waardoor de kans op fouten als gevolg van meer werkdruk wordt verminderd.
3. Schrijfschaalbaarheid in het cluster om een ​​hoge beschikbaarheid te garanderen. Elke scherf zou een replicaset moeten zijn, in die zin dat als een bepaalde mongod-instantie faalt, de resterende replicasetleden in staat zijn om een ​​ander lid als primair lid te kiezen, waardoor de operationele continuïteit wordt gewaarborgd.

Als in elk geval een bepaalde shard de neiging heeft om te mislukken, begin dan met te controleren hoeveel doorvoerbewerkingen is het onderhevig aan en overweeg om een ​​betere sharding-sleutel te selecteren om meer shards te hebben.

Wat als? Mongos-instantie wordt afwezig

Controleer eerst of je verbinding maakt met de juiste poort, aangezien je misschien onbewust bent veranderd. Bijvoorbeeld, implementatie met het AWS-platform, is er een kans op dit probleem vanwege de beveiligingsgroepen die mogelijk geen verbindingen op die poort toestaan. Probeer voor een onmiddellijke test de volledige host:port op te geven om er zeker van te zijn dat u een loopback-interface gebruikt. Het goede is dat als elke applicatieserver zijn eigen mongos-instantie heeft, de applicatieservers toegang kunnen blijven krijgen tot de database. Bovendien hebben mongo's-instanties hun status in de loop van de tijd gewijzigd en kunnen ze opnieuw worden opgestart zonder noodzakelijkerwijs gegevens te verliezen. Wanneer de instantie opnieuw is verbonden, zal het een kopie van de configuratiedatabase ophalen en beginnen met het routeren van query's.

Zorg ervoor dat de poort waarop u opnieuw verbinding probeert te maken, ook niet door een ander proces wordt bezet.

Wat als? Een lid wordt afwezig in de Shard Replica-set

Begin met het controleren van de status van de shard door het commando sh.status() uit te voeren. Als het geretourneerde resultaat de clusterId niet heeft, is de shard inderdaad niet beschikbaar. Onderzoek altijd beschikbaarheidsonderbrekingen en -storingen en als u deze niet in de kortst mogelijke tijd kunt herstellen, maakt u een nieuw lid aan om deze zo snel mogelijk te vervangen om meer gegevensverlies te voorkomen.

Als een secundair lid niet meer beschikbaar is, maar met de huidige oplog-items, kan het bij opnieuw verbinding de laatste ingestelde status door de huidige gegevens van de oplog te lezen als normaal replicatieproces. Als het de gegevens niet kan repliceren, moet u een eerste synchronisatie uitvoeren met een van deze twee opties...

1. Start mongod opnieuw met een lege datadirectory en laat MongoDB's normale initiële synchronisatiefunctie de gegevens herstellen. Deze benadering duurt echter lang om de gegevens te kopiëren, maar is vrij eenvoudig.
2. Start de hostmachine opnieuw op met een kopie van een recente gegevensmap van een ander lid in de replicaset. Snel proces maar met ingewikkelde stappen

De eerste synchronisatie stelt MongoDB in staat om...

1. Kloon alle beschikbare databases behalve de lokale databank. Zorg ervoor dat het doellid voldoende schijfruimte heeft in de lokale database om de oplog-records tijdelijk op te slaan voor de duur dat de gegevens worden gekopieerd.
2. Alle wijzigingen toepassen op de dataset met behulp van de oplog van de bron. Het proces is alleen voltooid als de status van de replica overgaat van STARTUP2 naar SECONDARY.

Wat als? Alle leden van een replicaset zijn afwezig

Gegevens in een shard  zijn niet beschikbaar als alle leden van een replicaset-shard afwezig zijn. Aangezien de andere shards beschikbaar blijven, zijn lees- en schrijfbewerkingen nog steeds mogelijk, behalve dat de toepassing wordt bediend met gedeeltelijke gegevens. U moet de oorzaak van de onderbrekingen onderzoeken en proberen de shard zo snel mogelijk opnieuw te activeren. Controleer welke queryprofiler of de explain-methode tot dat probleem heeft geleid.

Wat als? Verouderde configuratiegegevens leiden tot cursorstoringen

Soms kan het lang duren voordat een mongos-instantie de metadatacache uit de configuratiedatabase bijwerkt, waardoor een query wordt geretourneerd de waarschuwing: 

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

Deze fout wordt altijd weergegeven totdat de mongos-instanties hun caches verversen. Dit mag niet terug naar de toepassing worden verspreid. Om dit op te lossen, moet u de instantie forceren om te vernieuwen door fluRouterConfig uit te voeren.

De cache leegmaken voor een specifieke verzamelingsrun

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

Het cachegeheugen leegmaken voor een specifieke databaserun 

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

Om de cache voor alle databases en hun verzamelingen leeg te maken:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Wat als? Config Server wordt niet meer beschikbaar

Config-server kan in dit geval worden beschouwd als het primaire lid van waaruit secundaire knooppunten hun gegevens repliceren. Als het afwezig is, moeten de beschikbare secundaire knooppunten een van hun leden kiezen om de primaire te worden. Om te voorkomen dat u in een situatie terechtkomt waarin u mogelijk geen configuratieserver heeft, kunt u overwegen de leden van de replicaset te verdelen over twee datacenters sinds...

• Als een datacenter uitvalt, zijn er nog steeds gegevens beschikbaar voor lezen in plaats van geen bewerkingen als u één datacenter gebruikt .
• Als het datacenter met minderheidsleden uitvalt, kan de replicaset nog steeds zowel schrijf- als leesbewerkingen uitvoeren.

Het is raadzaam om leden over ten minste drie datacenters te verdelen.

Een andere distributiemogelijkheid is om de datadragende leden gelijkmatig te verdelen over de twee datacenters en de resterende leden in de cloud.

Fixing Database String Error

Vanaf MongoDB 3.4 worden SCCC-configuratieservers niet ondersteund voor gespiegelde mongod-instanties. Als u uw sharded-cluster moet upgraden naar versie 3.4, moet u configuratieservers converteren van SCCC naar CSRS.

Stilstand voorkomen bij het verplaatsen van configuratieservers

Stilstand kan optreden als gevolg van bepaalde factoren, zoals stroomuitval of netwerkfrequenties, wat resulteert in de uitval van een configuratieserver naar het cluster. Gebruik CNAME om die server te identificeren voor het hernoemen of hernummeren tijdens het opnieuw verbinden. Als de opdracht moveChunk commit mislukt tijdens het migratieproces, rapporteert MongoDB de fout:

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

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

Dit betekent dat de shard ook niet is verbonden met de configuratiedatabase, daarom zal de primaire dit lid beëindigen om inconsistentie van gegevens te voorkomen. U moet de chunk-migratiefout onafhankelijk oplossen door de MongoDB-ondersteuning te raadplegen. Zorg er ook voor dat u stabiele bronnen zoals netwerk en stroom aan het cluster levert.

Conclusie

Een MongoDB-shardcluster vermindert de werklast waaraan een enkele server zou zijn blootgesteld, waardoor de prestaties verbeteren van doorvoeractiviteiten. Als sommige params echter niet correct worden geconfigureerd, zoals het selecteren van een optimale shard-sleutel, kan er een onbalans in de belasting ontstaan, waardoor sommige shards uiteindelijk mislukken.

Ervan uitgaande dat de configuratie correct is uitgevoerd, kunnen er onvermijdelijke tegenslagen optreden, zoals stroomuitval. Overweeg om minimaal 3 datacenters te gebruiken om uw applicatie te blijven ondersteunen met minimale downtime. Als er een faalt, zijn de andere beschikbaar om leesbewerkingen te ondersteunen als de primaire een van de getroffen leden is. Upgrade ook uw systeem naar ten minste versie 3.4 omdat het meer functies ondersteunt.