Hur man övervakar MongoDB-databasprestanda

Rick Golba är lösningsingenjör på Percona.

MongoDB är en favoritdatabas för utvecklare. Som ett NoSQL-databasalternativ ger det utvecklare en databasmiljö som har flexibel schemadesign, automatiserad failover och ett utvecklarbekant inmatningsspråk, nämligen JSON.

Det finns många olika typer av NoSQL-databaser. Key-value-butiker lagrar och hämtar varje artikel med dess namn (även känd som en nyckel). Breda kolumnbutiker är ett slags nyckel-värdebutik som använder kolumner och rader (ungefär som en relationsdatabas), bara namnen på kolumnerna och raderna i en tabell kan variera. Grafdatabaser använder diagramstrukturer för att lagra datanätverk. Dokumentorienterade databaser lagrar data som dokument, vilket ger mer strukturell flexibilitet än andra databaser.

MongoDB är en dokumentinriktad databas. Det är en plattformsdatabas som innehåller data i dokument i ett binärt kodat JSON-format (känt som binärt JSON eller BSON). Det binära formatet ökar både hastigheten och flexibiliteten för JSON och lägger till fler datatyper.

MongoDB: s replikeringsmekanismer hjälper till att leverera hög tillgänglighet, och dess skärningsmekanism möjliggör horisontell skalbarhet. Många toppföretag på Internet som Facebook och eBay använder MongoDB i sin databasmiljö.

Varför övervaka MongoDB?

Din MongoDB-databasmiljö kan vara enkel eller komplicerad, lokal eller distribuerad, lokalt eller i molnet. Om du vill säkerställa en performant och tillgänglig databas bör du spåra och övervaka analyser för att:

  • Bestäm databasens nuvarande tillstånd
  • Granska prestandadata för att identifiera onormalt beteende
  • Ge några diagnostiska data för att lösa identifierade problem
  • Åtgärda små problem innan de växer till större problem
  • Håll din miljö igång smidigt
  • Se till att tillgänglighet och framgång fortsätter

Att övervaka din databasmiljö på ett mätbart och regelbundet sätt säkerställer att du kan upptäcka eventuella avvikelser, udda beteenden eller problem innan de påverkar prestanda. Korrekt övervakning innebär att du snabbt kan upptäcka avmattningar, resursbegränsningar eller annat avvikande beteende och agera för att åtgärda dessa problem innan du drabbas av konsekvenserna av långsamma webbplatser och applikationer, otillgänglig data eller frustrerade kunder.

Vad ska vi övervaka?

Det finns många saker du kan övervaka i en MongoDB-miljö, men några viktiga områden kommer att tipsa dig snabbt om något är fel. Du bör analysera följande mätvärden:

  • Replikeringsfördröjning . Replikeringsfördröjning avser förseningar i kopiering av data från den primära noden till en sekundär nod.
  • Replikatillstånd . Repliktillståndet är en metod för att spåra om sekundära noder har dött, och om det har valts till en ny primär nod.
  • Låsningstillstånd . Låsningstillståndet visar vilka datalås som är inställda och hur länge de har varit på plats.
  • Diskanvändning . Diskanvändning avser diskåtkomst.
  • Minnesanvändning . Med minnesanvändning avses hur mycket minne som används och hur det används.
  • Antal anslutningar . Antalet anslutningar databasen har öppnat för att kunna betjäna förfrågningar så snabbt som möjligt.

Låt oss gräva i några av detaljerna.

Replikeringsfördröjning

MongoDB använder replikering för att möta tillgänglighetsutmaningar och mål. Replikering är förökning av data från en primär nod till flera sekundära noder, eftersom operationer på den primära noden ändrar data. Dessa noder kan samlokaliseras, på olika geografiska platser eller virtuella.

Allt annat lika bör datareplikering ske snabbt och utan problem. Många saker kan hända som hindrar replikeringsprocessen från att köras smidigt. Även under de bästa förhållandena begränsar nätverkets fysiska egenskaper hur snabbt data replikeras. Fördröjningen mellan replikering och fullbordande kallas replikeringsfördröjning.

