Een checklist voor ontwikkeling en bedrijfsvoering voor MongoDB

MongoDB-controlelijsten voor bediening en ontwikkeling zijn bedoeld om databasebeheerders te helpen problemen te voorkomen in de MongoDB-productieomgeving. Een ontwikkelingschecklist moet kwesties behandelen zoals...

1. Schemaontwerp
2. Duurzaamheid van gegevens
3. Replicatie
4. Drives 
5. Sharding 

Een operatie-checklist daarentegen adressen...

1. Replicatie
2. Bestandssysteem 
3. Sharding
4. Hardware
5. Journaling (WiredTiger Storage Engine) 
6. Besturingssysteemconfiguraties 
7. Implementatie naar cloudhardware 
8. Bewaking
9. Back-ups en taakverdeling

Voordat u een project start, is het raadzaam om aan de controlelijst voor bediening en ontwikkeling te werken om een ​​soepele werking van MongoDB in productie mogelijk te maken. In dit artikel wordt de controlelijst voor bediening en ontwikkeling uitgelegd voordat MongoDB wordt geïmplementeerd.

MongoDB Operations Checklist

Replicatie

Alle replica-ledensets die niet verborgen zijn, moeten identiek worden ingericht met betrekking tot schijf, RAM, netwerkconfiguratie en CPU.

Oplog-grootte moet correct worden geconfigureerd om aan operationele behoeften te voldoen, zodat:

• Om de noodzaak van een volledige hersynchronisatie te vermijden, moet het replica oplog-toepassingsvenster de normale downtime en het onderhoudsvenster dekken.
• Om een ​​lid van een replicatieset te herstellen, moet het replica-oplogvenster altijd de benodigde tijd beslaan.

De productieset moet minimaal drie gegevensdragende knooppunten bevatten die draaien met journaal ingeschakeld. Bovendien moeten schrijfopdrachten worden uitgegeven met w:"meerderheid" schrijfzorg om de beschikbaarheid en duurzaamheid van gegevens te garanderen.

De implementatie moet een oneven aantal stemmende leden bevatten om het stemproces te vergemakkelijken wanneer het primaire knooppunt in het cluster uitvalt.

In plaats van IP-adressen te gebruiken waarvoor een configuratie nodig kan zijn vanwege een veranderend IP-adres, wordt het gebruik van logische DNS-hostnamen aanbevolen.

Zorg ervoor dat mongod-instanties 0 of 1 stemmen hebben.

Alle Mongod-instanties moeten volledig en bidirectioneel zijn verbonden, zodat de gegevensuitwisseling tussen de betrokken knooppunten gemakkelijk is.

Journaling

Dit is een strategie voor het loggen van dagboekbestanden op schijf die wordt gebruikt om de duurzaamheid van gegevens te garanderen in geval van storing. Alle instanties moeten om deze reden journaling hebben ingeschakeld, vooral als het gaat om schrijfintensieve werkbelastingen.

Houd er echter rekening mee dat dit van invloed is op versterkingen in snapshot-stijl, aangezien de records die de status van de database vormen, op gepartitioneerde volumes blijven staan.

Bestandssysteem

Gebruik geen News File System-schijven (NFS) voor dbPath. NFS-schijven kunnen mogelijk leiden tot gedestabiliseerde prestaties. Virtuele VMware-schijven worden aanbevolen voor gebruik door VMware-gebruikers.

Zorg ervoor dat uw schijfpartities zijn uitgelijnd met uw RAIDON-configuraties.

Voor Linux/Unix-gebruikers wordt het gebruik van XFS aanbevolen. Van XFS is bekend dat het beter presteert met MongoDB.

Voor gebruikers van het Windows-besturingssysteem wordt het NTFS-bestandssysteem aanbevolen. Vermijd het gebruik van een FAT-bestandssysteem.

Deployment naar cloudhardware

Windows Azure:wijzig de TCP keepalive (tcp_keepalive_time) in 100-120. De time-out voor TCP-sit out of gear op de Azure-stackbalancer is ook gematigd voor het gedrag van MongoDB's associatiepooling

Gebruik MongoDB 2.6.4 of nieuwere versies op frameworks met opslag met hoge latentie, zoals Windows Azure, aangezien deze versies uitvoeringsverbeteringen voor die frameworks bevatten.

Sharden

Plaats uw configuratieservers op speciale hardware voor een ideale uitvoering in uitgebreide clusters.

Zorg ervoor dat de hardware voldoende RAM heeft om de informatierecords volledig in het geheugen te bewaren en dat er speciale opslagruimte is.

Implementeer mongos-routers in overeenstemming met de Generation Setup-richtlijnen.

Synchroniseer de klokken op alle componenten van uw Sharded-cluster met behulp van NTP.

Zorg voor een volledig bidirectioneel netwerk tussen mongos, mongod en configuratieservers.

