Automatiseret test af opgraderingsprocessen til PostgreSQL

Test er en tidskrævende opgave, men det er et must før enhver opgraderingsproces på enhver teknologi. Afhængigt af typen af opgradering kan det være sværere eller nemmere, men det er altid nødvendigt, hvis du vil sikre dig, at dine data er sikre. Der er forskellige tilgange til opgradering, afhængigt af virksomheden og nedetidstolerancen. For eksempel kan processen være at teste din applikation i et separat miljø med den nye version, så du bliver nødt til at oprette en ny klynge til dette. En anden mulighed er at klone dit nuværende produktionsmiljø og opgradere det, hvilket kan være nyttigt, da du kan efterligne hele opgraderingsprocessen og undgå overraskelser i fremtiden.

Ved at udføre hele denne testproces manuelt, er der en stor chance for menneskelige fejl, og processen vil være langsom, hvilket kan påvirke Recovery Time Objective (RTO). I denne blog vil vi se, hvordan du automatiserer test til opgradering af dine PostgreSQL-databaser ved hjælp af ClusterControl.

Type databaseopgraderinger

Der er to typer opgraderinger:Mindre opgraderinger og større opgraderinger.

Mindre opgraderinger

Det er den mest almindelige og sikre opgradering, og i de fleste tilfælde udføres denne på plads. Da intet er 100 % sikkert, skal du altid have sikkerhedskopier og standby noder, så hvis noget går galt med opgraderingen, kan du fremme en standby node i den tidligere version, og dine systemer kan stadig fungere uden afbrydelser.

Du kan udføre denne form for opgradering ved hjælp af ClusterControl. For dette skal du gå til ClusterControl -> Vælg din PostgreSQL-klynge -> Administrer -> Opgraderinger.

På hver valgt node vil opgraderingsproceduren:

Stopknude
Opgrader node
Startknude

Masternoden i en PostgreSQL-topologi vil ikke blive opgraderet. For at opgradere Master skal en anden node forfremmes til at blive den nye Master først.

Større opgraderinger

For større opgraderinger anbefales det ikke at opgradere på stedet, da risikoen for, at noget går galt, er for høj til et produktionsmiljø. I stedet for dette er der forskellige tilgange til at lave opgraderinger.

Du kan klone din nuværende databaseklynge, opgradere den og teste din applikation der, og når du er færdig, hvis alt gik fint, kan du genskabe den for at gentage processen for at lave den rigtige opgradering , eller du kan også oprette en ny klynge i den nye version, teste din applikation og skifte trafikken, når den er klar, og der er flere muligheder... Brugen af Load Balancers er nyttig her for at forbedre High Availability. Den bedste tilgang afhænger af nedetidstolerancen og Recovery Time Objective (RTO).

Du kan ikke udføre større opgraderinger med ClusterControl direkte, fordi, som vi nævnte, skal du teste alt først for at sikre dig, at opgraderingen er sikker, men du kan bruge forskellige ClusterControl-funktioner til at lave denne opgave lettere. Så lad os se nogle af disse funktioner.

Implementering af et testmiljø

For dette behøver du ikke at oprette alt fra bunden. I stedet for dette kan du bruge ClusterControl til at gøre dette på en manuel eller automatiseret måde.

Gendan sikkerhedskopiering på Standalone Host

Vælg en sikkerhedskopi i afsnittet Sikkerhedskopiering, og du vil se muligheden "Gendan og verificere på selvstændig vært" for at gendanne en sikkerhedskopi i en separat node.

Her kan du angive, om du ønsker, at ClusterControl skal installere softwaren i den nye node, og deaktiver firewallen eller AppArmor/SELinux (afhængigt af OS). Til dette har du brug for en dedikeret vært (eller VM), der ikke er en del af klyngen.

Du kan holde noden oppe og køre, eller ClusterControl kan lukke databasen ned service indtil næste gendannelsesjob. Når den er færdig, vil du se den gendannede/verificerede sikkerhedskopi på backuplisten markeret med et flueben.

Hvis du ikke ønsker at udføre denne opgave manuelt, kan du planlægge denne proces ved at bruge funktionen Bekræft sikkerhedskopiering for at gentage dette job med jævne mellemrum i et sikkerhedskopieringsjob. Vi skal se, hvordan du gør dette i næste afsnit.

Automatisk ClusterControl-sikkerhedskopibekræftelse

For at automatisere denne opgave skal du gå til ClusterControl -> Vælg din PostgreSQL-klynge -> Sikkerhedskopiering -> Opret sikkerhedskopi, og vælg indstillingen Planlagt sikkerhedskopiering. Funktionen automatisk bekræftelse af sikkerhedskopiering er kun tilgængelig for planlagte sikkerhedskopier.

