Follower clustery jsou funkcí ScaleGrid, která vám umožňuje synchronizovat dva nezávislé databázové systémy (stejného typu). Na rozdíl od klonování nebo replikace vám to umožňuje udržovat aktivní kopii vašich produkčních dat v určitém okamžiku. Tento extra cluster, známý jako sledující cluster, lze využít pro různé případy použití, včetně analýzy, optimalizace a testování výkonu vaší aplikace pro MongoDB, MySQL a PostgreSQL. V tomto příspěvku na blogu se budeme zabývat třemi nejlepšími scénáři pro využití clusterů sledujících pro vaši aplikaci.
Jak se klastru sledujících liší od replikace?
Na rozdíl od statického klonu se tato data importují podle nastaveného plánu, takže váš cluster sledujících je vždy synchronizován s vaším produkčním clusterem. Zde je několik kritických způsobů, jak se liší od replikace:
- Můžete ovládat, jak často se cílový systém synchronizuje ze zdroje – jednou týdně, jednou denně nebo ještě méně často. To pomáhá snížit zatížení zdrojového systému.
- Protože se jedná o dva nezávislé systémy, máte mnohem větší flexibilitu ohledně synchronizovaných dat. Můžete mít různá uživatelská pověření a dokonce odstranit některá data z cíle na základě bezpečnostních požadavků (poznámka:To vyžaduje skriptování na straně uživatele – nejde o integrovanou funkci clusterů sledujících).
- Systém „sledovník“ je zapisovatelný, takže jej můžete použít jako pracovní prostředí pro testování změn vaší aplikace. To není něco, co můžete dělat na replikovaném uzlu.
Poznámka:ScaleGrid implementuje clustery sledujících pomocí snímků úložiště. Není k dispozici pro naše nabídky in-memory databází, jako je hosting pro Redis™*.
1. Nastavení vývoje/testu databáze
Byli jsme u toho všichni – údajně dobře otestovaný kus kódu je nasazen ve výrobě a pak se rozpoutá peklo. Výrobní pracovní postupy selhávají nebo jsou tak pomalé, že jsou v podstatě nepoužitelné. Inženýři jsou probuzeni z postelí, aby zahájili plnohodnotnou hasičskou operaci. Po hromadě bezesných nocí později se objeví tato obávaná hlavní příčina.
Aplikace se v produkčním a inženýrském nastavení chová odlišně.
Jinými slovy, testovali jsme to na „testovacích datech“. Což, jak se ukázalo, nebylo nic jako výrobní data. Vůbec.
Zřejmým způsobem, jak se této situaci vyhnout, je spustit testy na vašich produkčních datech. Samozřejmě ne skutečná produkce – to bude koketování s katastrofou. Na klonované kopii produkčních dat. Zatímco obavy o soukromí a zabezpečení dat to v mnoha scénářích znemožňují, pokud to požadavky na soukromí dovolí, je to nejlepší řešení. Už se nemusíme spoléhat na inženýry, kteří vygenerují vhodné datové sady – pokud to předá testovací data, bude to předávat produkční data.
To znamená, dokud se testovací data natolik nesynchronizují s produkcí, že už to není dobrá aproximace. A jsme zpět na začátku.
To je místo, kde nastupují seskupení následovníků.
Pomocí klastrů sledujících můžete pravidelně importovat data z produkční databáze do dev/test databáze. A protože se celý import provádí pomocí snímků úložiště, nikoli logického výpisu, proces je téměř okamžitý. Své importy můžete naplánovat jednou za 24 hodin, jednou týdně nebo podle frekvence, která vyhovuje vašemu konkrétnímu scénáři.
S vašimi vývojovými a QA clustery nastavenými tak, aby následovaly produkční cluster, můžete být v klidu. Pokud vaše aplikace projde testovací datovou sadou, je rozhodně vhodná k nasazení do produkce!
2. Analýza dat
Pokud jste pracovali jako DBA, pravděpodobně jste se svým týmem hovořili o tom, že se výkon systému v určitých časech „záhadně“ zpomaluje. Ve většině případů se ukáže, že viníkem je analytická úloha, která přistupuje k velkým množstvím dat a končí zpomalením celého systému.
Jako prodejce DBaaS jsme tuto konverzaci s našimi zákazníky vedli několikrát. Zde jsou dvě možnosti, které obvykle navrhujeme:
- Pokud je úloha analýzy spuštěna na primárním/hlavním serveru, přesuňte ji na sekundární/replikovaný server.
- Pokud analytická úloha již běží na sekundárním uzlu a snížení výkonu je nepřijatelné, doporučujeme přesunout úlohy do vyhrazeného analytického clusteru.
Pomocí naší funkce clusteru sledujících je velmi snadné udržovat analytický cluster aktuální se skutečnými produkčními údaji. Můžete vytvořit plán sledujících, abyste synchronizovali nejnovější data z produkce těsně předtím, než se spustí vaše analytická úloha.
Nejlepší část? Synchronizace sledujících neprovádí žádné operace na úrovni databáze – pouze obnovuje nejnovější snímek! Na váš produkční cluster to tedy nemá žádný dopad.
3. Hlášení
Dalším běžným případem použití, kdy naši zákazníci používají funkci clusterů sledujících, je generování přehledů. Procesy vytváření sestav obvykle neprobíhají často, ale přistupují k velkému množství dat a zabírají většinu prostředků databázového clusteru. Pokud je snížení výkonu nepřijatelné, doporučujeme našim zákazníkům přesunout vytížení sestav do nového clusteru.
Vzhledem k tomu, že operace vytváření přehledů nejsou časté, mnoho našich zákazníků dává přednost využití naší funkce pozastavení/obnovení k „pozastavení“ clusterů přehledů, když se nepoužívají. To pomáhá výrazně ušetřit náklady na infrastrukturu. Klastry sestav jsou obvykle také mnohem „menší“ (méně CPU/RAM), což pomáhá snížit náklady.
Po vytvoření clusteru sledujících z našeho uživatelského rozhraní můžete tento pracovní postup zautomatizovat:
- K obnovení clusteru použijte naše API pro obnovení.
- Počkejte, až bude cluster opět spuštěn (k tomuto účelu můžete použít rozhraní API pro získání stavu).
- Je-li to nutné, spusťte zálohování na produkčním clusteru (obvykle, pokud jsou ve vašem produkčním clusteru naplánovány pravidelné zálohy, můžete tento krok přeskočit. Pokud však chcete, aby vaše sestavy běžely na nejnovějších datech, je to nezbytné).
- Počkejte na dokončení zálohování.
- Spustit úlohu synchronizace u sledujícího – tím se najde nejnovější snímek ve zdrojovém clusteru a obnoví se do cíle.
- Počkejte na dokončení úlohy synchronizace.
- Spusťte své úlohy vytváření přehledů.
- Pomocí našeho rozhraní API pro pozastavení můžete cluster pozastavit do další úlohy vytváření sestav!
Myslíte si, že clustery sledujících jsou vhodné pro váš konkrétní případ uživatele? Vše o tom, jak nasadit a spravovat sledovací clustery pro MongoDB, MySQL a PostgreSQL, se můžete dozvědět v našich dokumentech nápovědy!
Pokud si nejste jisti, zda jsou clustery sledujících tím správným řešením pro váš případ použití, zanechte komentář nebo nás kontaktujte na adrese [email protected] – my rádi prodiskutujeme, která funkce nejlépe vyhovuje vašim požadavkům.