Gebruik CNAME's om uw configuratieservers te herkennen in het cluster, zodat u uw configuratieservers kunt hernoemen en nummeren zonder downtime.

Bewaking

Je kunt tools gebruiken zoals MongoDB Cloud Manager, ClusterControl of een ander monitoringframework om belangrijke databasestatistieken te screenen en alarmen in te stellen. Waarschuwingen opnemen voor de statistieken:

• Wachtrijen
• Replicatie-oplogvenster
• Beweringen
• Paginafouten
• Replicatievertraging

Bewaak hardwarestatistieken voor uw servers. Let vooral op beschikbare schijfruimte, schijfgebruik, CPU

Hardware

Gebruik RAID10- en SSD-schijven voor ideale prestaties.

SAN en virtualisatie:

Zorg ervoor dat elk van de mongod-instanties IOPS heeft ingericht voor zijn dbPath, of zijn claim fysieke schijf of LUN heeft.

Vermijd dynamische geheugenhoogtepunten, zoals geheugenzwelling, wanneer u in virtuele omgevingen werkt.

Vermijd het instellen van alle kopieerset-individuen op hetzelfde SAN, aangezien het SAN een enkel punt van teleurstelling kan zijn.

Load Balancing

Ontwerp load balancers om "sticky session" of "client affinity" mogelijk te maken met een adequate time-out voor bestaande verbindingen.

Vermijd het plaatsen van load balancers tussen de MongoDB-cluster of replicasetcomponenten.

Back-ups

Plan intermitterende tests van uw back-up- en herstelproces om tijdmeters bij de hand te hebben en het nut ervan te bevestigen.

Besturingssysteemconfiguratie

Windows

Overweeg om NTFS-upgrades voor "laatste toegangstijd" te deactiveren.

Formatteer NTFS-schijven door gebruik te maken van de standaard toewijzingseenheid van 4096 bytes.

Linux

Schakel de enorme transparante pagina's uit.

Maak aanpassingen aan de leeskopinstellingen van de dobbelstenen waar uw databasebestanden zijn opgeslagen. De readahead van de WiredTiger-opslagengine moet worden ingesteld tussen 8 en 32.

Als je Tuned op RHEL / CentOS gebruikt, moet je je aangepaste profiel aanpassen. Talloze van de afgestemde profielen die met RHEL / CentOS worden geleverd, kunnen de uitvoering negatief beïnvloeden met hun standaardinstellingen. Pas het door u gekozen afgestemde profiel aan om:

Schakel ongecompliceerde grote pagina's uit.

Stel de readahead in tussen 8 en 32 in elk geval van capaciteitsmediasortering.

Gebruik de noop- of deadline-schijfplanners voor SSD-schijven.

Gebruik de noop-schijfplanner voor gevirtualiseerde schijven in gast-VM's.

Schakel NUMA uit of stel vm.zone_reclaim_mode in op 0 en voer mongod-exemplaren uit met node interleaving.

Pas de ulimit-waarden op uw hardware aan uw gebruiksscenario aan. In het geval dat verschillende mongod- of mongos-exemplaren onder dezelfde client worden uitgevoerd, schaalt u de ulimit-waarden op dezelfde manier.

Ontwerp adequate recordhandles (fs.file-max), part pid-beperking (kernel.pid_max), maximale thread per proces (kernel.threads-max) en maximaal aantal geheugenoverzichtsgebieden per proces (vm.max_map_count) voor uw verzending. Voor uitgebreide frameworks geven de volgende waarden een goed beginpunt:

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

Zorg ervoor dat uw framework swapruimte heeft geconfigureerd.

Verwijs naar de documentatie van uw besturingssysteem voor aandachtspunten over de juiste maatvoering.

 Zorg ervoor dat de standaard-TCP keepalive van het systeem correct is ingesteld. Een waarde van 300 geeft vaak superieure prestaties voor replicasets en shard-clusters.

MongoDB-ontwikkelingschecklist

Replicatie

Gebruik een oneven aantal stemmende individuen om te garanderen dat de verkiezingen effectief doorgaan. Je hebt maximaal 7 stemgerechtigden. In het geval dat u een even aantal stemgerechtigde personen heeft en beperkingen, zoals kosten, het niet toestaan ​​om een ​​ander secundair lid te zijn van een stemgerechtigd lid, kunt u een arbiter opnemen om een ​​oneven aantal stemmen te garanderen.

Garandeer dat uw secundaire bronnen up-to-date blijven door monitoringtools te gebruiken en door geschikte schrijfproblemen aan te geven.

Gebruik geen hulpuitlezingen om de algehele leesdoorvoer te schalen.

Schemaontwerp

Gegevens in MongoDB bevatten een dynamisch patroon. Collecties houden de rapportstructuur niet in stand. Dit stimuleert iteratieve verbetering en polymorfisme. In ieder geval bevatten collecties vaak records met buitengewoon homogene structuren.