I en smidigt uppsättning primära och sekundära noder (kallad "replikuppsättning") kopierar sekundärerna snabbt ändringarna på den primära och replikerar varje grupp av operationer från oploggen så snabbt som de uppstår (eller så nära som möjligt) . Målet är att hålla replikeringsfördröjningen nära noll. Data som läses från vilken nod som helst ska vara konsekvent. Om den valda primära noden går ner eller på annat sätt inte är tillgänglig kan en sekundär ta över den primära rollen utan att påverka noggrannheten för data till klienter. De replikerade uppgifterna bör överensstämma med de primära uppgifterna innan den primära gick ner.

Replikeringsfördröjning är anledningen till att primära och sekundära noder inte blir synkroniserade. Om en sekundär nod väljs som primär och replikeringsfördröjningen är hög, kan sekundärversionen av data vara inaktuell. Ett tillstånd av förhöjd replikeringsfördröjning kan hända av flera icke-permanenta eller odefinierade skäl och korrigera sig själv. Men om replikeringsfördröjningen förblir hög eller börjar öka regelbundet är detta ett tecken på ett system- eller miljöproblem. I båda fallen, desto större replikeringsfördröjning - och ju längre den förblir hög - desto mer riskerar dina data att vara inaktuella för kunderna.

Det finns bara ett sätt att analysera detta mått: övervaka det! Detta är ett mått som ska övervakas 24x7x365, så det görs bäst med hjälp av automatisering och utlösningsvarningar för att varna DBA: er eller svarssystemadministratörer så snart det når en oönskad tröskel. Konfigurationen för denna tröskel beror på applikationens tolerans för replikeringsfördröjning. För att bestämma rätt tröskel, använd ett verktyg som grafer fördröjning över tid som Compass, MongoBooster, Studio 3T eller Percona Monitoring and Management (PMM).

Replikatillstånd

Replikering hanteras via replikuppsättningar. En replikuppsättning är en uppsättning noder med en vald primär nod och flera sekundära noder. Den primära noden är innehavaren av de mest uppdaterade uppgifterna, och den informationen replikeras till sekundärerna när ändringar görs i den primära.

Normalt är en medlem i en replikuppsättning primär och alla andra medlemmar är sekundära. Den tilldelade statusen ändras sällan. Om det gör det vill vi veta om det (vanligtvis omedelbart). Rolländringen sker vanligtvis snabbt och vanligtvis sömlöst, men det är viktigt att förstå exakt varför nodstatusen har ändrats, eftersom det kan ha varit på grund av ett hårdvaru- eller nätverksfel. Att växla mellan primär- och sekundärtillståndet (även känt som flapping) är inte en vanlig händelse, och i en perfekt värld bör det bara ske på grund av kända skäl (till exempel under miljöunderhåll som att uppgradera programvara eller hårdvara, eller under en specifik incident som som ett nätverksavbrott).

Låsningstillstånd

Databaser är mycket samtidiga och flyktiga miljöer, med flera kunder som gör förfrågningar och initierar transaktioner som utförs på data. Dessa förfrågningar och transaktioner sker inte i följd eller i en rationell ordning. Konflikter kan uppstå - till exempel om transaktioner försöker uppdatera samma post eller dokument, om en läsförfrågan kommer under en uppdatering av data etc. Det sätt som många databaser hanterar på att se till att data nås på ett organiserat sätt är "låsning. ” Låsning sker när en transaktion förhindrar att en databaspost, dokument, rad, tabell etc. ändras eller läses tills den aktuella transaktionen är klar att bearbetas.

I MongoDB utförs låsning på insamlings- eller dokumentnivå för att förhindra konflikter mellan samtidiga transaktioner. Vissa operationer kan också kräva ett globalt databaslås (till exempel när du släpper en samling). Om låsning inträffar för ofta påverkar det prestanda genom att göra transaktioner (inklusive läsningar) vänta på att låsta delar av databasen blir tillgängliga för läsning eller modifiering. En hög låsningsprocent är ett tecken på andra problem i databasen: hårdvarufel, dålig schemadesign, dåligt konfigurerade index, att inte använda index etc.

Det är viktigt att övervaka låsningsprocenten. Du bör veta vad en acceptabel procentsats är med avseende på prestanda och hur länge procentsatsen kan bibehållas innan prestanda påverkas. Om prestanda försämras för mycket på grund av en hög låsningsprocent kan det utlösa en replikering av tillståndsförändring genom serverns svar.

Diskanvändning

