Automatiseret test af opgraderingsprocessen til PXC/MariaDB Galera Cluster

Opgradering af din database til Galera-baserede klynger som Percona XtraDB Cluster (PXC) eller MariaDB Galera Cluster kan være udfordrende, især for et produktionsbaseret miljø. Du har ikke råd til at miste tilstanden af ​​din høje tilgængelighed og sætte den i fare.

En opgraderingsprocedure skal være veldokumenteret, og ideelt set bør dokumentation, streng testning og benchmarking udføres før opgraderinger. Det vigtigste er, at sikkerhed og forbedringer også skal identificeres baseret på ændringsloggen for dens databaseversionsopgradering.

Med alle bekymringerne hjælper automatisering med at opnå en mere effektiv opgraderingsproces og hjælper med at undgå menneskelige fejl og forbedrer RTO.

Sådan administreres PXC/MariaDB Galera Cluster-opgraderingsprocessen 

Opgradering af din PXC/MariaDB Galera Cluster kræver korrekt dokumentation og procesflow, der viser de ting, der skal gøres, og hvad der skal gøres, hvis tingene går sydpå. Det betyder, at der skal udarbejdes en Business Continuity Plan, som også skal dække din Disaster Recovery Plan. Du har ikke råd til at miste din virksomhed i tilfælde af problemer.

Det sædvanlige er at starte først med testmiljøet. Testmiljøet skal have nøjagtig samme indstillinger og konfiguration som dit produktionsmiljø. Du kan ikke fortsætte direkte med at opgradere produktionsmiljøet, da du ikke er sikker på, hvilken effekt og påvirkning det vil opstå, hvis tingene ikke stemmer overens med planen.

At arbejde med et produktionsmiljø er meget følsomt, så i de fleste tilfælde er der altid et nedetids- og vedligeholdelsesvindue for at undgå drastiske konsekvenser.

Der er to typer opgradering til PCX eller MariaDB Galera Cluster, som du skal være opmærksom på. Disse er den store udgivelsesopgradering og den mindre udgivelsesopgradering eller ofte omtalt som in-place opgradering. En in-place opgradering er, hvor du kan opgradere din databaseversion til dens seneste mindre version ved at bruge de samme binære data i din database. Der vil ikke være nogen fysiske ændringer af selve dataene, men kun på dens binære database eller underliggende softwarepakker.

Opgradering af PCX eller MariaDB Galera Cluster til en større udgivelse

Opgradering til en større udgivelse kan være udfordrende, især for et produktionsmiljø. Det involverer en kompleks type databasekonfiguration og særlige indbyggede funktioner i PXC eller MariaDB Galera Cluster. Spatiotemporale, tidsstemplede data, maskindata eller andre multifacetterede data er meget konservative og følsomme over for opgraderinger. Du kan ikke anvende en lokal opgradering til denne proces, fordi der ville være foretaget mange større ændringer. Medmindre du har meget små data eller data, der består af idempotenter, eller data, der nemt kan genereres, kan være sikkert at gøre, så længe du ved, at virkningen ikke vil påvirke dine data.

Hvis din datamængde er stor, er det bedst at have opgraderingsprocessen automatiseret. Det er dog muligvis ikke en ideel løsning at automatisere hele sekvensen i opgraderingsprocessen, fordi der kan være uventede problemer, der sniger sig ind under den store opgraderingsfase. Det er bedst at automatisere gentagne trin og processer med kendte resultater i en større opgradering. På ethvert tidspunkt kræves der en ressource til at evaluere, om automatiseringsprocessen er sikker for at undgå stop i opgraderingsprocessen. Automatisk test efter opgraderingen er lige så vigtig, og den bør inkluderes som en del af processen efter opgraderingen.

Opgradering af PCX eller MariaDB Galera Cluster til en mindre udgivelse

En mindre udgivelsesopgradering kaldet en in-placed opgradering er normalt en sikrere tilgang til at udføre en opgraderingsproces. Dette skyldes, at de mest almindelige ændringer for denne udgivelse er sikkerheds- og udnyttelsesrettelser eller forbedringer, fejl (normalt alvorlige) eller kompatibilitetsproblemer, der kræver patches, især hvis den nuværende hardware eller OS havde ændringer, der kan forårsage, at databasen ikke fungere korrekt. Selvom virkningen normalt kan genoprettes med en minimal effekt, er det stadig et must, at du skal se og læse ændringsloggen, der blev skubbet til den specifikke mindre versionsopgradering.

