Følgerklynger er en ScaleGrid-funktion, der giver dig mulighed for at holde to uafhængige databasesystemer (af samme type) synkroniserede. I modsætning til kloning eller replikering giver dette dig mulighed for at vedligeholde en aktiv kopi af dine produktionsdata på tidspunktet. Denne ekstra klynge, kendt som en follower-klynge, kan udnyttes til flere use cases, herunder til at analysere, optimere og teste din applikationsydelse til MongoDB, MySQL og PostgreSQL. I dette blogindlæg vil vi dække de tre bedste scenarier for at udnytte følgerklynger til din ansøgning.
Hvordan adskiller følgerklynger sig fra replikering?
I modsætning til en statisk klon importeres disse data efter en fastsat tidsplan, så din følgerklynge altid er synkroniseret med din produktionsklynge. Her er et par kritiske måder, hvorpå det adskiller sig fra replikering:
- Du kan kontrollere, hvor ofte destinationssystemet synkroniserer fra kilden – én gang om ugen, én gang om dagen eller endnu sjældnere. Dette hjælper med at reducere belastningen på kildesystemet.
- Da de er to uafhængige systemer, har du meget mere fleksibilitet over de data, der synkroniseres. Du kan have forskellige brugerlegitimationsoplysninger og endda fjerne nogle data fra destinationen baseret på sikkerhedskrav (bemærk:Dette kræver scripting på brugersiden – det er ikke en indbygget funktion i følgerklynger).
- 'Følger'-systemet er skrivbart, så du kan bruge det som et iscenesættelsesmiljø til at teste dine applikationsændringer. Dette er ikke noget, du kan gøre på en replikaknude.
Bemærk:ScaleGrid implementerer følgerklynger ved hjælp af lagringssnapshots. Den er ikke tilgængelig for vores hukommelsesdatabasetilbud som hosting for Redis™*.
1. Databaseudvikler/testopsætning
Vi har alle været der – et angiveligt gennemtestet stykke kode bliver implementeret i produktionen, og så bryder helvede løs. Produktionsarbejdsgange fejler eller er så langsomme, at de dybest set er ubrugelige. Ingeniører bliver vækket fra deres senge for at starte en fuldblæst brandslukning. En flok søvnløse nætter senere dukker den frygtede grundårsag op.
Applikationen opfører sig anderledes på produktions- og tekniske opsætninger.
Med andre ord testede vi det på "testdata". Hvilket, som det viser sig, ikke var noget som produktionsdataene. I det hele taget.
Den oplagte måde at undgå denne situation på er at køre test på dine produktionsdata. Ikke egentlig produktion selvfølgelig - det vil være at flirte med katastrofe. På en klonet kopi af produktionsdataene. Selvom bekymringer omkring privatlivets fred og datasikkerhed gør dette upraktisk i mange scenarier, hvis privatlivskravene tillader det, er dette den bedste løsning. Vi behøver ikke længere at stole på, at ingeniører genererer passende datasæt – hvis den videregiver testdata, videregiver den produktionsdata.
Det vil sige indtil testdata falder så langt ude af sync med produktionen, at det ikke længere er en god tilnærmelse. Og vi er tilbage ved udgangspunktet.
Det er her følgerklynger kommer ind.
Ved at bruge følgerklynger kan du med jævne mellemrum importere data fra din produktionsdatabase til dev/test-databasen. Og da hele importen udføres ved hjælp af lagringssnapshots, snarere end et logisk dump, er processen næsten øjeblikkelig. Du kan planlægge dine importer en gang hver 24 timer, en gang om ugen eller hvilken frekvens, der passer til dit særlige scenarie.
Med dine udviklings- og QA-klynger indstillet til at følge produktionsklyngen, kan du være rolig. Hvis din applikation videregiver testdatasættet, er den helt sikkert egnet til at implementere i produktionen!
2. Dataanalyse
Hvis du har arbejdet som DBA, har du sikkert haft en samtale med dit team om, at systemets ydeevne "på mystisk vis" går langsommere på bestemte tidspunkter. I de fleste tilfælde viser synderen sig at være et analysejob, der får adgang til tonsvis af data og ender med at bremse hele systemet.
Som DBaaS-leverandør har vi haft denne samtale flere gange med vores kunder. Her er de to muligheder, vi typisk foreslår:
- Hvis analysejobbet kører på den primære/masterserver, skal du flytte det til en sekundær/replikaserver.
- Hvis analysejobbet allerede kører på en sekundær node, og ydeevneforringelsen er uacceptabel, anbefaler vi at flytte opgaverne til en dedikeret analyseklynge.
Ved at bruge vores følgerklyngefunktion er det meget nemt at holde en analyseklynge opdateret med faktiske produktionsdata. Du kan oprette en følgerplan for at synkronisere de seneste data fra produktionen lige før dit analysejob starter.
Den bedste del? Følgersynkronisering udfører ingen operationer på databaseniveau - den gendanner blot det seneste øjebliksbillede! Så der er ingen indvirkning på din produktionsklynge.
3. Rapportering
En anden almindelig brugssag, hvor vores kunder bruger funktionen til følgeklynger, er til rapportgenerering. Rapporteringsprocesser kører typisk sjældent, men får adgang til store mængder data og optager de fleste af en databaseklynges ressourcer. Når ydeevneforringelsen er uacceptabel, anbefaler vi vores kunder at flytte rapporteringsarbejdsbyrden til en ny klynge.
Da rapporteringsoperationer er sjældne, foretrækker mange af vores kunder at udnytte vores pause/genoptag-funktion til at "pause" rapporteringsklynger, når de ikke er i brug. Dette hjælper med at spare massivt på infrastrukturomkostninger. Typisk er rapporteringsklynger også meget "mindre" (mindre CPU/RAM), for at hjælpe med at reducere omkostningerne.
Når du har oprettet en følgerklynge fra vores brugergrænseflade, kan du bruge denne arbejdsgang til at automatisere dit rapporteringsflow:
- Brug vores CV API til at genoptage klyngen.
- Vent, indtil klyngen er tilbage i køretilstand (du kan bruge din get-status API til dette formål).
- Udløs en sikkerhedskopi på din produktionsklynge, hvis det kræves (typisk, hvis der er planlagt regelmæssige sikkerhedskopier på din produktion, kan du springe dette trin over. Men hvis du ønsker, at din rapportering skal køre på de nyeste data, er dette vigtigt).
- Vent på, at sikkerhedskopieringen er fuldført.
- Udløs et synkroniseringsjob på følgeren – dette finder det seneste øjebliksbillede på kildeklyngen og gendanner til destinationen.
- Vent på, at synkroniseringsjobbet er fuldført.
- Kør dine rapporteringsopgaver.
- Brug vores pause API til at sætte klyngen på pause indtil dit næste rapporteringsjob!
Tror du, at følgerklynger passer godt til netop din brugercase? Du kan lære alt om, hvordan du implementerer og administrerer følgerklynger til MongoDB, MySQL og PostgreSQL i vores hjælpedokumenter!
Hvis du er i tvivl om, hvorvidt follower-klynger er den rigtige løsning til dit brugstilfælde, så læg en kommentar eller kontakt os på [email protected] – vi diskuterer gerne, hvilken funktion der passer bedst til dine krav.
