Úvahy o správě MongoDB

Níže je uveden výňatek z našeho whitepaperu „MongoDB Management and Automation with ClusterControl“, který si můžete zdarma stáhnout.

Úvahy o správě MongoDB

Vestavěná redundance

Klíčovým rysem MongoDB je jeho vestavěná redundance ve formě replikace. Pokud máte dva nebo více datových uzlů, lze je nakonfigurovat jako sadu replik, ve které jsou všechna data zapsaná do primárního uzlu replikována téměř v reálném čase do sekundárních uzlů,

zajištění více kopií dat. V případě primárního převzetí služeb při selhání provedou zbývající uzly v sadě replik volbu a povýší vítěze na primárního, což je proces, který obvykle trvá 2–3 sekundy a zápisy do sady replik mohou pokračovat. MongoDB také používá žurnál pro rychlejší a bezpečnější zápisy na server nebo sadu replik a také využívá metodu „zápisu“, pomocí které se
konfiguruje úroveň redundance zápisu.

Chcete-li ručně nasadit sadu replik, postupujte takto:

1. Přidělte jednoho fyzického nebo virtuálního hostitele pro každý databázový uzel a nainstalujte si na plochu klienta příkazového řádku MongoDB. Pro konfiguraci redundantní sady replik jsou vyžadovány minimálně tři uzly, z nichž alespoň dva budou datové uzly. Jeden uzel v sadě replik může být nakonfigurován jako arbitr:jedná se o proces mongod konfigurovaný pouze pro vytvoření kvora poskytnutím hlasu při volbě primárního, je-li to vyžadováno. Data nejsou replikována do arbitrážních procesů.
2. Nainstalujte MongoDB na každý uzel. Některé distribuce Linuxu zahrnují MongoDB Community Edition, ale uvědomte si, že nemusí obsahovat nejnovější verze. MongoDB Enterprise je k dispozici pouze stažením z webu MongoDB. Podobná funkce jako MongoDB Enterprise je k dispozici také prostřednictvím serveru Percona pro MongoDB, což je náhrada za MongoDB Enterprise nebo Community Edition.
3. Nakonfigurujte jednotlivé konfigurační soubory mongod.conf pro vaši sadu replik pomocí „parametru replikace“. Pokud budete pro zabezpečení používat soubor klíče, nakonfigurujte jej také nyní. Všimněte si, že použití zabezpečení souborů klíčů také umožňuje autentizaci na základě rolí, takže budete také muset přidat uživatele a role, abyste mohli používat servery. Restartujte proces mongod na každém serveru.
4. Zajistěte konektivitu mezi uzly. Musíte zajistit, aby uzly sady replik MongoDB mohly mezi sebou komunikovat na portu 27017 a také, aby se vaši klienti mohli připojit ke každému z uzlů sady replik na stejném portu.
5. Pomocí klienta příkazového řádku MongoDB se připojte k jednomu ze serverů a spusťte rs.initiate() pro inicializaci vaší sady replik a poté rs.add() pro každý další uzel. rs.conf() lze použít k zobrazení konfigurace.

I když tyto kroky nejsou tak složité jako nasazení a konfigurace shardovaného clusteru MongoDB nebo sdílení relační databáze, mohou být náročné a náchylné k chybám, zejména ve větších prostředích.

Škálovatelnost

MongoDB je často označován jako databázový software „web scale“ kvůli jeho schopnosti horizontálního škálování. Stejně jako relační databáze je možné MongoDB vertikálně škálovat, jednoduše upgradováním fyzického hostitele, na kterém je umístěno více jader CPU, více RAM, rychlejší disky nebo dokonce vyšší rychlost sběrnice. Vertikální škálování má však své limity, a to jak z hlediska poměru nákladů a přínosů a klesající návratnosti, tak technických omezení. K vyřešení tohoto problému má MongoDB funkci „automatického shardingu“, která umožňuje rozdělit databáze mezi mnoho hostitelů (nebo sady replik, kvůli redundanci). I když je sharding možný i na relačních platformách, pokud není navržen pro vytvoření databáze, vyžaduje to zásadní přepracování schématu a aplikace a také přepracování klientské aplikace, což činí tento proces zdlouhavým, časově náročným a náchylným k chybám.

Sharding MongoDB funguje tak, že zavádí proces routeru, pomocí kterého se klienti připojují ke sdílenému clusteru, a konfigurační servery, které ukládají metadata clusteru, umístění v clusteru každého dokumentu. Když klient odešle dotaz procesu routeru, nejprve se odkáže na konfigurační servery, aby získal umístění dokumentů, a poté získá výsledky dotazu přímo od jednotlivých serverů nebo
sady replik (útržky). Sdílení se provádí pro každou kolekci.

