Automatiserad testning av uppgraderingsprocessen för PXC/MariaDB Galera Cluster

Att uppgradera din databas för Galera-baserade kluster som Percona XtraDB Cluster (PXC) eller MariaDB Galera Cluster kan vara utmanande, särskilt för en produktionsbaserad miljö. Du har inte råd att förlora din höga tillgänglighet och utsätta den för risker.

En uppgraderingsprocedur måste vara väl dokumenterad, och helst bör dokumentation, rigorösa tester och benchmarking göras före uppgraderingar. Viktigast av allt, säkerhet och förbättringar måste också identifieras baserat på ändringsloggen för dess databasversionsuppgradering.

Med alla bekymmer hjälper automatisering till att uppnå en mer effektiv uppgraderingsprocess och hjälper till att undvika mänskliga fel och förbättrar RTO.

Hur man hanterar PXC/MariaDB Galera Cluster Upgrade Process 

Att uppgradera ditt PXC/MariaDB Galera Cluster kräver korrekt dokumentation och processflöde som listar de saker som ska göras och vad som ska göras om saker går söderut. Det betyder att en affärskontinuitetsplan som också ska täcka din katastrofåterställningsplan bör läggas fram. Du har inte råd att förlora ditt företag i händelse av problem.

Den vanliga metoden är att börja först med testmiljön. Testmiljön bör ha exakt samma inställningar och konfiguration som din produktionsmiljö. Du kan inte fortsätta direkt med att uppgradera produktionsmiljön eftersom du inte är säker på vilken effekt och påverkan det kommer att uppstå om saker och ting inte stämmer överens med planen.

Att arbeta med en produktionsmiljö är mycket känsligt, så i de flesta fall finns det alltid ett stillestånds- och underhållsfönster för att undvika drastisk påverkan.

Det finns två typer av uppgraderingar för PCX eller MariaDB Galera Cluster som du måste vara medveten om. Dessa är den stora versionsuppgraderingen och den mindre versionsuppgraderingen eller ofta kallad in-place-uppgradering. En uppgradering på plats är där du kan uppgradera din databasversion till den senaste mindre versionen med samma binära data i din databas. Det kommer inte att göras några fysiska ändringar av själva data, utan endast på dess binära databas eller underliggande programvarupaket.

Uppgraderar PCX eller MariaDB Galera Cluster till en större version

Att uppgradera till en större version kan vara utmanande, särskilt för en produktionsmiljö. Det involverar en komplex typ av databaskonfiguration och speciella inbyggda funktioner i PXC eller MariaDB Galera Cluster. Spatiotemporal, tidsstämplad data, maskindata eller mångfacetterad data är mycket konservativa och känsliga för uppgraderingar. Du kan inte tillämpa en uppgradering på plats för den här processen eftersom många stora ändringar skulle ha gjorts. Om du inte har mycket små data eller data som består av idempotenter eller data som enkelt kan genereras kan det vara säkert att göra så länge du vet att påverkan inte kommer att påverka din data.

Om din datavolym är stor är det bäst att ha uppgraderingsprocessen automatiserad. Det kanske dock inte är en idealisk lösning att automatisera hela sekvensen i uppgraderingsprocessen eftersom det kan finnas oväntade problem som smyger sig in under den stora uppgraderingsfasen. Det är bäst att automatisera repetitiva steg och processer med kända utfall i en större uppgradering. När som helst krävs en resurs för att utvärdera om automatiseringsprocessen är säker för att undvika stopp i uppgraderingsprocessen. Automatisk testning efter uppgraderingen är lika viktig, och den bör inkluderas som en del av efteruppgraderingsprocessen.

Uppgradering av PCX eller MariaDB Galera Cluster till en mindre version

En mindre versionsuppgradering som kallas en inplacerad uppgradering är vanligtvis ett säkrare tillvägagångssätt för att utföra en uppgraderingsprocess. Detta beror på att de vanligaste ändringarna för den här utgåvan är säkerhets- och exploateringskorrigeringar eller förbättringar, buggar (vanligtvis allvarliga sådana), eller kompatibilitetsproblem som kräver korrigeringar, särskilt om den aktuella hårdvaran eller operativsystemet har tillämpat ändringar som kan göra att databasen inte gör det. fungera ordentligt. Även om effekten vanligtvis kan återställas med minimal effekt, är det fortfarande ett måste att du måste titta och läsa ändringsloggen som skickades till den specifika mindre versionsuppgraderingen.

