En tjekliste for udvikling og drift for MongoDB

MongoDB drifts- og udviklingstjeklister er beregnet til at hjælpe databaseadministratorer med at undgå at støde på problemer i MongoDB produktionsmiljøet. En udviklingstjekliste bør behandle spørgsmål som...

1. Skemadesign
2. Datas holdbarhed
3. replikering
4. Drev 
5. Sharding 

En betjeningstjekliste adresserer på den anden side...

1. replikering
2. Filsystem 
3. Sharding
4. Hardware
5. Journaling (WiredTiger Storage Engine) 
6. Opsætning af operativsystem 
7. Implementering til cloud-hardware 
8. Overvågning
9. Sikkerhedskopier og belastningsbalancering

Før et projekt påbegyndes, er det tilrådeligt at arbejde på en tjekliste for drift og udvikling for at muliggøre en problemfri drift af MongoDB i produktionen. Denne artikel forklarer tjeklisten for drift og udvikling, før MongoDB implementeres.

MongoDB-driftstjekliste

replikering

Alle replika-medlemssæt, der ikke er skjulte, skal klargøres på samme måde med hensyn til disk, RAM, netværksopsætning og CPU.

Oplog-størrelse bør konfigureres korrekt til at imødekomme operationelle behov, således at:

• For at undgå behovet for en fuld gensynkronisering bør replika-oplog-applikationsvinduet dække det almindelige nedetids- og vedligeholdelsesvindue.
• For at gendanne et replikeringssætmedlem skal replika-oplogvinduet altid dække den nødvendige tid.

Produktionssættet bør som minimum indeholde tre databærende noder, der kører med journalføring aktiveret. Desuden skriver skal udstedes  med w:"majority" skrive bekymring med det formål at sikre datatilgængelighed og holdbarhed.

Implementeringen skal indeholde et ulige antal stemmeberettigede medlemmer for at lette afstemningsprocessen, når den primære node i klyngen fejler.

I stedet for at bruge IP-adresser, som muligvis kræver, at man ændrer konfigurationer på grund af ændring af IP, anbefales brug af logiske DNS-værtsnavne.

Sørg for, at mongod-forekomster har 0 eller 1 stemmer.

Alle Mongod-forekomster bør være fuldt og tovejs forbundet, således at det er let at kommunikere data mellem de involverede noder.

Journalist

Dette er en strategi til at logge på journalfiler på disken, som bruges til at sikre dataholdbarhed i tilfælde af fejl. Alle forekomster bør have journalisering aktiveret af denne grund, især når de håndterer skrivetunge arbejdsbelastninger.

Tænk dog på, at dette påvirker forstærkninger i snapshot-stil, da de poster, der udgør databasens tilstand, vil dvæle på partitionerede volumener.

Filsystem

Brug ikke NFS-drev (News File System) til dbPath. NFS-drev kan muligvis resultere i en destabiliseret ydeevne. VMware virtuelle drev anbefales til brug af VMware-brugere.

Sørg for, at dine diskpartitioner er justeret med dine RAIDON-konfigurationer.

For Linux/Unix-brugere anbefales brug af XFS. XFS er kendt for at yde bedre med MongoDB.

For Windows-operativsystembrugere anbefales NTFS-filsystemet. Du bør undgå at bruge FAT-filsystemer.

Implementering til Cloud-hardware

Windows Azure:Ændr TCP Keepalive (tcp_keepalive_time) til 100-120. TCP-timeoutet for sit ude af gear på Azure stack balancer er også moderat for MongoDBs tilknytningspooling-adfærd

Brug MongoDB 2.6.4 eller nyere versioner på frameworks med høj-latency storage, såsom Windows Azure, da disse versioner inkorporerer eksekveringsforbedringer til disse frameworks.

Sharding

Placer dine konfigurationsservere på dedikeret hardware for ideel udførelse i ekspansive klynger.

Sørg for, at hardwaren har tilstrækkelig RAM til at opbevare informationsposterne helt i hukommelsen og har dedikeret lagerplads.

Implementer mongos-routere i overensstemmelse med retningslinjerne for generationsopsætning.

Synkroniser urene på alle komponenter i din sharded klynge ved at bruge NTP.

Sørg for fuldt tovejsnetværk mellem mongo'er, mongod og konfigurationsservere.

Brug CNAME'er til at genkende dine konfigurationsservere til klyngen, så du kan omdøbe og omnummerere dine konfigurationsservere uden nedetid.

