Behovet for at opnå database High Availability er en ret almindelig opgave, og ofte et must. Hvis din virksomhed har et begrænset budget, kan det være dyrt at vedligeholde en replikeringsslave (eller mere end én), der kører på den samme cloud-udbyder (bare venter, hvis det er nødvendigt en dag). Afhængigt af applikationstypen er der nogle tilfælde, hvor en replikeringsslave er nødvendig for at forbedre RTO'en (Recovery Time Objective).
Der er dog en anden mulighed, hvis din virksomhed kan acceptere en kort forsinkelse for at få dine systemer online igen.
Cold Standby, er en redundansmetode, hvor du har en standby node (som backup) til den primære. Denne node bruges kun under en masterfejl. Resten af tiden er den kolde standby-knude lukket ned og bruges kun til at indlæse en sikkerhedskopi, når det er nødvendigt.
For at bruge denne metode er det nødvendigt at have en foruddefineret backuppolitik (med redundans) i henhold til en acceptabel RPO (Recovery Point Objective) for virksomheden. Det kan være, at tab af 12 timers data er acceptabelt for virksomheden, eller at tab af blot én time kan være et stort problem. Hver virksomhed og applikation skal bestemme deres egen standard.
I denne blog lærer du, hvordan du opretter en sikkerhedskopieringspolitik, og hvordan du gendanner den til en kold standby-server ved hjælp af ClusterControl og dens integration med Amazon AWS.
For denne blog antager vi, at du allerede har en AWS-konto og ClusterControl installeret. Mens vi skal bruge AWS som cloud-udbyder i dette eksempel, kan du bruge en anden. Vi bruger følgende PostgreSQL-topologi implementeret ved hjælp af ClusterControl:
- 1 PostgreSQL Primær Node
- 2 PostgreSQL Hot-standby noder
- 2 Load Balancers (HAProxy + Keepalived)
Oprettelse af en acceptabel sikkerhedskopieringspolitik
Den bedste praksis til at oprette denne type politik er at gemme sikkerhedskopieringsfilerne tre forskellige steder, én gemt lokalt på databaseserveren (for hurtigere gendannelse), en anden på en centraliseret backupserver og den sidste i skyen.
Du kan forbedre dette ved også at bruge komplette, inkrementelle og differentielle sikkerhedskopier. Med ClusterControl kan du udføre alle ovenstående bedste praksisser, alt sammen fra det samme system, med en venlig og brugervenlig brugergrænseflade. Lad os starte med at oprette AWS-integrationen i ClusterControl.
Konfiguration af ClusterControl AWS-integration
Gå til ClusterControl -> Integrationer -> Cloud Providers -> Tilføj Cloud-legitimationsoplysninger.
Vælg en cloud-udbyder. Vi understøtter AWS, Google Cloud eller Azure. I dette tilfælde skal du vælge AWS og fortsætte.
Her skal du tilføje et navn, en standardregion og en AWS nøgle-id og nøglehemmelighed. For at få eller oprette disse sidste skal du gå til IAM-sektionen (Identity and Access Management) på AWS-administrationskonsollen. For mere information kan du henvise til vores dokumentation eller AWS-dokumentation.
Nu har du oprettet integrationen, lad os gå til at planlægge den første sikkerhedskopiering vha. ClusterControl.
Planlægning af sikkerhedskopiering med ClusterControl
Gå til ClusterControl -> Vælg PostgreSQL-klyngen -> Sikkerhedskopiering -> Opret sikkerhedskopi.
Du kan vælge, om du vil oprette en enkelt sikkerhedskopi med det samme eller planlægge en ny backup. Så lad os vælge den anden mulighed og fortsætte.
Når du planlægger en sikkerhedskopiering, skal du først angive tidsplanen /frekvens. Derefter skal du vælge en sikkerhedskopieringsmetode (pg_dumpall, pg_basebackup, pgBackRest), den server, som sikkerhedskopieringen skal tages fra, og hvor du vil gemme sikkerhedskopien. Du kan også uploade vores backup til skyen (AWS, Google eller Azure) ved at aktivere den tilsvarende knap.
Angiv derefter brugen af komprimering, komprimeringsniveauet, kryptering og opbevaringsperiode til din backup. Der er en anden funktion kaldet "Bekræft sikkerhedskopiering", som du snart vil se mere detaljeret i dette blogindlæg.
Hvis indstillingen "Upload sikkerhedskopi til skyen" var aktiveret, Jeg vil se dette trin, hvor du skal vælge cloud-legitimationsoplysningerne og oprette eller vælge en S3-bøtte, hvor du skal gemme sikkerhedskopien. Du skal også angive opbevaringsperioden.
Nu har du den planlagte sikkerhedskopiering i afsnittet ClusterControl Schedule Backups. For at dække de bedste fremgangsmåder, der er nævnt tidligere, kan du planlægge en sikkerhedskopi til at gemme den på en ekstern server (ClusterControl-server) og i skyen og derefter planlægge en anden sikkerhedskopiering til at gemme den lokalt i databasenoden for en hurtigere gendannelse.
Gendannelse af en sikkerhedskopi på Amazon EC2
Når sikkerhedskopieringen er færdig, kan du gendanne den ved at bruge ClusterControl i sektionen Sikkerhedskopiering.
Oprettelse af Amazon EC2-instansen
Først og fremmest, for at gendanne det, skal du et sted at gøre det, så lad os oprette en grundlæggende Amazon EC2-instans. Gå til "Launch Instance" i AWS-administrationskonsollen i EC2-sektionen, og konfigurer din instans.
Når din instans er oprettet, skal du kopiere den offentlige SSH nøgle fra ClusterControl-serveren.
Gendannelse af sikkerhedskopien ved hjælp af ClusterControl
Nu har du den nye EC2-instans, lad os bruge den til at gendanne sikkerhedskopien der. For dette skal du i din ClusterControl gå til sikkerhedskopieringssektionen (ClusterControl -> Vælg Cluster -> Backup), og der kan du vælge "Gendan sikkerhedskopiering", eller direkte "Gendan" på den sikkerhedskopi, du vil gendanne.
Du har tre muligheder for at gendanne sikkerhedskopien. Du kan gendanne sikkerhedskopien i en eksisterende databaseknude, gendanne og verificere sikkerhedskopien på en selvstændig vært eller oprette en ny klynge fra sikkerhedskopien. Da du vil oprette en kold standby-knude, så lad os bruge den anden mulighed "Gendan og bekræft på selvstændig vært".
Du skal bruge en dedikeret vært (eller VM), der ikke er en del af af klyngen for at gendanne sikkerhedskopien, så lad os bruge den EC2-instans, der er oprettet til dette job. ClusterControl installerer softwaren, og den gendanner sikkerhedskopien i denne vært.
Hvis indstillingen "Luk serveren efter at sikkerhedskopien er blevet gendannet" er aktiveret, vil ClusterControl stoppe databasenoden efter at have afsluttet gendannelsesjobbet, og det er præcis, hvad vi har brug for til denne oprettelse i kold standby.
Du kan overvåge sikkerhedskopieringen i afsnittet ClusterControl Activity.
Brug af ClusterControl Verify Backup-funktionen
En sikkerhedskopi er ikke en sikkerhedskopi, hvis den ikke kan gendannes. Så du bør sørge for, at sikkerhedskopien fungerer, og gendanne den i den kolde standby-knude ofte.
Denne ClusterControl Verify Backup backup-funktion er en måde at automatisere vedligeholdelsen af en kold standby-knude ved at gendanne en nylig sikkerhedskopi for at holde denne så opdateret som muligt og undgå det manuelle backup-job til gendannelse. Lad os se, hvordan det virker.
Som opgaven "Gendan og bekræft på selvstændig vært" kræver det en dedikeret vært (eller VM), der ikke er en del af klyngen, for at gendanne sikkerhedskopien, så lad os bruge den samme EC2-instans her.
Den automatiske bekræftelse af sikkerhedskopiering er tilgængelig for de planlagte sikkerhedskopier. Så gå til ClusterControl -> Vælg PostgreSQL-klyngen -> Sikkerhedskopiering -> Opret sikkerhedskopi, og gentag de trin, du så tidligere, for at planlægge en ny sikkerhedskopiering.
I det andet trin vil du have funktionen "Bekræft sikkerhedskopiering" tilgængelig for at aktivere det.
Ved at bruge ovenstående muligheder vil ClusterControl installere softwaren og gendanne sikkerhedskopien på værten. Efter at have gendannet det, hvis alt gik fint, vil du se bekræftelsesikonet i afsnittet ClusterControl Backup.
Konklusion
Hvis du har et begrænset budget, men kræver høj tilgængelighed, kan du bruge en kold standby PostgreSQL-node, der kan være gyldig eller ej afhængig af virksomhedens RTO og RPO. I denne blog viste vi dig, hvordan du planlægger en sikkerhedskopi (i henhold til din forretningspolitik), og hvordan du gendanner den manuelt. Vi viste også, hvordan man gendanner sikkerhedskopien automatisk i en kold standby-server ved hjælp af ClusterControl, Amazon S3 og Amazon EC2.