Uppgraderingar är alltid en svår och tidskrävande uppgift. Först bör du testa din applikation i en testmiljö, så helst måste du klona din nuvarande produktionsmiljö för detta. Sedan måste du göra en plan för att utföra uppgraderingen som, beroende på verksamheten, kan vara med noll stilleståndstid (eller nästan noll), eller till och med schemalägga ett underhållsfönster för att säkerställa att om något går fel, kommer det att påverka så lite som möjligt.
Om du vill göra alla dessa saker manuellt, finns det en stor risk för mänskliga fel och processen kommer att gå långsamt. I den här bloggen kommer vi att se hur du automatiserar tester för att uppgradera dina MySQL-, MariaDB- eller Percona Server-databaser med ClusterControl.
Typ av uppgraderingar
Det finns två typer av uppgraderingar:Mindre uppgraderingar och större uppgraderingar.
Mindre uppgraderingar
Den första, Minor Upgrade, är den vanligaste och säkraste uppgraderingen, och i de flesta fall utförs denna på plats. Eftersom ingenting är 100% säkert måste du alltid ha säkerhetskopior och replikeringsslavnoder, så om något går fel med uppgraderingen och du av någon anledning inte kan återställa/nedgradera, kan du marknadsföra en slavnod, och dina system kan fortfarande arbeta utan avbrott.
Du kan utföra den här typen av uppgradering med ClusterControl. För detta, gå till ClusterControl -> Välj Cluster -> Hantera -> Uppgraderingar.
På varje vald nod kommer uppgraderingsproceduren:
-
Stoppnod
-
Uppgradera nod
-
Startnod
Masternoden i en replikeringstopologi 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 kan du klona ditt nuvarande databaskluster och testa din applikation där, och när du är klar kan du återskapa den eller till och med skapa ett nytt kluster i den nya versionen och byta trafik när den är klar. Det finns olika tillvägagångssätt för dessa uppgraderingar. Du kan uppgradera noderna en efter en, eller skapa ett annat kluster som replikerar trafiken från den nuvarande, du kan också använda lastbalanserare för att förbättra High Availability och fler alternativ. 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.
Säkerhetskopiering
Säkerhetskopiering är ett måste innan någon uppgradering. En bra backuppolicy kan undvika stora problem för verksamheten. Så låt oss se hur ClusterControl kan automatisera detta.
Skapa en säkerhetskopia
Gå till ClusterControl -> Välj Cluster -> Backup -> Create Backup.
Du kan skapa en ny säkerhetskopia eller konfigurera en schemalagd.
Du kan välja olika säkerhetskopieringsmetoder, beroende på databastekniken, och i samma avsnitt kan du välja vilken server du vill ta säkerhetskopian från, var du vill lagra säkerhetskopian och om du vill ladda upp säkerhetskopian till molnet (AWS, Azure eller Google Cloud) i samma jobb.
Du kan också komprimera och kryptera din säkerhetskopia och ange lagringsperioden, bland andra alternativ.
I avsnittet för säkerhetskopiering kan du se förloppet för säkerhetskopieringen och information som metod, storlek, plats med mera.
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 på ett manuellt eller automatiserat sätt.
Återställ säkerhetskopia på fristående värd
I avsnittet Säkerhetskopiering kan du välja 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 noden och inaktivera brandväggen eller AppArmor/SELinux (beroende på OS). 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 databastjänsten 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 kluster -> Säkerhetskopiering -> Skapa säkerhetskopia och välj alternativet Schemalagd säkerhetskopiering.
Den automatiska funktionen Verifiera säkerhetskopiering är endast tillgänglig för schemalagda säkerhetskopieringar, och processen är densamma som vi beskrev i ett tidigare avsnitt. 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 avsnittet ClusterControl Backup, samma som du kommer att ha genom att göra verifieringen manuellt, med skillnaden att du inte behöver oroa sig för restaureringsuppgiften. ClusterControl återställer säkerhetskopian varje gång automatiskt, och du kan testa din applikation med de senaste uppgifterna.
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 slavnoden att bemästra samt meddela dig om problemet. Det misslyckas också över resten av slavnoderna att replikera från den nya masterservern.
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 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=19 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=19 \
--available-upgrades \
--nodes='10.10.10.146' \
--log \
--print-json
$ s9s cluster --cluster-id=19 \
--upgrade-cluster \
--nodes='10.10.10.146' \
--logSkapa säkerhetskopia
$ s9s backup --create \
--backup-method=mysqldump \
--cluster-id=2 \
--nodes=10.10.10.146:3306 \
--on-controller \
--backup-directory=/storage/backups
--logÅterställ säkerhetskopia
$ s9s backup --restore \
--cluster-id=19 \
--backup-id=3 \
--waitVerifiera säkerhetskopior
$ s9s backup --verify \
--backup-id=3 \
--test-server=10.10.10.151 \
--cluster-id=19 \
--logMarknadsför slavnod
$ s9s cluster --promote-slave \
--cluster-id=19 \
--nodes='10.10.10.146' \
--logSlutsats
Uppgraderingar är nödvändiga men tidskrävande uppgifter. Att distribuera en testmiljö varje gång du behöver uppgradera kan vara en mardröm, och det är svårt att hålla den här uppdaterad utan något automatiseringsverktyg.
ClusterControl låter dig utföra mindre uppgraderingar eller till och med distribuera testmiljön för att göra uppgraderingsuppgiften enklare och säkrare. Du kan också integrera den med olika automationsverktyg som Ansible, Puppet och mer.