Viktiga kontroller för en hälsosam MongoDB-databas

Att upprätthålla en hälsosam MongoDB-databas är avgörande för att säkerställa applikationsstabilitet, optimal prestanda och dataintegritet. Ett ”friskt” kluster är ett som pålitligt hanterar läs- och skrivoperationer, skyddar data mot förlust och fungerar inom förväntade driftparametrar. Regelbundna kontroller och proaktiv övervakning är avgörande för att identifiera och åtgärda potentiella problem innan de påverkar din tjänst.

Vi kan dela in hälsan hos ditt MongoDB-kluster i tre grundläggande områden:

• Replikering
• Prestanda
• Backup 

Genom att regelbundet utvärdera dessa områden säkerställer du att din dataplattform är robust och pålitlig. Dessutom erbjuder moderna hanteringsverktyg som MongoDB Atlas och MongoDB Ops Manager integrerad övervakning med aviseringar och rekommendationer för att hjälpa dig ligga steget före potentiella problem. Att konfigurera aviseringar hjälper dig att hålla koll. Du hittar instruktioner och exempel om hur du ställer in aviseringar i den officiella MongoDB-dokumentationen.

Låt oss gå igenom dessa områden.

Replikeringsstatus

Replikering är ryggraden i hög tillgänglighet i MongoDB. Ett friskt replikeringsset säkerställer redundans och möjlighet till failover. Låt oss titta på tre viktiga indikatorer för att säkerställa effektiv replikering mellan servrarna som utgör medlemmarna i replikeringssetet.

Övergripande status och detaljer för replikeringsstatus 

Den kompletta statusen för ett replikeringsset kan hämtas genom att köra kommandot rs.status() i MongoDB-skalet. Detta kommando ger en heltäckande bild av replikeringssetets aktuella tillstånd. Utdata bör kontrolleras för att bekräfta att alla medlemmar är friska (d.v.s. i PRIMARY- eller SECONDARY-tillstånd) och fungerar som förväntat.

I Atlas-gränssnittet kan du också komma åt liknande information som kommandot ovan tillhandahåller. Från sidan ”Clusters” klickar du på ett specifikt klusternamn. Den åtgärden tar dig till fliken ”Overview”, där du får en översikt över noderna. Om något är riktigt fel bör det visas där. 

Tid för replikering

Beständighet i ett replikerat kluster beror på att data replikeras till en majoritet av noderna. Av den anledningen måste ett friskt kluster replikera snabbt. Om det inte gör det får operationer med skrivkravet majority längre latenser.

Den ledande indikatorn för detta är replikationsfördröjningen. Replikationsfördröjning avser fördröjningen mellan en operation på primärnoden och dess efterföljande tillämpning på en sekundär nod. Låg och stabil replikationsfördröjning är en stark hälsoindikator. Långsam replikering kan å andra sidan vara ett tecken på dåligt konfigurerade anslutningar mellan noder.

Det enklaste sättet att observera replikationsfördröjningen är att titta på diagrammet ”Replication Lag” under fliken ”Cluster Metrics”. Här är ett exempel på detta diagram för ett friskt kluster. Observera att denna metrisk inte gäller för klustrets PRIMARY-nod, den i mitten markerad med ett ”P”.

Replication Oplog Window 

Replikering implementeras via en särskild samling som kallas ”oplog”. Oplog (operationslogg) är en capped collection som registrerar alla dataändrande operationer. ”Replication Oplog Window” avser den ungefärliga tid som finns tillgänglig i replikerings-oplogen för synkkällan innan aktuella operationer börjar skrivas över. Med andra ord är Replication Oplog Window tidsskillnaden mellan de nyaste och äldsta tidsstämplarna i oplog. Ett tillräckligt värde för oplog-fönstret är avgörande för att sekundära noder ska kunna komma ikapp efter ett avbrott och för att undvika behovet av fullständig omsynkronisering av data.

Om en sekundär nod är offline längre än det tillgängliga Replication Oplog Window måste man synka om den sekundära noden från grunden. Med andra ord vill du ha ett värde för Replication Oplog Window som är längre än den maximala tid en replik kan vara otillgänglig. Notera att värdet är känsligt för toppar i skrivoperationer.

För att få ett större Replication Oplog Window kan man öka storleken på oplog-samlingen.

Prestandastatus

Prestanda påverkar direkt användarupplevelsen av din applikation och kostnaderna för att drifta klustret. Ett friskt kluster presterar effektivt i förhållande till sin arbetsbelastning.

Även här tittar vi på kritiska prestandaaspekter att övervaka.

