Pokud hostujete svůj cluster MongoDB v regionu Amazon AWS US-East, byl poslední měsíc poměrně zajímavý – dva výpadky během čtyř týdnů otestovaly provozní připravenost vašeho cloudu nasazení. Zatímco píšu tento blogový příspěvek, region Sao Paulo má také problémy s připojením. Překvapivé množství produkčních databází nepřežilo výpadek AWS. Měli jsme příležitost mluvit s řadou zákazníků MongoDB na AWS, abychom pochopili, jak výpadek ovlivnil jejich nasazení. Provedl jsem rychlý průzkum postižených jednotlivců a zde jsou čtyři hlavní důvody, proč týmy zažily výpadky:
-
Spuštění samostatné instance vs. sada replik
Pokud provozujete produkční server MongoDB, neexistuje žádná omluva pro spouštění samostatné instance nebo sady replik. Vytvořte sadu replik, abyste mohli mít sekundární k převzetí služeb při selhání v případě primárního selhání.
-
Nedistribuce replik v zónách dostupnosti
Zajistěte, abyste své repliky distribuovali v různých zónách dostupnosti v regionu. Tímto způsobem, pokud dojde k výpadku jednoho AZ, jak se to stalo dvakrát tento měsíc, vaše zbývající servery převezmou kontrolu a budete mít funkční cluster. Pokud má váš region pouze dva AZ, umístěte svého arbitra do jiného regionu. To vám však nepomůže, pokud celý region padne. Pokud chcete přežít selhání celého regionu AWS, budete muset svou sadu replik distribuovat do různých oblastí.
-
Nedistribuce vašich front-endů nebo aplikačních serverů mezi zóny dostupnosti
Ujistěte se, že svá rozhraní distribuujete do různých zón dostupnosti. Nemá smysl mít databázi v provozu, pokud je váš front-end mimo provoz. Pokud máte problémy s náklady, můžete v každém AZ udržovat aktuální front-end „zastavený“, který můžete v případě potřeby zapnout. Další možností je mít menší front-endy.
-
Připojte se k sadě replik vs. jeden server ve vašem připojovacím řetězci
Ujistěte se, že se místo jednoho serveru připojujete k sadě replik. Syntaxe se u různých ovladačů liší, ale zkontrolujte dokumentaci ovladače, abyste se ujistili, že používáte správnou syntaxi pro připojení k sadě replik namísto jednoho serveru. Tímto způsobem, pokud dojde k převzetí služeb při selhání, ovladač MongoDB udělá správnou věc a připojí se k novému primárnímu.
V ScaleGrid automatizujeme všechny provozní aspekty vašeho nasazení, abyste se mohli soustředit na svou aplikaci a nestarat se o operace. Když vytvoříte sadu replik MongoDB pomocí ScaleGrid, automaticky distribuujeme repliky napříč zónami dostupnosti. Díky této distribuci byli všichni naši zákazníci schopni bezpečně procházet problémem s výpadky AWS. Pokud máte zájem o podrobnější informace o provozních aspektech MongoDB, můžete si přečíst můj dřívější podrobný blogový příspěvek – 10 otázek, které je třeba položit a odpovědět na ně při hostování MongoDB na AWS