I det andet trin skal du sørge for, at du har aktiveret indstillingen Bekræft sikkerhedskopiering, og udfyld de nødvendige oplysninger.

Når jobbet er færdigt, kan du se bekræftelsesikonet i ClusterControl Sikkerhedskopieringssektion, den samme som du vil have ved at udføre verifikationen på den manuelle måde, med den forskel, at du ikke behøver at bekymre dig om genoprettelsesopgaven. ClusterControl vil gendanne sikkerhedskopien hver gang automatisk, og du kan teste din applikation med de seneste data.

Opret klynge fra sikkerhedskopi

En anden måde at skabe et testmiljø på er ved at oprette en ny klynge fra en sikkerhedskopi af din primære klynge. For dette skal du gå til ClusterControl -> Vælg din PostgreSQL-klynge -> Backup. Der skal du vælge den sikkerhedskopi, der skal gendannes fra listen, og vælge Gendan -> Opret klynge fra sikkerhedskopi.

Denne mulighed vil oprette en ny PostgreSQL-klynge fra den valgte sikkerhedskopi.

Du skal tilføje OS- og databaselegitimationsoplysningerne og oplysningerne for at implementere ny klynge. Når dette job er færdigt, vil du se den nye klynge i ClusterControl UI.

Klynge-til-klynge-replikering

Siden ClusterControl 1.7.4 er der en funktion kaldet Cluster-to-Cluster Replication. Det giver dig mulighed for at have en replikering kørende mellem to autonome klynger.

Oprettelse af en klynge-til-klynge-replikering

Gå til ClusterControl -> Vælg din PostgreSQL-klynge -> Klyngehandlinger -> Opret slaveklynge.

Slaveklyngen vil blive oprettet ved at streame data fra den nuværende primære klynge.

Du skal angive SSH-legitimationsoplysninger og port, et navn til din slaveklynge, og hvis du ønsker, at ClusterControl skal installere den tilsvarende software og konfigurationer for dig.

Efter opsætning af SSH-adgangsoplysningerne skal du definere databaseversionen, datadir, port og administratorlegitimationsoplysninger. Da det vil bruge streamingreplikering, skal du sørge for at bruge den samme databaseversion, og legitimationsoplysningerne skal være de samme, som bruges af den primære klynge.

I dette trin skal du tilføje serveren til den nye slaveklynge . Til denne opgave kan du indtaste både IP-adresse eller værtsnavn for databasenoden.

Du kan overvåge jobstatus i ClusterControl-aktivitetsmonitoren. Når opgaven er færdig, kan du se klyngen på hovedskærmen til ClusterControl.

Autogendannelse og failover

Hvis autogendannelsesfunktionen er aktiveret, vil ClusterControl i tilfælde af fejl fremme den mest avancerede standby-knude til primær samt give dig besked om problemet. Det mislykkes også over resten af standby-noderne at replikere fra den nye primære server.

Hvis der er Load Balancers i topologien, vil ClusterControl omkonfigurere dem til at anvende topologiændringerne.

Du kan også køre en failover manuelt, hvis det er nødvendigt. Gå til ClusterControl -> Vælg din PostgreSQL-klynge -> Noder -> Vælg den node, der skal forfremmes -> Nodehandlinger -> Promoter slave.

På denne måde, hvis noget går galt under opgraderingen, kan du bruge ClusterControl til at rette det ASAP.

Automatisering af ting med ClusterControl CLI

ClusterControl CLI, også kendt som s9s, er et kommandolinjeværktøj introduceret i ClusterControl version 1.4.1 til at interagere, kontrollere og administrere databaseklynger ved hjælp af ClusterControl-systemet. ClusterControl CLI åbner en dør til klyngeautomatisering, hvor du nemt kan integrere den med eksisterende implementeringsautomatiseringsværktøjer som Ansible, Puppet, Chef osv. Lad os nu se nogle eksempler på dette værktøj.

Opgrader

$ s9s cluster --cluster-id=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--log

Bekræft sikkerhedskopier

$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--log

Klynge-til-klynge-replikering

$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--log

Promover Slave Node

$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--log

Konklusion

Opgraderinger er nødvendige, men tidskrævende opgaver, da du skal teste din applikation for at undgå problemer under processen. Det kan være svært at implementere et testmiljø, hver gang du skal opgradere og vedligeholde dette up-to-date uden noget automatiseringsværktøj.

ClusterControl giver dig mulighed for at udføre mindre opgraderinger fra ClusterControl UI eller CLI, eller endda implementere testmiljøet for at gøre opgraderingsopgaven nemmere og sikrere. Du kan også integrere det med forskellige automatiseringsværktøjer som Ansible, Puppet og mere.