Rick Golba er løsningsingeniør i Percona.
MongoDB er en favorittdatabase for utviklere. Som NoSQL-databasealternativ gir det utviklere et databasemiljø som har fleksibelt skjemadesign, automatisert failover og et utvikler-kjent inndataspråk, nemlig JSON.
Det finnes mange forskjellige typer NoSQL-databaser. Key-value-butikker lagrer og henter hvert element med navnet sitt (også kjent som en nøkkel). Brede kolonnelager er en slags nøkkelverdi-butikk som bruker kolonner og rader (omtrent som en relasjonsdatabase), bare navnene på kolonnene og radene i en tabell kan variere. Grafdatabaser bruker grafstrukturer til å lagre nettverk av data. Dokumentorienterte databaser lagrer data som dokumenter, og gir mer strukturell fleksibilitet enn andre databaser.
MongoDB er en dokumentorientert database. Det er en database på tvers av plattformer som inneholder data i dokumenter i et binært kodet JSON-format (kjent som binært JSON eller BSON). Det binære formatet øker både hastigheten og fleksibiliteten til JSON, og legger til flere datatyper.
MongoDBs replikeringsmekanismer hjelper til med å levere høy tilgjengelighet, og skjæringsmekanismen gir horisontal skalerbarhet. Mange topp Internett-selskaper som Facebook og eBay bruker MongoDB i databasemiljøet.
Hvorfor overvåke MongoDB?
Ditt MongoDB-databasemiljø kan være enkelt eller komplisert, lokalt eller distribuert, lokalt eller i skyen. Hvis du vil sikre en performant og tilgjengelig database, bør du spore og overvåke analyser for å:
- Bestem gjeldende status for databasen
- Gjennomgå ytelsesdata for å identifisere unormal oppførsel
- Gi noen diagnostiske data for å løse identifiserte problemer
- Løs små problemer før de blir større
- Hold miljøet i gang
- Sikre kontinuerlig tilgjengelighet og suksess
Overvåking av databasemiljøet ditt på en målbar og regelmessig måte sikrer at du kan oppdage avvik, merkelig oppførsel eller problemer før de påvirker ytelsen. Riktig overvåking betyr at du raskt kan oppdage forsinkelser, ressursbegrensninger eller annen avvikende oppførsel og handle for å løse disse problemene før du blir truffet med konsekvensene av langsomme nettsteder og applikasjoner, utilgjengelige data eller frustrerte kunder.
Hva skal vi overvåke?
Det er mange ting du kan overvåke i et MongoDB-miljø, men noen få viktige områder vil tipse deg raskt hvis noe er galt. Du bør analysere følgende beregninger:
- Replikasjonsforsinkelse. Replikasjonsforsinkelse refererer til forsinkelser i kopiering av data fra primærnoden til en sekundær node.
- Replikatilstand. Replikatilstanden er en metode for sporing av om sekundære noder har dødd, og om det var valg av en ny primærnode.
- Låsetilstand. Låsetilstanden viser hvilke datalåser som er satt, og hvor lang tid de har vært på plass.
- Diskutnyttelse. Diskutnyttelse refererer til disktilgang.
- Minnebruk. Minnebruk refererer til hvor mye minne som brukes, og hvordan det brukes.
- Antall tilkoblinger. Antall tilkoblinger databasen har åpnet for å kunne levere forespørsler så raskt som mulig.
La oss fordype oss i noen av detaljene.
Replikasjonsforsinkelse
MongoDB bruker replikering for å møte tilgjengelighetsutfordringer og mål. Replikering er forplantning av data fra en primær node til flere sekundære noder, ettersom operasjoner på den primære noden endrer dataene. Disse nodene kan være samlokaliserte, på forskjellige geografiske steder eller virtuelle.
Alt skal like, skal datareplikering skje raskt og uten problemer. Mange ting kan skje som hindrer replikeringsprosessen i å kjøre jevnt. Selv under de beste forhold begrenser de fysiske egenskapene til nettverket hvor raskt data blir replikert. Forsinkelsen mellom replikering og fullføring av den kalles replikasjonsforsinkelse.
I et jevnt løpende sett med primære og sekundære noder (referert til som et "replika-sett") kopierer sekundærene raskt endringene på den primære, og replikerer hver gruppe operasjoner fra oploggen så fort de oppstår (eller så nær som mulig) . Målet er å holde replikasjonsforsinkelsen nær null. Data som leses fra hvilken som helst node skal være konsistente. Hvis den valgte primære noden går ned eller på annen måte er utilgjengelig, kan en sekundær overta den primære rollen uten å påvirke nøyaktigheten av data til klienter. De replikerte dataene skal være i samsvar med primærdataene før primærdataene gikk ned.
Replikasjonsforsinkelse er grunnen til at primære og sekundære noder blir ut av synkronisering. Hvis en sekundær node blir valgt som primær, og replikasjonsforsinkelsen er høy, kan sekundærens versjon av dataene være utdaterte. En tilstand med forhøyet replikasjonsforsinkelse kan skje av flere ikke-permanente eller udefinerte grunner og korrigere seg selv. Imidlertid, hvis replikasjonsforsinkelsen holder seg høy eller begynner å øke med en jevn hastighet, er dette et tegn på et systemisk eller miljømessig problem. I begge tilfeller, jo større replikasjonsforsinkelse - og jo lenger den forblir høy - jo mer risikerer dataene dine å være utdaterte for klienter.
Det er bare en måte å analysere denne beregningen på: overvåke den! Dette er en beregning som bør overvåkes 24x7x365, så det gjøres best ved hjelp av automatisering og utløservarsler for å varsle DBA-er eller systemadministratorer for respons så snart den treffer en uønsket terskel. Konfigurasjonen for denne terskelen er avhengig av applikasjonens toleranse for replikasjonsforsinkelse. For å bestemme riktig terskel, bruk et verktøy som grafer forsinkelse over tid, for eksempel Compass, MongoBooster, Studio 3T eller Percona Monitoring and Management (PMM).
Replikatilstand
Replikering håndteres via replika sett. Et replikasett er et sett med noder med en valgt primærnode og flere sekundære noder. Den primære noden er keeperen av de mest oppdaterte dataene, og disse dataene replikeres til sekundærene når det gjøres endringer i den primære.
Normalt er ett medlem av et replika sett primært, og alle de andre medlemmene er sekundære. Den tildelte statusen endres sjelden. Hvis det gjør det, vil vi vite om det (vanligvis umiddelbart). Rollendringen skjer vanligvis raskt, og vanligvis sømløst, men det er viktig å forstå nøyaktig hvorfor nodestatusen endret seg, da det kunne ha vært på grunn av en maskinvare- eller nettverksfeil. Bytte mellom primær og sekundær tilstand (også kjent som klaff) er ikke en vanlig forekomst, og i en perfekt verden bør det bare skje på grunn av kjente årsaker (for eksempel under miljøvedlikehold som oppgradering av programvare eller maskinvare, eller under en spesifikk hendelse slik som nettverksbrudd).
Låsetilstand
Databaser er svært samtidige og ustabile miljøer, med flere kunder som gjør forespørsler og starter transaksjoner som blir utført på dataene. Disse forespørslene og transaksjonene skjer ikke sekvensielt eller i en rasjonell rekkefølge. Det kan oppstå konflikter - for eksempel hvis transaksjoner prøver å oppdatere den samme posten eller dokumentet, hvis en leseforespørsel kommer under en oppdatering av data osv. Måten mange databaser håndterer å sørge for at data er tilgjengelig på en organisert måte er "låsning. ” Låsing skjer når en transaksjon forhindrer at en databasepost, dokument, rad, tabell, etc. endres eller leses til den nåværende transaksjonen er ferdig behandlet.
I MongoDB utføres låsing på samlings- eller dokumentnivå for å forhindre konflikter mellom samtidige transaksjoner. Enkelte operasjoner kan også kreve en global databaselås (for eksempel når du slipper en samling). Hvis låsing skjer for ofte, påvirker det ytelsen ved at transaksjoner (inkludert lesing) venter på at låste deler av databasen blir tilgjengelig for lesing eller endring. En høy låseprosent er et tegn på andre problemer i databasen: maskinvarefeil, dårlig skjemadesign, dårlig konfigurerte indekser, ikke bruk av indekser, etc.
Det er viktig å overvåke låseprosenten. Du bør vite hva en akseptabel prosentandel er med hensyn til ytelse, og hvor lenge prosentandelen kan opprettholdes før du påvirker ytelsen. Hvis ytelsen forringes for mye på grunn av en høy låseprosent, kan det utløse en replikert tilstandsendring gjennom serverens respons.
Diskutnyttelse
Hver DBA bør overvåke ledig diskplass på databaseserverne. Når en database bruker opp diskplass på verten, stopper den serveren brått. Proaktiv dimensjonering av data og overvåking av loggfilstørrelser er gode teknikker for databasestørrelse.
Ofte må databasen din vokse automatisk. I disse tilfellene må du garantere at det ikke vokser ut maskinvaren. Regelmessig gjennomgang av diskplass kan bidra til å forhindre uventede stopp på databaseserver, samt finne dårlige designproblemer (som spørsmål som krever full innsamling av samling).
Minnebruk
Å ha alle dataene dine i RAM gir raskere responstid for databaser. Men hva betyr det, og hvordan vet du når noe er i RAM?
Måten databasen bruker minne på, kan være noe uklar. Mye av minnet en server bruker, er til bufferbassenget (data). Det kan være vanskelig å finne ut hvilken database som bruker den største delen av bufferpoolminnet, og enda vanskeligere å finne ut hvilke samlinger eller dokumenter som faktisk er i bufferpoolminnet. Å vite denne informasjonen er nyttig når du balanserer databasen over flere servere (via sharding), eller identifiserer data som er optimale for konsolidering i en serverinstans.
Å bruke verktøy for å bestemme hvilke forekomster som bruker minne mest, og for hvilke data, kan hjelpe deg med å optimalisere miljøet ditt.
Antall tilkoblinger
Databasetransaksjoner initieres vanligvis av applikasjoner og prosesser gjennom "tilkoblinger". Antall åpne forbindelser kan påvirke ytelsen til databasen. I teorien bør forbindelsen avsluttes når en transaksjon er fullført. I praksis blir imidlertid mange av forbindelsene åpne. Det er normalt at en database holder noen tilkoblinger i live for å muliggjøre visse transaksjoner, men hvis for mange er åpne, kan det begrense antallet tilgjengelige i tilkoblingsbassenget.
Som en best praksis bør en database holde forbindelsene åpne i minst mulig tid for å fullføre en forespørsel. Dette tillater et lite basseng med tilkoblinger for å betjene et stort antall transaksjonsforespørsler. Ellers vil søknader om transaksjonstransaksjoner bli sittende fast og vente på en åpen forbindelse. Du må overvåke antall åpne forbindelser i databasen for å bekrefte at de lukkes, og at det er et sunt antall forbindelser igjen i bassenget for innkommende forespørsler.
Verktøy som følger med MongoDB
Nå som vi vet hva vi bør overvåke, er neste spørsmål hvordan? Heldigvis kommer MongoDB med noen brukervennlige verktøy for overvåking av serverstatistikk.
mongostat
Dette verktøyet gir global statistikk om minnebruk, replikasett og mer, oppdatert hvert sekund (som standard).
De mongostat verktøyet gir deg en oversikt over forekomst av din MongoDB-server. Hvis du kjører en enkelt "Mongod" -forekomst, viser den deg statistikken for den samme forekomsten. Hvis du kjører et MongoDB-klyngemiljø, returnerer den statistikken for "Mongo" -forekomsten. mongostat brukes best til å se på en enkelt forekomst for en bestemt hendelse (for eksempel hva som skjer når en spesifikk applikasjonsforespørsel kommer inn). Du kan bruke denne kommandoen til å overvåke grunnleggende serverstatistikk:
- prosessor
- Hukommelse
- Disk IO
- Nettverkstrafikk
Se MongoDB-dokumentasjonen på mongostat for detaljer om bruk.
mongotop
Dette verktøyet gir statistikk på samlingsnivå om lese- og skriveaktivitet.
De mongotop kommandoen sporer tiden som kreves for å fullføre lese- og skriveoperasjoner på en MongoDB-serverforekomst. Den gir statistikk på nivå per samling. mongotop returnerer verdier hvert sekund som standard, men du kan justere tidsrammen etter behov.
Alle beregningene per sekund er relatert til serverens konfigurasjon, samt klyngearkitekturen. For enkeltforekomster som kjøres lokalt, og bruker standardporten, er alt du trenger å gjøre å angi mongotop kommando. Hvis du kjører i et klynget miljø med flere forekomster av mongoder og mongoer, må du oppgi et vertsnavn og portnummer med kommandoen.
Se MongoDB-dokumentasjonen på mongotop for detaljer om bruk.
rs.status ()
Denne kommandoen gir status for replikasettet.
Du kan bruke rs.status () kommando for å få informasjon om et løpende replika-sett. Denne kommandoen kan kjøres fra konsollen til ethvert medlem av hvilket som helst sett, og den vil returnere statusen til replikasettet som sett av medlemmet i spørsmålet.
Se MongoDB-dokumentasjonen på rs.status () for detaljer om bruk.