Bepaal de verzameling verzamelingen die je alleen nodig hebt en de indexen die nodig zijn om je zoekopdrachten te ondersteunen. Met het speciale geval van de _id-index, moet u alle indexen uitdrukkelijk maken:MongoDB maakt van nature geen andere indexen dan _id.

Garandeer dat uw schemaplan uw implementatiesortering ondersteunt:als u van plan bent om sharded-clusters te gebruiken voor horizontale schaling, plan dan uw schema om een ​​sterke shardsleutel op te nemen. De Shard-sleutel beïnvloedt de lees- en schrijfuitvoering door te beslissen hoe MongoDB gegevens segmenteert. U kunt de Shard-sleutel niet meer wijzigen als deze eenmaal is ingesteld.

Zorg ervoor dat uw schemaplan niet afhankelijk is van geïndexeerde clusters die onbeperkt in lengte groeien. Gewoonlijk kan de beste uitvoering worden bereikt wanneer dergelijke geïndexeerde clusters minder dan 1000 componenten hebben.

Houd rekening met de limieten voor documentschattingen bij het ontwerpen van uw schema. De BSON Document Estimate-beperking is 16 MB per document. Gebruik GridFS in het geval dat u grotere rapporten nodig heeft.

Stuurprogramma's

Maak gebruik van associatie pooling. De meeste MongoDB-stuurprogramma's ondersteunen associatiepooling. Pas de grootte van de associatiepool aan uw gebruiksscenario aan, beginnend bij 110-115% van het normale aantal gelijktijdige databasevereisten.

Zorg ervoor dat uw applicaties tijdelijke schrijf- en leesfouten afhandelen tijdens de verkiezing van replicasets.

Garandeer dat uw toepassingen mislukte verzoeken afhandelen en probeer ze indien nodig opnieuw. Stuurprogramma's niet

probeer natuurlijk opnieuw mislukte verzoeken.

Gebruik exponentiële backoff-redenen voor het opnieuw proberen van databaseverzoeken.

Gebruik cursor.maxTimeMS() voor leesbewerkingen en wtimeout voor schrijfbewerkingen als u de uitvoeringsperiode voor databasebewerkingen wilt beperken.

Duurzaamheid van gegevens

Zorg ervoor dat je replicaset ten minste drie datadragende hubs bevat met w:majority compose-zorg. Er zijn drie datadragende hubs vereist voor een brede data-solide replicaset.

Gegarandeerd dat alle instanties journaling gebruiken.

Sharden

Gegarandeerd dat uw shardsleutel de belasting gelijkelijk overbrengt op uw shards.

Gebruik gerichte bewerkingen voor workloads die moeten worden geschaald met het aantal shards.

Voor MongoDB 3.6 en daarna retourneren secundairen niet langer verweesde gegevens, tenzij gebruik wordt gemaakt van leesprobleem "beschikbaar" (wat het standaard leesprobleem is voor leesbewerkingen tegen secundaire bestanden wanneer deze niet gerelateerd zijn aan causaal betrouwbare sessies).

Vanaf MongoDB 3.6 houden alle leden van de shard-replicaset chunk-metadata bij, waardoor ze wezen kunnen uitfilteren wanneer ze "beschikbaar" niet gebruiken. Als zodanig kunnen niet-gerichte of uitgezonden vragen die geen gebruik maken van "beschikbaar" veilig op elk lid worden uitgevoerd en zullen geen verweesde informatie retourneren.

Het "toegankelijke" leesprobleem kan verweesde documenten van hulpleden retourneren omdat het niet controleert op gereviseerde chunk-metadata. In elk geval, in het geval dat de teruggave van verweesde documenten onbeduidend is voor een toepassing, geeft het "beschikbare" leesprobleem de minste inactiviteit mogelijk tussen de verschillende leesproblemen.

Brokken vooraf splitsen en handmatig aanpassen bij het insluiten van uitgebreide datasets in een nieuwe niet-gehashte shardverzameling. Door vooraf te splitsen en fysiek aan te passen, kan de ingesloten stapel worden verspreid over de scherven, waardoor de uitvoering voor de startbelasting wordt uitgebreid.

Conclusie 

Controlelijstbeheer voor bediening en ontwikkeling is een cruciale stap die ontwikkelaars moeten nemen bij het gebruik van MongoDB in productie. Het zijn belangrijke overwegingen omdat ze de stroom van taken voor een project in productie verbeteren. De MongoDB-productieomgeving vereist stabiele en betrouwbare databasefuncties, omdat de database in productie echte wereldwerkgegevens opslaat. De integriteit van gegevens hangt af van de stabiliteit van de database die mogelijk wordt gemaakt door ervoor te zorgen dat aan alle items op de controlelijst voor bewerking en ontwikkeling wordt gewerkt vóór productie.