Pro účely výkonu je zde kriticky důležitý parametr „shard key“, indexované pole nebo složené pole, které existuje v každém dokumentu v kolekci. Je to to, co definuje distribuci zápisu mezi fragmenty kolekce. Špatně zvolený klíč může mít velmi nepříznivý vliv na výkon. Například útržkový klíč založený čistě na časové řadě může vést k tomu, že všechny zápisy budou směřovat do jednoho uzlu po dlouhou dobu. Hashovaný shard klíč však může při rovnoměrném rozložení zápisů mezi fragmenty ovlivnit výkon čtení, protože výsledná sada je načítána z mnoha uzlů.

Rozhodci

MongoDB arbitr je proces mongod, který byl nakonfigurován tak, aby nefungoval jako datový uzel, ale aby poskytoval pouze funkci hlasování, když má být zvolena replika primární sady, aby přerušil vazby a chránil před rozděleným hlasováním. Rozhodce se nemůže stát primárním, protože nedrží kopii dat ani nepřijímá zápisy. I když je možné mít více než jednoho arbitra v sadě replik, obecně se to nedoporučuje.

Členové sady replik se zpožděním

Členové sady odložených replik přidávají další úroveň redundance a udržují stav, který je o pevný počet sekund za primární. Vzhledem k tomu, že zpožděné členy jsou „běžná záloha“ nebo běžící „historický“ snímek datové sady, mohou pomoci při zotavení z různých typů lidských chyb.

Zpoždění členové jsou „skryté“ členy sady replik, neviditelné pro klientské aplikace, a proto je nelze přímo dotazovat. Během normálního provozu se také nemusí stát primárními a je nutné je ručně překonfigurovat pro případ, že se mají použít k zotavení z chyby.

Zálohy

Zálohování sady replik nebo sdíleného clusteru se provádí pomocí nástroje příkazového řádku „mongodump“. Při použití s ​​parametrem --oplog to vytvoří výpis databáze, který obsahuje oplog, aby se vytvořil snímek stavu instance mongoda v určitém okamžiku. Pomocí mongorestore s parametrem --replayOplog pak můžete plně obnovit stav dat v době, kdy byla záloha dokončena, a vyhnout se tak nekonzistentnosti.

Pro pokročilejší požadavky na zálohování je k dispozici nástroj třetí strany nazvaný „mongodbconsistent-backup“ – také založený na příkazovém řádku –, který poskytuje plně konzistentní zálohy sdílených clusterů, což je složitý postup vzhledem k tomu, že sdílené databáze jsou distribuovány mezi více hostitelů.

Monitorování

Pro monitorování MongoDB je na trhu k dispozici řada komerčních nástrojů, oficiálních i neoficiálních. Tyto nástroje jsou obecně nástroji pro správu jednotlivých produktů, které se zaměřují výhradně na MongoDB. Mnohé se zaměřují pouze na určité specifické aspekty, jako je správa kolekcí ve stávající architektuře MongoDB nebo na zálohování nebo na nasazení. Bez řádného plánování to může vést k situaci, kdy je nutné nasadit a spravovat ve vašem prostředí velké množství dalších nástrojů.

Nástroje příkazového řádku poskytované s MongoDB, „mongotop“ a „mongostat“ mohou poskytnout podrobný pohled na výkon vašeho prostředí a lze je použít k diagnostice problémů. Kromě toho může klient příkazového řádku MongoDB „mongo“ také spouštět „rs.status()“ – nebo ve sdíleném clusteru „sh.status() – pro zobrazení stavu sad replik nebo clusterů a jejich členských hostitelů. Příkaz „db.stats()“ vrací dokument, který se zabývá využitím úložiště a objemy dat a jsou ekvivalenty pro kolekce a další volání pro přístup k mnoha interním metrikám.

Souhrn

Toto byl stručný souhrn úvah o správě MongoDB. I na tak vysoké úrovni by však mělo být okamžitě zřejmé, že i když je možné spravovat sadu replik nebo sdílený cluster z příkazového řádku pomocí dostupných nástrojů, není to škálovatelné v prostředí s mnoha sadami replik nebo s velkou produkcí. střepový shluk. Ve středních až velkých prostředích obsahujících mnoho hostitelů
a databází se rychle stane nemožné spravovat vše pomocí nástrojů a skriptů příkazového řádku. Zatímco interní nástroje a skripty mohou být vyvíjeny pro nasazení a údržbu prostředí, přidává to zátěž na správu nového vývoje, systémů kontroly revizí a procesů. Jednoduchý upgrade databázového serveru se může stát složitým procesem, pokud jsou pro podporu nových databázových
verzí serveru vyžadovány změny nástrojů.

Jak ale bez interních nástrojů a skriptů automatizujeme a spravujeme clustery MongoDB? Stáhněte si bílou knihu a zjistěte, jak na to!