Deployering af jobbet til at udføre opgraderingsprocessen er et ideelt eksempel på automatisering. Det sædvanlige flow er meget gentagne og forårsager for det meste ingen skade på din eksisterende PXC eller MariaDB Galera Cluster. Det, der betyder mest, er, at efter opgraderingen skal automatisk test fortsætte for at fastslå, at opsætning, konfiguration, effektivitet og funktionalitet ikke er brudt.

Undgå fiaskoerne! Vær klar, få det automatiseret!

En af vores klienter kontaktede os og bad om hjælp, fordi en funktion, som de bruger i databasen, ikke fungerer korrekt efter den mindre opgradering af databasen. De bad om trin og processer til, hvordan man nedgraderer, og hvor sikkert det vil være. Deres kunder klagede over, at deres applikation fuldstændig ikke virker, og generaliserede, at det ikke var nyttigt.

Selv for sådan en lille fejl kan en sur kunde give en dårlig bemærkning til dit produkt. Læren fra dette scenarie er, at fejl i test efter en opgradering fører til en antagelse om, at alle funktioner i en database fungerer som forventet.

Antag, at du har planer om at automatisere opgraderingsprocessen, så vær opmærksom på, at typen af ​​automatiseringsproces varierer alt efter den type opgraderinger, du skal udføre. Som nævnt tidligere har en større opgradering i forhold til en mindre opgradering forskellige forskellige tilgange. Så din automatopsætning gælder muligvis ikke for begge databasesoftwareopgraderinger.

Automatisering efter opgraderingsprocessen

På dette tidspunkt forventes det, at du får udført din opgraderingsproces, ideelt set gennem automatisering. Nu hvor din database er klar til at modtage klientforbindelser, skal den følge med en streng testfase.

Kør mysql_upgrade

Det er meget vigtigt og yderst anbefalet at udføre mysql_upgrade, når opgraderingsprocessen er fuldført. mysql_upgrade leder efter inkompatibiliteter med den opgraderede MySQL-server ved at gøre følgende:

• Den opgraderer systemtabellerne i mysql-skemaet, så du kan drage fordel af nye privilegier eller muligheder, der evt. er blevet tilføjet.

• Det opgraderer ydeevneskemaet og sys-skemaet.

• Den undersøger brugerskemaer.

mysql_upgrade bestemmer, om en tabel har problemer såsom inkompatibilitet på grund af ændringer i den seneste version efter opgraderingen og forsøger at løse det ved at reparere tabellen. Ellers, hvis den mislykkes, skal din automatiseringstest mislykkes og må ikke gå videre til noget andet. Det skal undersøges først og udføre en manuel reparation.

Tjek fejllogfiler

Når mysql_upgrade er færdig, skal du kontrollere og verificere for de fejl, der opstod. Du kan indsætte dette i et script og tjekke for eventuelle "fejl" eller "advarsels"-etiketter i fejlloggene. Det er meget vigtigt at afgøre, om der er en sådan. Din automatiserede test skal have evnen til at fange fejlfælder, enten den kan vente på, at et brugerinput fortsætter, hvis fejlen bare er meget minimal eller forventet, ellers stopper opgraderingsprocessen.

Udfør en enhedstest

Et TDD-databasemiljø (Test Driven Development) er en softwareudviklingstilgang, hvor der er en række testcases, der skal valideres og afgøre, om valideringen er sand (bestået) eller falsk (ikke bestået). Noget i stil med det, vi har på skærmbilledet nedenfor:

Billede udlånt af guru99.com

Dette er en type enhedstest, der hjælper med at undgå uønskede fejl eller logiske fejl i dit program og i din database. Husk, at hvis der er ugyldige data gemt i databasen, vil det skade alle forretningsanalyser og transaktioner, især hvis det involverer komplekse økonomiske beregninger eller matematiske ligninger.

Hvis du spørger, er det virkelig nødvendigt at udføre en enhedstest efter opgraderingen? Selvfølgelig er det det! Du behøver ikke nødvendigvis at køre dette under produktionsmiljøet. Under testfaserne, det vil sige ved først at opgradere dine QA'er, udviklings-/iscenesættelsesmiljø, skal det anvendes i det område. Data skal være en nøjagtig kopi i det mindste eller næsten det samme som dets produktionsmiljø. Dit mål her er at undgå uønskede resultater og helt sikkert forkerte logiske resultater. Du skal selvfølgelig passe godt på dine data og afgøre, om resultaterne består valideringstesten.

Hvis du har til hensigt at køre med din produktion, så gør det. Vær dog ikke så stiv som din testfase anvendt i QA-, udviklings- eller iscenesættelsesmiljøet. Det er fordi du skal planlægge din tid ud fra det tilgængelige vedligeholdelsesvindue og undgå forsinkelser og længere RTO.

