Rick Golba er løsningsingeniør i Percona.
MongoDB er en yndlingsdatabase for udviklere. Som NoSQL-databasemulighed giver den udviklere et databasemiljø, der har fleksibelt skemadesign, automatiseret failover og et udviklerkendt inputsprog, nemlig JSON.
Der er mange forskellige typer NoSQL-databaser. Key-value-butikker gemmer og henter hvert element ved hjælp af dets navn (også kendt som en nøgle). Store kolonnelagre er en slags nøgleværdilager, der bruger kolonner og rækker (ligesom en relationsdatabase), kun navnene på kolonnerne og rækkerne i en tabel kan variere. Grafdatabaser bruger grafstrukturer til at gemme datanetværk. Dokumentorienterede databaser lagrer data som dokumenter, hvilket giver mere strukturel fleksibilitet end andre databaser.
MongoDB er en dokumentorienteret database. Det er en platform på tværs af platforme, der indeholder data i dokumenter i et binært kodet JSON-format (kendt som binært JSON eller BSON). Det binære format øger både JSONs hastighed og fleksibilitet og tilføjer flere datatyper.
MongoDB's replikeringsmekanismer hjælper med at levere høj tilgængelighed, og dets sharding-mekanisme giver mulighed for vandret skalerbarhed. Mange top internetfirmaer som Facebook og eBay bruger MongoDB i deres databasemiljø.
Hvorfor overvåge MongoDB?
Dit MongoDB-databasemiljø kan være simpelt eller kompliceret, lokalt eller distribueret lokalt eller i skyen. Hvis du vil sikre en performant og tilgængelig database, skal du spore og overvåge analyser for at:
- Bestem databasens aktuelle tilstand
- Gennemgå præstationsdata for at identificere enhver unormal adfærd
- Giv nogle diagnostiske data for at løse identificerede problemer
- Løs små problemer, før de vokser til større problemer
- Hold dit miljø kørende
- Sikre løbende tilgængelighed og succes
Overvågning af dit databasemiljø på en målbar og regelmæssig måde sikrer, at du kan se uoverensstemmelser, ulige adfærd eller problemer, før de påvirker ydeevnen. Korrekt overvågning betyder, at du hurtigt kan se afmatninger, ressourcebegrænsninger eller anden afvigende adfærd og handle for at løse disse problemer, før du bliver ramt af konsekvenserne af langsomme websteder og applikationer, utilgængelige data eller frustrerede kunder.
Hvad skal vi overvåge?
Der er mange ting, du kan overvåge i et MongoDB-miljø, men et par vigtige områder vil tip dig hurtigt, hvis noget er galt. Du skal analysere følgende metrics:
- Replikationsforsinkelse. Replikeringsforsinkelse henviser til forsinkelser i kopiering af data fra den primære node til en sekundær node.
- Replikatilstand. Replikatilstanden er en metode til sporing af, om sekundære noder er døde, og hvis der var valg af en ny primær node.
- Låsningstilstand. Låsningstilstanden viser, hvilke datalåse der er indstillet, og hvor længe de har været på plads.
- Diskudnyttelse. Diskudnyttelse refererer til diskadgang.
- Hukommelsesforbrug. Hukommelsesbrug refererer til, hvor meget hukommelse der bruges, og hvordan det bruges.
- Antal forbindelser. Antallet af forbindelser databasen har åbent for at kunne betjene anmodninger så hurtigt som muligt.
Lad os dykke ned i nogle af detaljerne.
Replikationsforsinkelse
MongoDB bruger replikering til at imødekomme tilgængelighedsudfordringer og mål. Replikering er formering af data fra en primær node til flere sekundære noder, da operationer på den primære node ændrer dataene. Disse noder kan være placeret på forskellige geografiske placeringer eller virtuelle.
Alt i alt skal datareplikering ske hurtigt og uden problemer. Der kan ske mange ting, der forhindrer replikeringsprocessen i at køre jævnt. Selv under de bedste forhold begrænser netværkets fysiske egenskaber, hvor hurtigt data replikeres. Forsinkelsen mellem start af replikering og færdiggørelse kaldes replikationsforsinkelse.
I et jævnt kørende sæt primære og sekundære knudepunkter (kaldet et "replikasæt") kopierer sekundærerne hurtigt ændringer på den primære og replikerer hver gruppe af operationer fra oploggen så hurtigt som de forekommer (eller så tæt som muligt) . Målet er at holde replikationsforsinkelsen tæt på nul. Data, der læses fra enhver knude, skal være ensartede. Hvis den valgte primære node går ned eller på anden måde ikke er tilgængelig, kan en sekundær overtage den primære rolle uden at påvirke nøjagtigheden af data til klienter. De replikerede data skal være i overensstemmelse med de primære data, før de primære gik ned.
Replikeringsforsinkelse er grunden til, at primære og sekundære noder bliver ude af synkronisering. Hvis en sekundær knude vælges som primær, og replikationsforsinkelsen er høj, kan sekundærens version af dataene være forældede. En tilstand med forhøjet replikationsforsinkelse kan ske af flere ikke-permanente eller udefinerede grunde og rette sig selv. Men hvis replikeringsforsinkelsen forbliver høj eller begynder at stige med en regelmæssig hastighed, er dette et tegn på et systemisk eller miljømæssigt problem. I begge tilfælde, jo større replikationsforsinkelse - og jo længere den forbliver høj - jo mere risikerer dine data at være forældede for klienter.
Der er kun en måde at analysere denne metrik på: overvåg den! Dette er en måling, der skal overvåges 24x7x365, så det gøres bedst ved hjælp af automatisering og udløsningsadvarsler for at advare DBA'er eller svarsystemadministratorer, så snart den rammer en uønsket tærskel. Konfigurationen for denne tærskel afhænger af din applikations tolerance for replikeringsforsinkelse. For at bestemme den korrekte tærskel skal du bruge et værktøj, der grafer forsinkelse over tid, såsom Compass, MongoBooster, Studio 3T eller Percona Monitoring and Management (PMM).
Replikatilstand
Replikering håndteres via replika-sæt. Et replikasæt er et sæt noder med en valgt primær node og flere sekundære noder. Den primære knude er indehaveren af de mest opdaterede data, og disse data replikeres til sekundærerne, når der foretages ændringer i den primære.
Normalt er et medlem af et replika-sæt primært, og alle de andre medlemmer er sekundære. Den tildelte status ændres sjældent. Hvis det gør det, vil vi vide om det (normalt med det samme). Rolleskiftet sker normalt hurtigt og normalt problemfrit, men det er vigtigt at forstå nøjagtigt, hvorfor nodestatus ændrede sig, da det kunne have været på grund af en hardware- eller netværksfejl. Skift mellem primær og sekundær tilstand (også kendt som flapping) er ikke en normal begivenhed, og i en perfekt verden bør det kun ske på grund af kendte årsager (for eksempel under miljøvedligeholdelse som opgradering af software eller hardware eller under en bestemt hændelse som netværksafbrydelse).
Låsningstilstand
Databaser er meget samtidige og ustabile miljøer, hvor flere klienter fremsætter anmodninger og indleder transaktioner, der bliver udført på dataene. Disse anmodninger og transaktioner sker ikke sekventielt eller i en rationel rækkefølge. Konflikter kan forekomme - for eksempel hvis transaktioner forsøger at opdatere den samme post eller det samme dokument, hvis en læseanmodning kommer under en opdatering til data osv. Den måde, som mange databaser håndterer at sikre, at der er adgang til data på en organiseret måde, er "låsning. ” Låsning opstår, når en transaktion forhindrer, at en databasepost, et dokument, en række, en tabel osv. Ændres eller læses, indtil den aktuelle transaktion er færdigbehandlet.
I MongoDB udføres låsning på indsamlings- eller dokumentniveau for at forhindre konflikter mellem samtidige transaktioner. Visse operationer kan også kræve en global databaselås (for eksempel når du slipper en samling). Hvis låsning forekommer for ofte, påvirker det ydelsen ved at lade transaktioner (inklusive læsninger) vente på, at låste dele af databasen bliver tilgængelige til læsning eller ændring. En høj låseprocent er et tegn på andre problemer i databasen: hardwarefejl, dårligt skema design, dårligt konfigurerede indekser, ikke brug af indekser osv.
Det er vigtigt at overvåge låseprocenten. Du bør vide, hvad en acceptabel procentdel er med hensyn til ydeevne, og hvor længe procentdelen kan opretholdes, før du påvirker ydeevnen. Hvis ydeevnen forringes for meget på grund af en høj låseprocent, kan den udløse en replikeret tilstandsændring gennem serverens reaktion.
Diskudnyttelse
Hver DBA skal overvåge den tilgængelige diskplads på deres databaseservere. Når en database bruger diskpladsen på værten, stopper den server brat. Proaktiv dimensionering af data og overvågning af logfilstørrelser er gode teknikker til databasestørrelse.
Ofte skal din database muligvis vokse automatisk. I disse tilfælde skal du garantere, at den ikke vokser ud af hardwaren. Regelmæssig gennemgang af diskplads kan hjælpe med at forhindre uventede databaseserverstop samt lokalisere dårlige designproblemer (som forespørgsler, der kræver en fuld indsamlingsscanning).
Hukommelsesforbrug
At gemme alle dine data i RAM fremskynder responstider for databaser. Men hvad betyder det, og hvordan ved du, når noget er i RAM?
Den måde, din database bruger hukommelse på, kan være noget uklar. En stor del af den hukommelse, som en server bruger, er til bufferpuljen (data). Det kan være svært at finde ud af, hvilken database der bruger den største del af bufferpuljehukommelsen, og endnu sværere at finde ud af, hvilke samlinger eller dokumenter der faktisk findes i bufferpuljehukommelsen. At kende disse oplysninger er nyttigt, når du afbalancerer din database på tværs af flere servere (via sharding) eller identificerer data, der er optimale til konsolidering i en serverinstans.
Brug af værktøjer til at bestemme, hvilke forekomster der bruger hukommelse mest, og til hvilke data, kan hjælpe dig med at optimere dit miljø.
Antal forbindelser
Databasetransaktioner initieres normalt af applikationer og processer gennem "forbindelser". Antallet af åbne forbindelser kan påvirke databasens ydeevne. I teorien skal forbindelsen afsluttes, når en transaktion er gennemført. I praksis bliver mange af forbindelserne imidlertid åbne. Det er normalt, at en database holder nogle forbindelser i live for at lette visse transaktioner, men hvis der er for mange åbne, kan det begrænse antallet af tilgængelige i forbindelsespuljen.
Som en bedste praksis skal en database holde forbindelser åbne i mindst mulig tid til at udfylde en anmodning. Dette gør det muligt for en lille pool af forbindelser til at betjene et stort antal transaktionsanmodninger. Ellers sidder applikationstransaktionsanmodninger fast og venter på en åben forbindelse. Du skal overvåge antallet af åbne forbindelser i databasen for at kontrollere, at de lukkes, og at der er et sundt antal forbindelser tilbage i puljen til indgående anmodninger.
Værktøjer leveret med MongoDB
Nu hvor vi ved, hvad vi skal overvåge, er det næste spørgsmål, hvordan? Heldigvis kommer MongoDB med nogle brugervenlige værktøjer til overvågning af serverstatistikker.
mongostat
Dette værktøj indeholder global statistik om hukommelsesforbrug, status for replikasæt og mere, opdateret hvert sekund (som standard).
Det mongostat hjælpeprogram giver dig et overblik over din MongoDB serverinstans. Hvis du kører en enkelt "mongod" -forekomst, viser den dig statistikken for den enkelte forekomst. Hvis du kører et MongoDB-klyngemiljø, returnerer det statistikken for "mongos" -forekomsten. mongostat bruges bedst til at se en enkelt forekomst til en bestemt begivenhed (for eksempel hvad sker der, når en bestemt applikationsanmodning kommer ind). Du kan bruge denne kommando til at overvåge grundlæggende serverstatistikker:
- CPU
- Hukommelse
- Disk IO
- Netværkstrafik
Se MongoDB-dokumentationen på mongostat for detaljer om brug.
mongotop
Dette værktøj giver statistik på samlingsniveau om læse- og skriveaktivitet.
Det mongotop kommandoen sporer den nødvendige tid til at gennemføre læse- og skriveoperationer på en MongoDB-serverinstans. Det giver statistik på niveau pr. Samling. mongotop returnerer værdier hvert sekund som standard, men du kan justere tidsrammen efter behov.
Alle metrics pr. Sekund er relateret til din servers konfiguration såvel som klyngearkitekturen. For enkeltforekomster, der kører lokalt, og ved hjælp af standardporten er alt, hvad du skal gøre, at indtaste mongotop kommando. Hvis du kører i et klynget miljø med flere mongod- og mongos-forekomster, skal du angive et værtsnavn og portnummer med kommandoen.
Se MongoDB-dokumentationen på mongotop til specifikationer for brug.
rs.status ()
Denne kommando giver status for replikasættet.
Du kan bruge rs.status () kommando for at få oplysninger om et kørende replika-sæt. Denne kommando kan køres fra konsollen for ethvert medlem af ethvert sæt, og den vil returnere status for replikasættet set af det pågældende medlem.
Se MongoDB-dokumentationen på rs.status () til specifikationer for brug.