Varje DBA bör övervaka tillgängligt diskutrymme på sina databasservrar. När en databas förbrukar hårddiskutrymmet på värden stoppar servern plötsligt. Proaktivt dimensionering av data och övervakning av loggstorlekar är bra tekniker för databasstorlek.

Ofta kan din databas behöva växa automatiskt. I dessa fall måste du garantera att det inte växer ut hårdvaran. Genom att regelbundet granska diskutrymme kan du förhindra oväntade databasserverstopp och hitta dåliga designproblem (som frågor som kräver en fullständig samlingssökning).

Minnesanvändning

Att hålla alla dina data i RAM-kort snabbar databasens svarstider. Men vad betyder det, och hur vet du när något finns i RAM?

Hur din databas använder minne kan vara något oklart. Mycket av minnet som en server använder är för buffertpoolen (data). Det kan vara svårt att ta reda på vilken databas som använder den största delen av buffertpoolminnet och ännu svårare att ta reda på vilka samlingar eller dokument som faktiskt finns i buffertpoolminnet. Att veta den här informationen är användbar när du balanserar din databas över flera servrar (via sharding) eller identifierar data som är optimala för konsolidering till en serverinstans.

Att använda verktyg för att avgöra vilka instanser som använder minnet mest och för vilka data kan hjälpa dig att optimera din miljö.

Antal anslutningar

Databastransaktioner initieras vanligtvis av applikationer och processer genom "anslutningar". Antalet öppna anslutningar kan påverka databasens prestanda. I teorin ska anslutningen avslutas när en transaktion är klar. I praktiken blir dock många av anslutningarna öppna. Det är normalt att en databas håller några anslutningar vid liv för att underlätta vissa transaktioner, men om för många lämnas öppna kan det begränsa antalet tillgängliga i anslutningspoolen.

Som en bästa praxis bör en databas hålla anslutningarna öppna under minst den tid som krävs för att slutföra en begäran. Detta gör att en liten pool av anslutningar kan betjäna ett stort antal transaktionsförfrågningar. Annars kommer ansökningstransaktionsförfrågningar att fastna och vänta på en öppen anslutning. Du måste övervaka antalet öppna anslutningar i databasen för att verifiera att de stängs och att det finns ett hälsosamt antal anslutningar kvar i poolen för inkommande förfrågningar.

Verktyg med MongoDB

Nu när vi vet vad vi ska övervaka är nästa fråga hur? Lyckligtvis kommer MongoDB med några lättanvända verktyg för övervakning av serverstatistik.

mongostat

Detta verktyg tillhandahåller global statistik om minnesanvändning, replikuppsättningsstatus och mer, uppdateras varje sekund (som standard).

Den mongostatVerktyget ger dig en överblick över din MongoDB Server-instans. Om du kör en enda "mongod" -instans visar den statistiken för den enskilda instansen. Om du kör en MongoDB-klustermiljö returnerar den statistiken för "mongos" -instansen. mongostatanvänds bäst för att titta på en enda instans för en specifik händelse (till exempel vad som händer när en specifik applikationsbegäran kommer in). Du kan använda det här kommandot för att övervaka grundläggande serverstatistik:

  • CPU
  • Minne
  • Disk IO
  • Nätverkstrafik

Se MongoDB-dokumentationen mongostatför information om användning.

mongotop

Detta verktyg tillhandahåller statistik på samlingsnivå om läs- och skrivaktiviteter.

Den mongotopkommandot spårar den tid som krävs för att slutföra läs- och skrivoperationer på en MongoDB server instans. Det ger statistik på en nivå per insamling. mongotopreturnerar värden varje sekund som standard, men du kan justera tidsramen efter behov.

Alla mätvärden per sekund är relaterade till serverkonfigurationen, liksom klusterarkitekturen. För enstaka instanser som körs lokalt och använder standardporten är allt du behöver göra att ange mongotopkommandot. Om du kör i en klustrad miljö med flera mongod- och mongosinstanser måste du ange ett värdnamn och portnummer med kommandot.

Se MongoDB-dokumentationen mongotopför information om användning.

rs.status()

Det här kommandot ger status för replikuppsättningen.

Du kan använda rs.status()kommandot för att få information om en löpande replikuppsättning. Det här kommandot kan köras från konsolen för alla medlemmar i vilken uppsättning som helst, och det returnerar statusen för replikuppsättningen som den berörda medlemmen ser.

Se MongoDB-dokumentationen rs.status()för information om användning.