I min erfaring vælger kunderne i opgraderingsfasen en hurtigere tilgang, som skal være vigtig for at afgøre, om en sådan funktion giver det korrekte resultat. Desuden kan du have et script til at automatisere testen af ​​et sæt forretningslogiske funktioner eller lagrede procedurer, da det hjælper med at cache forespørgslerne og gøre din database varm.

Når du forbereder enhedstest til din database, skal du undgå at genopfinde hjulet. Tag i stedet et kig på de tilgængelige værktøjer, du kan vælge, hvis det passer til dine krav og behov. Tjek Selenium, eller tjek denne blog.

Bekræft identiteten af ​​forespørgsler

Det mest almindelige værktøj, du kan bruge, er Perconas pt-opgradering. Det verificerer, at forespørgselsresultaterne er identiske på forskellige servere. Den udfører forespørgsler baseret på de givne logfiler og den leverede forbindelse (eller kaldet som DSN), sammenligner derefter resultaterne og rapporterer eventuelle væsentlige forskelle. Det giver mere end det, da dine muligheder for at indsamle eller analysere forespørgslerne, f.eks. gennem tcpdump.

Det er nemt at bruge pt-opgraderingen. For eksempel kan du køre med følgende 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 er en god praksis, at når en opgradering, især en større udgivelsesopgradering er blevet udført, bruges pt-upgrade til at fortsætte og udføre forespørgselsanalyse, der identificerer forskelle baseret på resultaterne. Det er en god praksis at gøre dette i testfasen, mens du gør det på dit QA eller iscenesættelses- og udviklingsmiljø, så du kan beslutte, om det er sikrere at fortsætte. Du kan tilføje dette til dit automatiseringsværktøj og køre det som en spillebog, når det er klar til at udføre sin pligt.

Hvordan automatiseres testprocessen?

I vores tidligere blogs har vi præsenteret forskellige måder at automatisere dine databaser på. De mest almindelige værktøjer, der er mode, er disse IaC (Infrastructure as Code) implementeringssoftwareværktøjer. Du kan bruge Puppet, Chef, SaltStack eller Ansible til at udføre jobbet.

Min præference har altid været Ansible at udføre min automatiserede test, det giver mig mulighed for at oprette playbooks efter dens jobrolle. Selvfølgelig kan jeg ikke skabe én hel tings automat, der vil gøre alle tingene, fordi situationen og miljøet varierer. Baseret på de givne opgraderingstyper tidligere (større vs mindre opgradering), bør du skelne til dens proces. Selvom det kun er en opgradering på stedet, skal du stadig sørge for, at dine playbooks udfører det korrekte job.

ClusterControl er din ven til databaseautomatisering!

ClusterControl er en god mulighed for at udføre grundlæggende og automatiseret test. ClusterControl er ikke en ramme til test; det er ikke et værktøj til at levere enhedstest. Det er dog et databasestyrings- og overvågningsværktøj, der inkorporerer en masse automatiserede implementeringer baseret på de ønskede udløsere fra brugeren eller administratoren af ​​softwaren.

ClusterControl tilbyder mindre versionsopgraderinger, som giver DBA'erne bekvemmelighed, når de udfører opgraderinger. Det gør også mysql_upgrade on the fly. Så du behøver ikke at udføre det manuelt. ClusterControl registrerer også nye versioner, der skal opgraderes, og anbefaler de næste trin for dig. I tilfælde af fejl, vil opgraderingen ikke fortsætte.

Her er et eksempel på det mindre opgraderingsjob:

Hvis du ser godt efter, kører mysql_upgrade med succes. Selvom den ikke anbefaler og udfører en automatisk opgradering af masteren, er det fordi det ikke er den rigtige fremgangsmåde at fortsætte. I så fald skal du promovere den nye slave og derefter degradere masteren som slave for at udføre opgraderingen.

Konklusion

Det fantastiske med ClusterControl er, at du kan inkorporere kontrol af fejllogfiler, udføre en enhedstest, verificere identiteten af ​​forespørgsler ved at oprette Advisors. Det er ikke svært at gøre det. Du kan henvise til vores tidligere blog Brug af ClusterControl Advisor til at oprette checks for SELinux og Meltdown/Spectre:Part One. Dette eksemplificerer, hvordan du kan drage fordel og enten udløse det næste job, der skal udføres, når opgraderingen er udført. ClusterControl har indbyggede alarmer eller alarmer, der kan integreres med dine foretrukne tredjeparts alarmsystemer for at give dig besked om din automatiske tests aktuelle status.