Att distribuera jobbet för att utföra uppgraderingsprocessen är ett idealiskt exempel för automatisering. Det vanliga flödet är mycket repetitivt och orsakar oftast ingen skada på ditt befintliga PXC eller MariaDB Galera Cluster. Det som är viktigast är att efter uppgraderingen ska automatiserad testning fortsätta för att fastställa att installationen, konfigurationen, effektiviteten och funktionaliteten inte är trasiga.

Undvik fiaskoerna! Var redo, ha det automatiserat!

En klient till oss kontaktade oss och bad om hjälp eftersom en funktion som de använder i databasen inte fungerar korrekt efter den mindre uppgraderingen av databasen. De bad om steg och processer för hur man nedgraderar och hur säkert det kommer att vara. Deras kunder klagade på att deras applikation helt inte fungerar och generaliserade att det inte är användbart.

Även för ett så litet fel kan en förbannad kund ge en dålig kommentar till din produkt. Lärdomen från det här scenariot är att ett misslyckande med testning efter en uppgradering leder till ett antagande om att alla funktioner i en databas fungerar som förväntat.

Anta att du har planer på att automatisera uppgraderingsprocessen, notera då att typen av automatiseringsprocess varierar beroende på vilken typ av uppgraderingar du måste göra. Som nämnts tidigare har en större uppgradering jämfört med en mindre uppgradering olika distinkta tillvägagångssätt. Så din automatinställning kanske inte gäller för båda uppgraderingarna av databasprogramvaran.

Automatisk efter uppgraderingsprocessen

Vid denna tidpunkt förväntas det att du har din uppgraderingsprocess gjord, helst genom automatisering. Nu när din databas är redo att ta emot klientanslutningar måste den följa med en rigorös testfas.

Kör mysql_upgrade

Det är mycket viktigt och extremt rekommenderat att köra mysql_upgrade när uppgraderingsprocessen har slutförts. mysql_upgrade letar efter inkompatibiliteter med den uppgraderade MySQL-servern genom att göra följande:

• Den uppgraderar systemtabellerna i mysql-schemat så att du kan dra nytta av nya privilegier eller funktioner som kan har lagts till.

• Den uppgraderar prestandaschemat och sys-schemat.

• Den undersöker användarscheman.

Mysql_upgrade avgör om en tabell har problem som inkompatibilitet på grund av ändringar i den senaste versionen efter uppgraderingen och försöker lösa det genom att reparera tabellen. Annars, om det misslyckas, måste ditt automationstest misslyckas och får inte gå vidare till något annat. Det måste undersökas först och göra en manuell reparation.

Kontrollera felloggar

När mysql_upgrade är klar måste du kontrollera och verifiera de fel som uppstod. Du kan lägga in detta i ett skript och kontrollera om det finns några "fel"- eller "varnings"etiketter i felloggarna. Det är mycket viktigt att avgöra om det finns en sådan. Ditt automatiska test måste ha förmågan att fånga felfällor, antingen kan det vänta på att en användarinmatning fortsätter om felet bara är väldigt minimalt eller förväntat, annars stoppa uppgraderingsprocessen.

Utför ett enhetstest

En TDD-databasmiljö (Test Driven Development) är ett tillvägagångssätt för mjukvaruutveckling där det finns en serie testfall som ska valideras och avgöra om valideringen är sann (godkänd) eller falsk (underkänd). Något liknande det vi har i skärmdumpen nedan:

Bild med tillstånd från guru99.com

Detta är en typ av enhetstestning som hjälper till att undvika oönskade buggar eller logiska fel i din applikation och i din databas. Kom ihåg att om det finns ogiltiga data lagrade i databasen, skulle det skada all affärsanalys och transaktioner, särskilt om det involverar komplexa finansiella beräkningar eller matematiska ekvationer.

Om du frågar, är det verkligen nödvändigt att utföra ett enhetstest efter uppgraderingen? Så klart det är! Du behöver inte nödvändigtvis köra detta under produktionsmiljön. Under testfaserna, d.v.s. när du först uppgraderar dina QAs, utvecklings-/staging-miljön, måste den tillämpas i det området. Data måste vara en exakt kopia åtminstone eller nästan samma som dess produktionsmiljö. Ditt mål här är att undvika oönskade resultat och definitivt felaktiga logiska resultat. Du måste naturligtvis ta väl hand om dina data och avgöra om resultaten klarar valideringstestet.

Om du tänker köra med din produktion, gör det då. Var dock inte så stel som din testfas tillämpas i QA-, utvecklings- eller iscensättningsmiljön. Det beror på att du måste planera din tid utifrån det tillgängliga underhållsfönstret och undvika förseningar och längre RTO.

