Kontrolní seznam vývoje a provozu pro MongoDB

Kontrolní seznamy provozu a vývoje MongoDB mají správcům databází pomoci vyhnout se problémům v produkčním prostředí MongoDB. Kontrolní seznam vývoje by měl řešit problémy jako...

1. Návrh schématu
2. Trvalost dat
3. Replikace
4. Pohony 
5. Sharding 

Provozní kontrolní seznam na druhé straně adresy...

1. Replikace
2. Systém souborů 
3. Sharding
4. Hardware
5. Ukládání deníků (WiredTiger Storage Engine) 
6. Konfigurace operačního systému 
7. Nasazení na cloudový hardware 
8. Monitorování
9. Zálohování a vyrovnávání zátěže

Před zahájením projektu je vhodné zapracovat na kontrolním seznamu provozu a vývoje, aby byl umožněn hladký provoz  MongoDB v produkci. Tento článek vysvětluje kontrolní seznam provozu a vývoje před nasazením MongoDB.

Kontrolní seznam operací MongoDB

Replikace

Všechny sady členů replik, které nejsou skryté, by měly být zřízeny identicky, pokud jde o disk, RAM, nastavení sítě a CPU.

Velikost protokolu by měla být správně nakonfigurována tak, aby odpovídala provozním potřebám:

• Abyste se vyhnuli nutnosti úplné opětovné synchronizace, mělo by okno aplikace repliky oplog pokrývat pravidelné prostoje a okno údržby.
• Chcete-li obnovit člena replikační sady, mělo by okno replikačního protokolu vždy pokrýt potřebnou dobu.

Produkční sada by měla obsahovat minimálně tři uzly nesoucí data, které běží s povoleným žurnálováním. Kromě toho by zápisy měly být vydávány s w:"většinový" zápis, aby byla zajištěna dostupnost a trvanlivost dat.

Nasazení by mělo obsahovat lichý počet hlasujících členů, aby se usnadnil proces hlasování, kdykoli selže primární uzel v clusteru.

Namísto používání IP adres, které mohou vyžadovat změnu konfigurace kvůli změně IP, se doporučuje používat logické názvy hostitelů DNS.

Ujistěte se, že instance mongod mají 0 nebo 1 hlas.

Všechny instance Mongod by měly být plně a obousměrně propojeny, aby byla mezi zúčastněnými uzly snadná komunikace dat.

Ukládání deníků

Toto je strategie protokolování souborů žurnálu na disku předem, která se používá k zajištění trvanlivosti dat v případě selhání. Z tohoto důvodu by měly mít všechny instance povoleno žurnálování, zejména při práci s náročnými pracovními zátěžemi.

Mějte však na paměti, že to ovlivní zesílení ve stylu snímků, protože záznamy tvořící stav databáze budou setrvávat na rozdělených svazcích.

Systém souborů

Nepoužívejte pro dbPath disky News File System (NFS). Jednotky NFS mohou mít za následek destabilizaci výkonu. Uživatelé VMware doporučují virtuální disky VMware.

Ujistěte se, že jsou diskové oddíly zarovnány s konfiguracemi RAIDON.

Pro uživatele Linux/Unix se doporučuje použití XFS. Je známo, že XFS funguje lépe s MongoDB.

Pro uživatele operačního systému Windows se doporučuje souborový systém NTFS. Měli byste se vyhnout použití jakéhokoli souborového systému FAT.

Nasazení do cloudového hardwaru

Windows Azure:Změňte hodnotu udržování TCP (tcp_keepalive_time) na 100-120. Časový limit TCP sit out of gear na nástroji pro vyrovnávání zásobníku Azure je také mírný pro chování MongoDB při sdružování asociací

Používejte MongoDB 2.6.4 nebo novější verze na rámcích s úložištěm s vysokou latencí, jako je Windows Azure, protože tyto verze obsahují vylepšení spouštění pro tyto rámce.

Sharding

Umístěte své konfigurační servery na vyhrazený hardware pro ideální provádění v rozsáhlých clusterech.

Ujistěte se, že hardware má dostatek paměti RAM pro úplné uložení informačních záznamů v paměti a vyhrazené úložiště.

Nasaďte směrovače mongos v souladu s pokyny pro nastavení generace.

Synchronizujte hodiny na všech součástech vašeho sdíleného clusteru pomocí NTP.

Zajistěte plnou obousměrnou síť mezi mongos, mongod a konfiguračními servery.