Overvågning

Du kan bruge værktøjer som MongoDB Cloud Manager, ClusterControl eller en anden overvågningsramme til at screene nøgledatabasemetrikker og opsætte alarmer. Inkorporer advarsler for metrics:

• Køer
• Oplog-vindue for replikering
• Påstande
• Sidefejl
• Replikeringsforsinkelse

Overvåg hardwaremålinger for dine servere. Vær især opmærksom på tilgængelig diskplads, diskbrug, CPU

Hardware

Brug RAID10- og SSD-drev til ideel ydeevne.

SAN og virtualisering:

Sørg for, at hver af mongod-instanserne har klargjort IOPS til sin dbPath eller har sit fysiske krav eller LUN.

Undgå dynamiske hukommelseshøjdepunkter, såsom hukommelseshævelse, når du kører i virtuelle miljøer.

Undgå at indstille alle kopisæt-individer på samme SAN, da SAN kan være et enkelt punkt af skuffelse.

Belastningsbalancering

Design load balancere for at aktivere "sticky sessions" eller "client affinity" med en passende timeout for eksisterende forbindelser.

Undgå at placere belastningsbalancere mellem MongoDB-klyngen eller replikasættets komponenter.

Sikkerhedskopier

Planlæg periodiske test af din backup- og gendannelsesproces for at have tidsmålere ved hånden og bekræfte dens anvendelighed.

Opsætning af operativsystem

Windows

Overvej at deaktivere NTFS "sidste adgangstid"-opgraderinger.

Formatér NTFS-diske ved at bruge standardstørrelsen for tildelingsenheden på 4096 bytes.

Linux

Sluk for de enorme gennemsigtige sider.

Foretag justeringer af læsehovedindstillingerne for de terninger, hvor dine databasefiler er gemt. Readahead for WiredTiger-lagringsmotoren skal indstilles mellem 8 og 32.

Hvis du bruger tunet på RHEL / CentOS, skal du tilpasse din tilpassede profil. Talrige af de indstillede profiler, der leveres med RHEL / CentOS, kan påvirke udførelsen negativt med deres standardindstillinger. Tilpas din valgte indstillede profil til:

Deaktiver ligetil store sider.

Sæt readahead mellem 8 og 32 i alle tilfælde af kapacitetsmediesortering.

Brug noop eller deadline diskplanlæggere til SSD-drev.

Brug noop-diskplanlæggeren til virtualiserede drev i gæste-VM'er.

Deaktiver NUMA eller indstil vm.zone_reclaim_mode til 0 og kør mongod-forekomster med node-interleaving.

Juster ugrænseværdierne på din hardware, så de passer til din brug. I tilfælde af at forskellige mongod- eller mongo-forekomster kører under den samme klient, skaler du grænseværdierne på samme måde.

Design passende registreringshåndtag (fs.file-max), del pid constrain (kernel.pid_max), maksimal tråd pr. proces (kernel.threads-max) og maksimalt antal hukommelseskonturområder pr. proces (vm.max_map_count) til din afsendelse. For ekspansive rammer giver følgende værdier et godt udgangspunkt:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Sørg for, at dit framework har konfigureret swap-plads.

Henviser til dit operativsystems dokumentation for interessepunkter i den korrekte størrelse.

 Sørg for, at systemets standard-TCP Keepalive er indstillet nøjagtigt. En værdi på 300 giver ofte overlegen ydeevne for replikasæt og sharded clusters.

MongoDB-udviklingstjekliste

replikering

Brug et ulige antal stemmeberettigede personer for at sikre, at valg fortsætter effektivt. Du vil have op til 7 stemmeberettigede personer. I tilfælde af at du har et lige antal stemmeberettigede personer, og begrænsninger, såsom omkostninger, ikke tillade at inkludere en anden sekundær for at være stemmeberettiget medlem, vil du være i stand til at inkludere en dommer for at garantere et ulige antal stemmer.

Garantere, at dine sekundære forbliver opdaterede ved at bruge overvågningsværktøjer og ved at angive passende skriveproblemer.

Brug ikke hjælpelæsninger til at skalere den samlede læsegennemstrømning.

Skemadesign

Data i MongoDB indeholder et dynamisk mønster. Samlinger opretholder ikke rapportstrukturen. Dette tilskynder til iterativ forbedring og polymorfi. Under alle omstændigheder har samlinger ofte poster med overordentlig homogene strukturer.