Aktuellt antal operationer ligger på förväntad nivå 

Det första jag brukar kontrollera är om klustret tar emot det förväntade antalet operationer. Här förutsätter ”förväntat” att du känner till värdet. Om inte kan det ge en bra förståelse att undersöka trenden för frågor under den senaste timmen, dagen, veckan osv., och om några toppar eller avvikelser inträffar. En återkommande veckotopp vid en viss tidpunkt kan kräva att klustret skalas upp i förväg.

Håll ett öga på takten för operationer (läsningar, skrivningar, kommandon). Plötsliga, oväntade toppar eller fall kan indikera ett problem, såsom ett applikationsfel, en resursbegränsning eller ett ineffektivt frågemönster. För att hjälpa dig kan du ställa in aviseringar på antalet operationer, som kan observeras i avsnittet ”Opcounters” i klustermetrikerna.

Dessutom finns realtidsinformation om den aktuella takten för operationer i fliken ”Real Time”.

Få bättre insikt i långsamma frågor 

Frågor som tar ovanligt lång tid att köra kallas långsamma frågor. Dessa indikerar ofta behov av indexering eller optimering. Det är också viktigt att övervaka operationer som kräver sortering i minnet, eftersom detta kan förbruka mycket serverresurser och försämra prestandan.

Fliken ”Query Insights” låter dig visa frågor, filtrera dem efter kriterier och utföra ytterligare åtgärder. Du vill använda den här sidan för att identifiera vilka frågor som bör optimeras och vilka som kanske behöver köras på en annan nod eller vid en senare tidpunkt.

Saknade index

Den vanligaste orsaken till långsamma frågor i MongoDB är avsaknaden av lämpliga index. MongoDB kan utföra en samlingsskanning (kontroll av varje dokument i samlingen) när ett index saknas, men detta är mycket ineffektivt, särskilt på stora samlingar. Att identifiera och skapa saknade index är avgörande för att upprätthålla frågeprestanda.

Fliken ”Performance Advisor” innehåller flera värdefulla verktyg som hjälper dig optimera prestanda. Nedan är sidan ”Create Indexes”.

Backupstatus

Replikering är en värdefull tillgång för att mildra dataförlust när resurser, som en servers disk, går förlorade eller skadas. Klustrets inbyggda höga tillgänglighet täcker de flesta maskinvarufel. Men en pålitlig backupstrategi är fortfarande det yttersta skyddet mot dataförlust. Ett friskt kluster har ett testat, fungerande system för backup och återställning.

Liksom i de andra avsnitten tittar vi på några viktiga överväganden för din backupstrategi.

Definiera återställningsmålen 

Definiera ditt Recovery Point Objective (RPO), vilket är den maximalt acceptabla mängden dataförlust, och ditt Recovery Time Objective (RTO), vilket är den maximalt tillåtna tiden för att återställa tjänsten. Dessa mål avgör nödvändig frekvens och metod för dina backuper.

Grunderna i backup

Det finns olika verktyg för att säkerhetskopiera data med MongoDB. Det börjar med en enkel dump av dina data med mongodump. Därefter går man vidare till att använda MongoDB:s hanteringsverktyg för att ta ögonblicksbilder och bevara enskilda operationer (oplog) för att återskapa en bild av valfri tidpunkt. MongoDB Atlas inkorporerar dessa verktyg för hostade kluster, medan MongoDB OpsManager utför en liknande funktion för dina kluster på plats.

Att behålla många versioner av data som backup tar vanligtvis mer utrymme än själva originaldatabasen. Du bör förstå kostnaderna för att bättre matcha dina behov. Denna övning resulterar i ett schema som visar hur många ögonblicksbilder som ska produceras och deras respektive frekvens.

Spåra, komma åt och återställa backuper

Om du använder MongoDB Atlas, verifiera att den hanterade backup-processen körs framgångsrikt, regelbundet tar ögonblicksbilder och att kvarhållningspolicyerna överensstämmer med ditt RPO.

Utför en återställning: Det enda sättet att verkligen bekräfta att dina backuper är giltiga är att regelbundet utföra ett återställningstest. Denna åtgärd validerar hela kedjan för backup och återställning och säkerställer att data går att återställa vid en nödsituation.

Slutsats

Ett friskt MongoDB-kluster kännetecknas av:

• Optimal replikeringsstatus
• Effektiv prestanda
• Pålitliga backuper

Proaktiv övervakning inom dessa tre områden, analys av frågeprestanda och test av återställningsåtgärder säkerställer stabiliteten och livslängden för din MongoDB-distribution.