Použijte CNAME k rozpoznání vašich konfiguračních serverů v clusteru, abyste mohli přejmenovat a přečíslovat své konfigurační servery bez prostojů.

Monitorování

K zobrazení klíčových databázových metrik a nastavení alarmů můžete využít nástroje jako MongoDB Cloud Manager, ClusterControl nebo jiný monitorovací rámec. Zahrnout upozornění pro metriky:

• Fronty
• Okno protokolu replikace
• Tvrzení
• Chyby stránky
• Prodleva replikace

Sledujte hardwarové metriky vašich serverů. Věnujte pozornost zejména dostupnému prostoru na disku, využití disku, CPU

Hardware

Pro ideální výkon použijte disky RAID10 a SSD.

SAN a virtualizace:

Ujistěte se, že každá z instancí mongodu má zajištěný IOPS pro svou cestu dbPath nebo má svůj nárokovaný fyzický disk nebo LUN.

Při běhu ve virtuálních prostředích se vyhněte dynamickým zvýrazněním paměti, jako je otékání paměti.

Nenastavujte všechny kopírovací sady na stejnou síť SAN, protože SAN může být jediným bodem zklamání.

Vyrovnávání zátěže

Navrhněte nástroje pro vyrovnávání zatížení tak, aby umožňovaly „pevné relace“ nebo „spřažení s klienty“ s adekvátním časovým limitem pro existující připojení.

Nevkládejte mezi komponenty MongoDB clusteru nebo sady replik nástroje pro vyrovnávání zatížení.

Zálohy

Naplánujte si občasné testy procesu zálohování a obnovy, abyste měli po ruce ukazatele času a potvrdili jeho užitečnost.

Konfigurace operačního systému

Windows

Zvažte deaktivaci upgradů systému NTFS s „časem posledního přístupu“.

Formátujte disky NTFS pomocí výchozí velikosti alokační jednotky 4096 bajtů.

Linux

Vypněte velké průhledné stránky.

Upravte nastavení čtecí hlavy kostek, kde jsou uloženy soubory databáze. Předčítání úložiště WiredTiger by mělo být nastaveno mezi 8 a 32.

Pokud používáte laděný na RHEL / CentOS, musíte upravit svůj upravený profil. Mnoho vyladěných profilů dodávaných s RHEL / CentOS může nepříznivě ovlivnit provádění se svými výchozími nastaveními. Přizpůsobte si vybraný vyladěný profil na:

Zakázat přímočaré velké stránky.

Nastavte předčítání mezi 8 a 32 v každém případě řazení médií podle kapacity.

Využijte plánovače disků noop nebo deadline pro SSD disky.

Použijte plánovač disků noop pro virtualizované jednotky v hostovaných virtuálních počítačích.

Zakažte NUMA nebo nastavte vm.zone_reclaim_mode na 0 a spouštějte výskyty mongodů s prokládáním uzlů.

Upravte hodnoty ulimit na vašem hardwaru tak, aby odpovídaly vašemu případu použití. V případě, že pod stejným klientem běží různé výskyty mongod nebo mongos, upravte hodnoty ulimit podobným způsobem.

Navrhněte adekvátní popisovače záznamů (fs.file-max), část pid omezení (kernel.pid_max), maximální vlákno na proces (kernel.threads-max) a maximální počet oblastí obrysu paměti na proces (vm.max_map_count) pro vaše odeslání. Pro rozsáhlé rámce představují následující hodnoty skvělý výchozí bod:

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

Ujistěte se, že váš rámec má nakonfigurovaný odkládací prostor.

Odkažte se na dokumentaci svého operačního systému pro body zájmu o správné velikosti.

 Ujistěte se, že je přesně nastaveno výchozí systémové udržování TCP. Hodnota 300 často poskytuje vynikající výkon pro sady replik a sdílené clustery.

Kontrolní seznam vývoje MongoDB

Replikace

Využijte lichý počet hlasujících osob, abyste zaručili, že volby budou efektivně pokračovat. Budete mít až 7 hlasujících jednotlivců. V případě, že máte sudý počet hlasujících jednotlivců a omezení, jako je cena, neumožňují zahrnutí dalšího sekundárního člena jako hlasujícího člena, budete moci zahrnout arbitra, který zaručí lichý počet hlasů.

Zaručte, že vaše sekundární stránky zůstanou aktuální pomocí monitorovacích nástrojů a uvedením vhodného problému se zápisem.

Nepoužívejte pomocná čtení ke škálování celkové propustnosti čtení.

Návrh schématu