Beslut det sæt af samlinger, du bare vil kræve, og de indekser, der kræves for at understøtte dine forespørgsler. Med det specielle tilfælde af _id-indekset, skal du lave alle indekser udtrykkeligt:​​MongoDB laver naturligvis ikke andre indekser end _id.

Garanterer, at din skemaplan understøtter din implementeringssortering:Hvis du planlægger at bruge sharded clusters til horisontal skalering, planlæg dit skema til at inkorporere en stærk shard-nøgle. Shard-nøglen påvirker læse- og skriveudførelsen ved at bestemme, hvordan MongoDB segmenterer data. Du kan ikke ændre shard-nøglen, når den først er indstillet.

Sørg for, at din skemaplan ikke afhænger af indekserede klynger, der vokser i længde uden binding. Normalt kan den bedste udførelse opnås, når sådanne indekserede klynger har mindre end 1000 komponenter.

Overvej dokumentestimatgrænserne, når du designer dit skema. BSON Document Estimate-begrænsningen er 16 MB pr. dokument. Hvis du har brug for større rapporter, skal du bruge GridFS.

Drivere

Gør brug af foreningspooling. De fleste MongoDB-chauffører understøtter foreningspooling. Ændr foreningspuljens størrelse, så den passer til din brugssituation, startende ved 110-115 % af det normale antal samtidige databasekrav.

Sørg for, at dine applikationer håndterer tidsmæssige skrive- og læsefejl under replikavalg.

Garanterer, at dine applikationer håndterer mislykkede anmodninger, og prøv dem igen, hvis det er relevant. Det gør chauffører ikke

prøv naturligvis mislykkede anmodninger igen.

Brug eksponentiel backoff-rationale for genforsøg på databaseanmodninger.

Brug cursor.maxTimeMS() til læsninger og wtimeout til skrivninger, hvis du ønsker at begrænse udførelsesperioden for databaseoperationer.

Dataholdbarhed

Sørg for, at dit replikasæt indeholder mindst tre databærende hubs med w:majority compose bekymring. Tre databærende hubs er påkrævet for replika-sæt bred data soliditet.

Garanti for, at alle forekomster bruger journalføring.

Sharding

Garanti for, at din shard-nøgle overfører belastningen ligeligt på dine shards.

Brug målrettede operationer til arbejdsbelastninger, der skal skaleres med antallet af shards.

For MongoDB 3.6 og senere returnerer sekundære ikke længere forældreløse data, medmindre de bruger læsebekymring "tilgængelig" (som er standard læsebekymring for læsninger mod sekundære, når de ikke er relateret til kausalt pålidelige sessioner).

Begyndende i MongoDB 3.6 holder alle medlemmer af shard replika-sættet chunk-metadata, hvilket tillader dem at bortfiltrere forældreløse børn, når de ikke bruger "tilgængelig". Som sådan kan ikke-målrettede eller udsendte forespørgsler, der ikke bruger "tilgængelig", køres sikkert på ethvert medlem og vil ikke returnere forældreløse oplysninger.

Det "tilgængelige" læseproblem kan returnere forældreløse dokumenter fra hjælpemedlemmer, da det ikke søger efter overhalede chunk-metadata. Under alle omstændigheder, i tilfælde af at returneringen af ​​forældreløse dokumenter er ubetydelig for en ansøgning, giver den "tilgængelige" læste bekymring den mindst mulige inaktivitetslæsning blandt de forskellige læste bekymringer.

Forudsplit og juster chunks manuelt, når der integreres ekspansive datasæt i en ny ikke-hashed shard samling. Forudspaltning og fysisk justering gør det muligt for indlejringsstakken at blive spredt blandt skårene, hvilket udvider udførelsen for startbelastningen.

Konklusion 

Drifts- og udviklingstjeklistestyring er et afgørende skridt, som udviklere skal indarbejde, når de bruger MongoDB i produktionen. De er vigtige overvejelser, fordi de forbedrer flowet af opgaver for et projekt i produktionen. MongoDB-produktionsmiljøet kræver stabile og pålidelige databasefunktioner, fordi databasen i produktionen gemmer data fra den virkelige verden. Dataintegriteten afhænger af databasens stabilitet, hvilket er aktiveret ved at sikre, at der arbejdes med alle elementer på tjeklisten for drift og udvikling før produktion.