Testning är en tidskrävande uppgift, men det är ett måste innan någon uppgraderingsprocess på någon teknik. Beroende på typ av uppgradering kan det vara svårare eller enklare, men det är alltid nödvändigt om du vill vara säker på att din data är säker. Det finns olika tillvägagångssätt för uppgradering, beroende på verksamheten och stilleståndstoleransen. Processen kan till exempel vara att testa din applikation i en separat miljö med den nya versionen, så du måste skapa ett nytt kluster för detta. Ett annat alternativ är att klona din nuvarande produktionsmiljö och uppgradera den, vilket kan vara användbart eftersom du kan emulera hela uppgraderingsprocessen och undvika överraskningar i framtiden.
Genom att göra hela denna testprocess manuellt finns det en stor risk för mänskliga fel och processen kommer att vara långsam vilket kan påverka återhämtningstidsmålet (RTO). I den här bloggen kommer vi att se hur du automatiserar tester för att uppgradera dina PostgreSQL-databaser med ClusterControl.
Typ av databasuppgraderingar
Det finns två typer av uppgraderingar:Mindre uppgraderingar och större uppgraderingar.
Mindre uppgraderingar
Det är den vanligaste och säkraste uppgraderingen, och i de flesta fall utförs den på plats. Eftersom ingenting är 100 % säkert måste du alltid ha säkerhetskopior och standby-noder, så om något går fel med uppgraderingen kan du marknadsföra en standby-nod i den tidigare versionen, och dina system kan fortfarande fungera utan avbrott.
Du kan utföra den här typen av uppgradering med ClusterControl. För detta, gå till ClusterControl -> Välj ditt PostgreSQL-kluster -> Hantera -> Uppgraderingar.
På varje vald nod kommer uppgraderingsproceduren:
-
Stoppnod
-
Uppgradera nod
-
Startnod
Masternoden i en PostgreSQL-topologi kommer inte att uppgraderas. För att uppgradera Mastern måste en annan nod befordras för att bli den nya Mastern först.
Större uppgraderingar
För större uppgraderingar rekommenderas inte uppgraderingen på plats, eftersom risken för att något går fel är för hög för en produktionsmiljö. Istället för detta finns det olika metoder för att göra uppgraderingar.
Du kan klona ditt nuvarande databaskluster, uppgradera det och testa ditt program där, och när du är klar, om allt gick bra, kan du återskapa det för att upprepa processen för att göra den riktiga uppgraderingen , eller så kan du också skapa ett nytt kluster i den nya versionen, testa din applikation och byta trafik när den är klar, och det finns fler alternativ... Användningen av Load Balancers är användbar här för att förbättra High Availability. Det bästa tillvägagångssättet beror på stilleståndstoleransen och återhämtningstidsmålet (RTO).
Du kan inte utföra större uppgraderingar med ClusterControl direkt, eftersom du, som vi nämnde, måste testa allt först för att försäkra dig om att uppgraderingen är säker, men du kan använda olika ClusterControl-funktioner för att göra denna uppgift lättare. Så låt oss se några av dessa funktioner.
Distribuera en testmiljö
För detta behöver du inte skapa allt från grunden. Istället för detta kan du använda ClusterControl för att göra detta manuellt eller automatiskt.
Återställ säkerhetskopia på fristående värd
I avsnittet Säkerhetskopiering, välj en säkerhetskopia och du kommer att se alternativet "Återställ och verifiera på fristående värd" för att återställa en säkerhetskopia i en separat nod.
Här kan du ange om du vill att ClusterControl ska installera programvaran i den nya nod och inaktivera brandväggen eller AppArmor/SELinux (beroende på operativsystemet). För detta behöver du en dedikerad värd (eller virtuell dator) som inte är en del av klustret.
Du kan hålla noden igång, eller så kan ClusterControl stänga av databasen service tills nästa återställningsjobb. När den är klar kommer du att se den återställda/verifierade säkerhetskopian i säkerhetskopieringslistan markerad med en bock.
Om du inte vill göra den här uppgiften manuellt kan du schemalägga denna process med hjälp av funktionen Verifiera säkerhetskopiering för att upprepa detta jobb med jämna mellanrum i ett säkerhetskopieringsjobb. Vi kommer att se hur du gör detta i nästa avsnitt.
Automatisk ClusterControl-säkerhetskopiering
För att automatisera denna uppgift, gå till ClusterControl -> Välj ditt PostgreSQL-kluster -> Säkerhetskopiering -> Skapa säkerhetskopia och välj alternativet Schemalagd säkerhetskopiering. Funktionen för automatisk säkerhetskopiering är endast tillgänglig för schemalagda säkerhetskopieringar.
I det andra steget, se till att du har aktiverat alternativet Verifiera säkerhetskopiering, och fyll i den information som krävs.
När jobbet är klart kan du se verifieringsikonen i ClusterControl Säkerhetskopieringssektion, samma som du kommer att ha genom att göra verifieringen på det manuella sättet, med skillnaden att du inte behöver oroa dig för återställningsuppgiften. ClusterControl återställer säkerhetskopian varje gång automatiskt, och du kan testa din applikation med de senaste uppgifterna.
Skapa kluster från säkerhetskopia
Ett annat sätt att skapa en testmiljö är att skapa ett nytt kluster från en säkerhetskopia av ditt primära kluster. För detta, gå till ClusterControl -> Välj ditt PostgreSQL-kluster -> Säkerhetskopiering. Där väljer du säkerhetskopian som ska återställas från listan och väljer Återställ -> Skapa kluster från säkerhetskopia.
Det här alternativet skapar ett nytt PostgreSQL-kluster från den valda säkerhetskopian.
Du måste lägga till OS- och databasuppgifterna och informationen för att distribuera nytt kluster. När det här jobbet är klart kommer du att se det nya klustret i ClusterControl UI.
Kluster-till-klusterreplikering
Sedan ClusterControl 1.7.4 finns en funktion som heter Cluster-to-Cluster Replication. Det låter dig ha en replikering som körs mellan två autonoma kluster.
Skapa en kluster-till-kluster-replikering
Gå till ClusterControl -> Välj ditt PostgreSQL-kluster -> Klusteråtgärder -> Skapa slavkluster.
Slavklustret kommer att skapas genom att strömma data från det nuvarande primära klustret.
Du måste ange SSH-uppgifter och port, ett namn för ditt slavkluster, och om du vill att ClusterControl ska installera motsvarande programvara och konfigurationer åt dig.
När du har ställt in SSH-åtkomstinformationen måste du definiera databasversionen, datadir, port och administratörsuppgifter. Eftersom det kommer att använda strömmande replikering, se till att du använder samma databasversion, och autentiseringsuppgifterna måste vara desamma som används av det primära klustret.
I det här steget måste du lägga till servern i det nya slavklustret . För den här uppgiften kan du ange både IP-adress eller värdnamn för databasnoden.
Du kan övervaka jobbstatusen i ClusterControl-aktivitetsövervakaren. När uppgiften är klar kan du se klustret på huvudskärmen för ClusterControl.
Autorecovery and failover
Om du har aktiverat funktionen för automatisk återställning, i händelse av fel, kommer ClusterControl att marknadsföra den mest avancerade standbynoden till primär samt meddela dig om problemet. Det misslyckas också över resten av standbynoderna att replikera från den nya primära servern.
Om det finns lastbalanserare i topologin kommer ClusterControl att konfigurera om dem för att tillämpa topologiändringarna.
Du kan även köra en failover manuellt om det behövs. Gå till ClusterControl -> Välj ditt PostgreSQL-kluster -> Noder -> Välj den nod som ska främjas -> Nodåtgärder -> Marknadsför slav.
På detta sätt, om något går fel under uppgraderingen, kan du använda ClusterControl för att fixa det ASAP.
Automatisera saker med ClusterControl CLI
ClusterControl CLI, även känd som s9s, är ett kommandoradsverktyg som introducerats i ClusterControl version 1.4.1 för att interagera, kontrollera och hantera databaskluster med ClusterControl-systemet. ClusterControl CLI öppnar en dörr för klusterautomatisering där du enkelt kan integrera den med befintliga automationsverktyg för distribution som Ansible, Puppet, Chef, etc. Låt oss nu se några exempel på detta verktyg.
Uppgradera
$ 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 \
--logVerifiera säkerhetskopior
$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--logKluster-till-klusterreplikering
$ 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 \
--logMarknadsför slavnod
$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--logSlutsats
Uppgraderingar är nödvändiga men tidskrävande uppgifter eftersom du behöver testa din applikation för att undvika problem under processen. Det kan vara svårt att distribuera en testmiljö varje gång du behöver uppgradera och underhålla den här uppdateringen utan något automatiseringsverktyg.
ClusterControl låter dig utföra mindre uppgraderingar från ClusterControl UI eller CLI, eller till och med distribuera testmiljön för att göra uppgraderingen enklare och säkrare. Du kan också integrera den med olika automationsverktyg som Ansible, Puppet och mer.