Data v MongoDB obsahují dynamický vzor. Sbírky nepodporují strukturu sestav. To podporuje iterativní zlepšování a polymorfismus. V každém případě sbírky často obsahují záznamy s mimořádně homogenní strukturou.

Určete sadu kolekcí, které budete právě vyžadovat, a indexy požadované pro zálohování vašich dotazů. Se speciálním případem indexu _id musíte vytvořit všechny indexy výslovně:MongoDB přirozeně nevytváří žádné jiné indexy než _id.

Zaručte, že váš plán schématu bude podporovat vaše řazení nasazení:v případě, že plánujete využít sdílené clustery pro horizontální škálování, naplánujte své schéma tak, aby zahrnovalo silný shard klíč. Shard key ovlivňuje provádění čtení a zápisu tím, že rozhoduje, jak MongoDB segmentuje data. Jakmile je hardwarový klíč nastaven, nemůžete jej změnit.

Ujistěte se, že váš plán schématu nezávisí na indexovaných klastrech, jejichž délka bez omezení narůstá. Obvykle lze nejlepšího provedení dosáhnout, když takové indexované clustery mají méně než 1000 komponent.

Při navrhování schématu vezměte v úvahu limity odhadu dokumentu. Omezení BSON Document Estimate je 16 MB na dokument. V případě, že požadujete větší reporty, použijte GridFS.

Ovladače

Využijte sdružování přidružení. Většina ovladačů MongoDB podporuje sdružování asociací. Změňte velikost asociačního fondu tak, aby vyhovovala vašemu případu použití, počínaje 110–115 % běžného počtu souběžných požadavků na databázi.

Ujistěte se, že vaše aplikace zvládají dočasné chyby při zápisu a čtení během voleb sady replik.

Zaručte, že vaše aplikace zpracují neúspěšné požadavky, a v případě potřeby je zkuste znovu. Ovladače ne

přirozeně opakujte neúspěšné požadavky.

Využijte zdůvodnění exponenciálního ústupu pro opakované pokusy o databázový požadavek.

Použijte kurzor.maxTimeMS() pro čtení a wtimeout pro zápis v případě, že chcete omezit dobu provádění databázových operací.

Trvalost dat

Ujistěte se, že vaše sada replik obsahuje alespoň tři rozbočovače nesoucí data se zájmem o w:majority compose. Pro solidnost dat široké sady replik jsou vyžadovány tři rozbočovače dat.

Zaručte, že všechny instance využívají žurnálování.

Sharding

Zaručte, že váš úlomkový klíč přenese zatížení rovnoměrně na vaše úlomky.

Využijte cílené operace pro úlohy, které se škálovaly podle počtu fragmentů.

Pro MongoDB 3.6 a pozdější sekundární soubory již nevracejí osiřelá data, pokud nevyužívají problém čtení "k dispozici" (což je výchozí problém čtení pro čtení proti sekundárním souborům, pokud nesouvisí s kauzálně spolehlivými relacemi).

Počínaje MongoDB 3.6 všichni členové sady replik útržků uchovávají metadata kousku, což jim umožňuje odfiltrovat sirotky, když nevyužívají „dostupné“. Necílené nebo vysílané dotazy, které nevyužívají „dostupné“, lze tedy bezpečně spustit u kteréhokoli člena a nevrátí osiřelé informace.

Otázka "přístupného" čtení může vrátit osiřelé dokumenty od pomocných členů, protože nekontroluje přepracovaná metadata bloku. V každém případě, v případě, že vrácení osiřelých dokumentů je pro aplikaci bezvýznamné, problém "dostupného" čtení poskytuje mezi různými problémy čtení nejmenší možnou nečinnost čtení.

Předrozdělte a ručně upravte bloky při vkládání rozsáhlých datových sad do nové nehašované sdílené kolekce. Předrozdělení a fyzické nastavení umožňuje rozmístění balíčku vložení mezi úlomky, čímž se rozšíří provádění pro počáteční zatížení.

Závěr 

Správa kontrolního seznamu provozu a vývoje je zásadním krokem, který musí vývojáři začlenit při používání MongoDB v produkci. Jsou to klíčové aspekty, protože zlepšují tok úkolů pro projekt ve výrobě. Produkční prostředí MongoDB vyžaduje stabilní a spolehlivé databázové funkce, protože produkční databáze uchovává reálná data. Integrita dat závisí na stabilitě databáze, která je umožněna tím, že je zajištěno, že všechny položky na kontrolním seznamu provozu a vývoje jsou zpracovány před výrobou.