Enligt min erfarenhet väljer kunder under uppgraderingsfasen ett snabbare tillvägagångssätt som ska vara viktigt för att avgöra om en sådan funktion ger rätt resultat. Dessutom kan du ha ett skript för att automatisera testet av en uppsättning affärslogiska funktioner eller lagrade procedurer eftersom det hjälper till att cachelagra frågorna och göra din databas varm.

När du förbereder dig för Unit Test för din databas, undvik att uppfinna hjulet på nytt. Ta istället en titt på de tillgängliga verktygen du kan välja om det är bra för dina krav och behov. Kolla in Selenium eller kolla in den här bloggen.

Verifiera frågornas identitet

Det vanligaste verktyget du kan använda är Perconas pt-uppgradering. Den verifierar att frågeresultaten är identiska på olika servrar. Den exekverar frågor baserat på de givna loggarna och den medföljande anslutningen (eller kallas DSN), jämför sedan resultaten och rapporterar eventuella signifikanta skillnader. Det erbjuder mer än så eftersom dina alternativ att samla in eller analysera frågorna, till exempel genom tcpdump.

Det är enkelt att använda pt-uppgraderingen. Du kan till exempel köra med följande kommando:

## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log

## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517

## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535  -x -n -q -tttt     \
  | pt-query-digest --type tcpdump --no-report --print \
  | pt-upgrade h=host1 h=host2

Det är en god praxis att när en uppgradering, särskilt en större versionsuppgradering har utförts, används pt-upgrade för att fortsätta och utföra frågeanalys för att identifiera skillnader baserat på resultaten. Det är en bra praxis att göra detta under testfasen samtidigt som du gör det på din QAs eller iscensättning och utvecklingsmiljö så att du kan bestämma om det är säkrare att fortsätta. Du kan lägga till detta i ditt automatiseringsverktyg och köra det som en spelbok när den är redo att utföra sin uppgift.

Hur automatiseras testprocessen?

I våra tidigare bloggar har vi presenterat olika sätt att automatisera dina databaser. De vanligaste verktygen som är på modet är dessa IaC (Infrastructure as Code) distributionsprogramvaruverktyg. Du kan använda Puppet, Chef, SaltStack eller Ansible för att göra jobbet.

Min preferens har alltid varit Ansible att utföra mina automatiserade tester, det låter mig skapa spelböcker efter sin jobbroll. Naturligtvis kan jag inte skapa en hel saksautomat som gör allt eftersom situationen och miljön varierar. Baserat på de givna uppgraderingstyperna tidigare (stor vs mindre uppgradering), bör du särskilja processen. Även om det bara är en uppgradering på plats, måste du fortfarande se till att dina spelböcker utför rätt jobb.

ClusterControl är din vän med databasautomatisering!

ClusterControl är ett bra alternativ för att utföra grundläggande och automatiserade tester. ClusterControl är inte ett ramverk för testning; det är inte ett verktyg för att tillhandahålla enhetstestning. Det är dock ett databashanterings- och övervakningsverktyg som innehåller många automatiserade distributioner baserat på de begärda triggers från användaren eller administratören av programvaran.

ClusterControl erbjuder mindre versionsuppgraderingar, vilket ger DBA:er bekvämlighet när de utför uppgraderingar. Det gör mysql_upgrade i farten också. Så du behöver inte utföra det manuellt. ClusterControl upptäcker också nya versioner som ska uppgraderas och rekommenderar nästa steg för dig att göra. Om ett fel uppstår kommer uppgraderingen inte att fortsätta.

Här är ett exempel på det mindre uppgraderingsjobbet:

Om du tittar noga så körs mysql_upgrade framgångsrikt. Även om den inte rekommenderar och gör en automatisk uppgradering av mastern, beror det på att det inte är rätt tillvägagångssätt att fortsätta. I så fall måste du marknadsföra den nya slaven och sedan degradera mastern som slav för att utföra uppgraderingen.

Slutsats

Det fantastiska med ClusterControl är att du kan inkludera kontroll av felloggar, utföra ett enhetstest, verifiera identiteten på frågor genom att skapa rådgivare. Det är inte svårt att göra det. Du kan hänvisa till vår tidigare blogg Använda ClusterControl Advisor för att skapa checkar för SELinux och Meltdown/Spectre:Part One. Detta exemplifierar hur du kan dra fördel av och antingen utlösa nästa jobb att göra när uppgraderingen är utförd. ClusterControl har inbyggda varningar eller larm som kan integreras med dina favoritlarmsystem från tredje part för att meddela dig om din automatiska tests aktuella status.