Följarkluster är en ScaleGrid-funktion som låter dig hålla två oberoende databassystem (av samma typ) synkroniserade. Till skillnad från kloning eller replikering tillåter detta dig att underhålla en aktiv kopia av din produktionsdata vid tidpunkten. Detta extra kluster, känt som ett follower-kluster, kan utnyttjas för flera användningsfall, inklusive för att analysera, optimera och testa din applikationsprestanda för MongoDB, MySQL och PostgreSQL. I det här blogginlägget kommer vi att täcka de tre bästa scenarierna för att dra nytta av följarkluster för din applikation.
Hur skiljer sig följarkluster från replikering?
Till skillnad från en statisk klon importeras denna data enligt ett fastställt schema så att ditt efterföljarkluster alltid är synkroniserat med ditt produktionskluster. Här är några viktiga sätt på vilka det skiljer sig från replikering:
- Du kan styra hur ofta destinationssystemet synkroniserar från källan – en gång i veckan, en gång om dagen eller till och med mer sällan. Detta hjälper till att minska belastningen på källsystemet.
- Eftersom de är två oberoende system har du mycket mer flexibilitet över data som synkroniseras. Du kan ha olika användaruppgifter och till och med ta bort vissa data från destinationen baserat på säkerhetskrav (obs! Detta kräver skript på användarsidan – det är inte en inbyggd funktion i följarkluster).
- Följersystemet är skrivbart, så du kan använda det som en iscensättningsmiljö för att testa dina programändringar. Detta är inget du kan göra på en repliknod.
Obs:ScaleGrid implementerar följarkluster med lagringsögonblicksbilder. Det är inte tillgängligt för våra databaserbjudanden i minnet som värd för Redis™*.
1. Databasutvecklare/testinställningar
Vi har alla varit där – en förment vältestad kodbit distribueras i produktionen och sedan brakar helvetet löst. Produktionsarbetsflöden misslyckas, eller är så långsamma att de i princip är oanvändbara. Ingenjörer väcks från sina sängar för att starta en fullblåst brandbekämpningsoperation. Ett gäng sömnlösa nätter senare dyker den fruktade grundorsaken upp.
Applikationen beter sig annorlunda på produktions- och tekniska inställningar.
Med andra ord testade vi det på "testdata". Vilket, som det visar sig, inte liknade produktionsdata. Överhuvudtaget.
Det självklara sättet att undvika denna situation är att köra tester på din produktionsdata. Inte den faktiska produktionen så klart – det blir att flirta med katastrof. På en klonad kopia av produktionsdata. Även om oro kring integritet och datasäkerhet gör detta omöjligt i många scenarier, om integritetskraven tillåter, är detta den bästa lösningen. Vi behöver inte längre förlita oss på att ingenjörer genererar lämpliga datamängder – om den skickar testdata vidare kommer den att vidarebefordra produktionsdata.
Det vill säga tills testdata faller så långt ur synk med produktionen att det inte längre är en bra uppskattning. Och vi är tillbaka på ruta ett.
Det är här följarkluster kommer in.
Genom att använda följarkluster kan du periodiskt importera data från din produktionsdatabas till dev/test-databasen. Och eftersom hela importen utförs med lagringsögonblicksbilder, snarare än en logisk dump, är processen nästan omedelbar. Du kan schemalägga dina importer en gång var 24:e timme, en gång i veckan eller vilken frekvens som passar just ditt scenario.
Med dina utvecklings- och QA-kluster inställda på att följa produktionsklustret kan du vara lugn. Om din applikation förmedlar testdatauppsättningen är den definitivt lämplig att distribuera i produktion!
2. Dataanalys
Om du har arbetat som DBA har du förmodligen haft en konversation med ditt team om att systemprestanda "mystiskt" saktar ner vid vissa tidpunkter. I de flesta fall visar sig den skyldige vara ett analysjobb som får tillgång till massor av data och som slutar med att hela systemet saktar ner.
Som DBaaS-leverantör har vi haft den här konversationen flera gånger med våra kunder. Här är de två alternativen som vi vanligtvis föreslår:
- Om analysjobbet körs på den primära/huvudservern, flytta det till en sekundär/replika server.
- Om analysjobbet redan körs på en sekundär nod och prestandaförsämringen är oacceptabel rekommenderar vi att jobben flyttas till ett dedikerat analyskluster.
Med vår funktion för följarkluster är det mycket enkelt att hålla ett analyskluster uppdaterat med faktiska produktionsdata. Du kan skapa ett följarschema för att synkronisera den senaste informationen från produktionen precis innan ditt analysjobb börjar.
Det bästa? Synkronisering av följare utför inga operationer på databasnivå – den återställer bara den senaste ögonblicksbilden! Så det finns ingen inverkan på ditt produktionskluster.
3. Rapportering
Ett annat vanligt användningsfall där våra kunder använder funktionen för följarkluster är för rapportgenerering. Rapporteringsprocesser körs vanligtvis sällan, men får tillgång till stora mängder data och tar upp det mesta av ett databasklusters resurser. När prestandaförsämringen är oacceptabel rekommenderar vi att våra kunder flyttar rapporteringsarbetet till ett nytt kluster.
Eftersom rapporteringsoperationer är sällsynta föredrar många av våra kunder att utnyttja vår paus-/återuppta-funktion för att "pausa" rapporteringskluster när de inte används. Detta hjälper till att spara enormt på infrastrukturkostnader. Vanligtvis är rapporteringskluster också mycket "mindre" (mindre CPU/RAM), för att hjälpa till att minska kostnaderna.
När du har skapat ett följarkluster från vårt användargränssnitt kan du använda det här arbetsflödet för att automatisera ditt rapporteringsflöde:
- Använd vårt CV för att återuppta klustret.
- Vänta tills klustret är tillbaka i körläge (du kan använda ditt get-status API för detta ändamål).
- Utlös en säkerhetskopia på ditt produktionskluster, om det behövs (vanligtvis, om regelbundna säkerhetskopieringar är schemalagda på din produktion, kan du hoppa över det här steget. Men om du vill att din rapportering ska köras på den senaste informationen är detta viktigt).
- Vänta tills säkerhetskopieringen är klar.
- Utlösa ett synkroniseringsjobb på följaren – detta hittar den senaste ögonblicksbilden på källklustret och återställer till destinationen.
- Vänta tills synkroniseringsjobbet är klart.
- Kör dina rapporteringsuppgifter.
- Använd vårt paus-API för att pausa klustret till ditt nästa rapporteringsjobb!
Tror du att följarkluster passar bra för just ditt användarfall? Du kan lära dig allt om hur du distribuerar och hanterar följarkluster för MongoDB, MySQL och PostgreSQL i våra hjälpdokument!
Om du är osäker på om följarkluster är rätt lösning för ditt användningsfall, lämna en kommentar eller kontakta oss på [email protected] – vi diskuterar gärna vilken funktion som bäst passar dina krav.
