Nasazení MongoDB v produkčním prostředí může skutečně fungovat, pouze pokud je dodržen správný vzor nasazení. Nasazení sady replik v jediném hostiteli nezaručuje vysokou dostupnost dat. Práce s velkými daty vyžaduje rozsáhlý výzkum a optimální implementace, a to buď kombinací dostupných možností, nebo výběrem té s nejvyššími slibnými přínosy.
Vzory nasazení pro MongoDB zahrnují:
- Tříčlenné sady replik
- Sady replik distribuované ve dvou nebo více datových centrech.
Tři členské sady replik
Replikace je škálovací strategie pro MongoDB, která zvyšuje vysokou dostupnost dat. Sada replik obsahuje:
- Primární uzel:zodpovědný za všechny operace propustnosti zápisu a lze z něj také číst.
- Sekundární uzly:Mohou být použity pouze pro operace čtení, ale mohou být zvoleny jako primární v případě, že stávající selže. Aktualizace dat získávají z oplogu generovaného primárním členem sady.
- Rozhodce. Používá se k usnadnění volby primárního v případě, že existuje sudý počet členů sady replik. Nehostuje žádnou kopii dat.
Výhod sady replik lze dosáhnout pouze s minimálním počtem tří členů s následující architekturou:
Primární-Sekundární-Sekundární
Toto je nejvíce doporučeno, protože má větší odolnost proti chybám a řeší omezení spojená s přidáním třetího členu nesoucího data, jako je cena.
Toto nasazení bude kromě primárních dat vždy poskytovat dvě úplné kopie, čímž zajistí vysokou dostupnost. Selhání primární volby spustí sadu replik k výběru nové primární volby a provoz bude pokračovat jako obvykle. Pokud se starý primární člen stane živým, bude zařazen do kategorie sekundárního člena.
Během volebního procesu si členové signalizují pomocí tlukotu srdce a během této doby neprobíhají žádné operace zápisu
Po volebním procesu předpokládáme, že architektura bude reformována takto:
Primární-sekundární-arbitr
To zajišťuje, že sada replik zůstane dostupná i v případě, že primární nebo sekundární není k dispozici, a to usnadněním procesu volby mezi sekundární a primární. Arbitři nenesou žádnou kopii dat, a proto vyžadují méně prostředků na správu.
Omezením tohoto nasazení je; žádná redundance, protože existují pouze dva datové členy:primární a sekundární. Výsledkem je nižší odolnost proti chybám.
Tolerance chyb by měla být schopna zajistit:
- Dostupnost zápisu: Většina hlasujících členů sady replik je potřeba k udržení nebo volbě primárního orgánu, který je odpovědný za operace zápisu.
- Redundance dat:zápis může být potvrzen více členy, aby se zabránilo vrácení zpět
Konfigurace Primary-Secondary-Arbiter podporuje aspekt dostupnosti zápisu pouze tak, že pokud je jeden člen sady nedostupný, primární může být stále udržován.
Pokud se však sekundární člen stane nedostupným, nepodporování druhého aspektu má za následek určité provozní důsledky:
- Nebude probíhat žádná aktivní replikace, zejména pokud je sekundární stránka offline po dlouhou dobu. Když je sekundární prvek offline příliš dlouho, může vypadnout z oplogu a jeden jej při restartu donutí znovu synchronizovat.
- Redundance dat bude sabotována, takže operace zápisu bude potvrzena pouze aktuálním primárním prvkem.
- Možnost Většina s obavami nebude poskytovat nejnovější data připojeným aplikacím a interním procesům. To je případ, kdy vaše konfigurace očekává, že zápisy budou vyžadovat většinové potvrzení, a proto budou zablokovány, dokud nebude dostupná většina členů s daty.
- Migrace bloků mezi fragmenty bude také ohrožena, pokud je sada replik součástí sdíleného clusteru.
- Tlak na mezipaměť úložiště WiredTiger, pokud dojde k vrácení zpět a většinový bod potvrzení nelze posunout.
Abyste se těmto důsledkům vyhnuli, můžete se rozhodnout pro konfiguraci Primární – Sekundární – Sekundární, protože zvyšuje odolnost proti chybám.
Poznámka:Tolerance chyb se neprojevuje pouze v případě selhání, ale také některé systémové operace, jako je aktualizace softwaru a běžná údržba, mohou způsobit, že člen bude krátkodobě nedostupný.
Sady replik distribuované mezi dvě nebo více datových center
Vysokou dostupnost lze povýšit na jinou úroveň distribucí členů sady replik napříč geograficky odlišnými datovými centry. Tento přístup kromě zajištění vysoké odolnosti proti chybám v případě nedostupnosti datového centra zvýší redundanci.
Pokud jsou všichni členové umístěni v jediném datovém centru, je sada replik náchylná k poruchám datového centra, jako jsou přechodné síťové jevy a výpadky napájení.
Je vhodné ponechat alespoň jednoho člena v alternativním datovém centru, použijte lichý počet datových center a vyberte rozložení členů, které nabídne většinu pro zvolení nebo alespoň poskytne kopii dat v případě selhání.
Konfigurace by měla zajistit, že v případě výpadku některého datového centra zůstane sada replik zapisovatelná, protože zbývající členové mohou uspořádat volby.
Distribuujte svá data alespoň do tří datových center.
Členové mohou být omezeni na zdroje nebo mít síťová omezení, takže nejsou vhodní stát se primárními v případě převzetí služeb při selhání. Tyto členy můžete nakonfigurovat tak, aby se nestali primárními tím, že jim dáte prioritu 0.
Členové v datovém centru mohou mít vyšší prioritu než jiná datová centra, aby jim byla dána priorita hlasování, takže si mohou zvolit primární místo před členy v jiných datových centrech.
Všichni členové v sadě replik by měli být schopni spolu komunikovat.
Závěr
Výhody replikace lze povýšit na slibnější stav distribucí členů do několika datových center. Kromě zajištění redundance dat to podstatně zvyšuje odolnost proti chybám. Členové sady replik při distribuci mezi dvě nebo více datových center poskytují výhody oproti jedinému datovému centru, jako například:
Pokud dojde k výpadku jednoho z datových center, data jsou stále dostupná pro čtení na rozdíl od distribuce v jednom datovém centru.
Operace zápisu lze stále potvrdit, kdykoli dojde k výpadku datového centra s menšinovými členy.
Operace čtení mohou být stále možné, pokud datové centrum s většinově hlasujícími členy na rozdíl od případu jediného datového centra upadne.