Geautomatiseerd testen van het upgradeproces voor PXC/MariaDB Galera Cluster

Het upgraden van uw database voor op Galera gebaseerde clusters zoals Percona XtraDB Cluster (PXC) of MariaDB Galera Cluster kan een uitdaging zijn, vooral voor een productieomgeving. U kunt het zich niet veroorloven om de staat van uw hoge beschikbaarheid te verliezen en in gevaar te brengen.

Een upgradeprocedure moet goed gedocumenteerd zijn, en idealiter moeten documentatie, strenge tests en benchmarking worden uitgevoerd voordat upgrades worden uitgevoerd. Het belangrijkste is dat beveiliging en verbeteringen ook moeten worden geïdentificeerd op basis van de changelog van de upgrade van de databaseversie.

Met alle zorgen helpt automatisering om een efficiënter upgradeproces te realiseren, menselijke fouten te voorkomen en de RTO te verbeteren.

Het PXC/MariaDB Galera Cluster-upgradeproces beheren

Het upgraden van je PXC/MariaDB Galera Cluster vereist een goede documentatie en processtroom die een overzicht geeft van de dingen die gedaan moeten worden en wat je moet doen als het mis gaat. Dat betekent dat er een bedrijfscontinuïteitsplan moet worden opgesteld dat ook uw rampenherstelplan dekt. U kunt het zich niet veroorloven uw bedrijf te verliezen in geval van problemen.

Het is gebruikelijk om eerst met de testomgeving te beginnen. De testomgeving moet exact dezelfde instellingen en configuratie hebben als uw productieomgeving. U kunt niet direct doorgaan met het upgraden van de productieomgeving omdat u niet zeker weet welk effect en impact het zal hebben als zaken niet volgens plan verlopen.

Werken met een productieomgeving is zeer gevoelig, dus in de meeste gevallen is er altijd een downtime en onderhoudsperiode om drastische gevolgen te voorkomen.

Er zijn twee soorten upgrades voor PCX of MariaDB Galera Cluster waarvan u op de hoogte moet zijn. Dit zijn de major release-upgrade en de minor release-upgrade of vaak aangeduid als in-place upgrade. Bij een interne upgrade kunt u uw databaseversie upgraden naar de meest recente secundaire versie met dezelfde binaire gegevens van uw database. Er zullen geen fysieke wijzigingen zijn aan de gegevens zelf, maar alleen aan de binaire database of onderliggende softwarepakketten.

PCX of MariaDB Galera-cluster upgraden naar een grote release

Upgraden naar een grote release kan een uitdaging zijn, vooral voor een productieomgeving. Het gaat om een complex type databaseconfiguratie en speciale ingebouwde functies van PXC of MariaDB Galera Cluster. Ruimtelijke tijd-, tijdstempelgegevens, machinegegevens of andere veelzijdige gegevens zijn zeer conservatief en gevoelig voor upgrades. U kunt voor dit proces geen interne upgrade toepassen omdat er veel grote wijzigingen zouden zijn aangebracht. Tenzij u zeer kleine gegevens heeft of gegevens die bestaan uit idempotents of gegevens die gemakkelijk kunnen worden gegenereerd, kunt u dit veilig doen, zolang u weet dat de impact geen invloed heeft op uw gegevens.

Als uw datavolume groot is, kunt u het upgradeproces het beste automatiseren. Het is echter misschien niet de ideale oplossing om alle stappen in het upgradeproces te automatiseren, omdat er onverwachte problemen kunnen optreden tijdens de grote upgradefase. Het is het beste om repetitieve stappen en processen met bekende resultaten te automatiseren bij een grote upgrade. Er is op elk moment een resource nodig om te evalueren of het automatiseringsproces veilig is om te voorkomen dat het upgradeproces wordt onderbroken. Geautomatiseerd testen na de upgrade is net zo belangrijk en moet worden opgenomen als onderdeel van het proces na de upgrade.

PCX of MariaDB Galera-cluster upgraden naar een kleine release

Een upgrade van een kleine release die een in-placed upgrade wordt genoemd, is meestal een veiligere manier om een upgradeproces uit te voeren. Dit komt omdat de meest voorkomende wijzigingen voor deze release beveiligings- en exploit-patches of verbeteringen, bugs (meestal ernstige) of compatibiliteitsproblemen zijn waarvoor patches nodig zijn, vooral als de huidige hardware of het huidige besturingssysteem wijzigingen heeft aangebracht die er ook voor kunnen zorgen dat de database niet werkt. naar behoren functioneren. Hoewel de impact meestal met een minimaal effect kan worden hersteld, is het nog steeds een must dat u de changelog bekijkt en leest die naar de specifieke kleine versie-upgrade is gepusht.

Het implementeren van de taak om het upgradeproces uit te voeren is een ideaal voorbeeld voor automatisering. De gebruikelijke stroom is zeer repetitief en veroorzaakt meestal geen schade aan uw bestaande PXC- of MariaDB Galera-cluster. Het belangrijkste is dat na de upgrade geautomatiseerde tests worden uitgevoerd om te bepalen of de setup, configuratie, efficiëntie en functionaliteit niet worden verbroken.

Vermijd de fiasco's! Wees klaar, laat het automatiseren!

Een klant van ons nam contact met ons op en vroeg om hulp omdat, na de kleine upgrade van de database, een functie die ze in de database gebruiken niet goed werkt. Ze vroegen om stappen en processen voor het downgraden en hoe veilig het zal zijn. Hun klanten klaagden dat hun applicatie totaal niet werkt, en generaliseerden dat het niet nuttig is.

Zelfs bij zo'n klein probleempje kan een boze klant een slechte opmerking over je product maken. De les die uit dit scenario is geleerd, is dat het falen van testen na een upgrade leidt tot de veronderstelling dat alle functies in een database werken zoals verwacht.

Stel dat je plannen hebt om het upgradeproces te automatiseren, houd er dan rekening mee dat het type automatiseringsproces varieert afhankelijk van het soort upgrades dat je moet doen. Zoals eerder vermeld, heeft een grote upgrade versus een kleine upgrade verschillende verschillende benaderingen. Uw automaatconfiguratie is dus mogelijk niet van toepassing op beide databasesoftware-upgrades.

Automatiseren na het upgradeproces

Op dit moment wordt verwacht dat je het upgradeproces hebt voltooid, idealiter door middel van automatisering. Nu uw database klaar is om clientverbindingen te ontvangen, volgt een rigoureuze testfase.

Voer mysql_upgrade uit

Het is erg belangrijk en wordt ten zeerste aanbevolen om mysql_upgrade uit te voeren zodra het upgradeproces is voltooid. mysql_upgrade zoekt naar incompatibiliteit met de geüpgradede MySQL-server door de volgende dingen te doen:

Het upgradet de systeemtabellen in het mysql-schema, zodat u kunt profiteren van nieuwe privileges of mogelijkheden die mogelijk zijn toegevoegd.
Het upgradet het prestatieschema en het systeemschema.
Het onderzoekt gebruikersschema's.

De mysql_upgrade bepaalt of een tabel problemen heeft, zoals incompatibiliteiten als gevolg van wijzigingen in de meest recente versie na de upgrade, en probeert dit op te lossen door de tabel te repareren. Anders, als het mislukt, moet uw automatiseringstest mislukken en mag het niet verder gaan met iets anders. Het moet eerst worden onderzocht en een handmatige reparatie uitvoeren.

Controleer foutenlogboeken

Zodra de mysql_upgrade is voltooid, moet u controleren op de fouten die zijn opgetreden. U kunt dit in een script plaatsen en controleren op eventuele "fout"- of "waarschuwings"-labels in de foutenlogboeken. Het is erg belangrijk om te bepalen of die er is. Uw geautomatiseerde test moet de mogelijkheid hebben om error-traps op te vangen, of het kan wachten op invoer van een gebruiker om door te gaan als de fout zeer minimaal is of verwacht wordt, anders stopt u het upgradeproces.

Voer een eenheidstest uit

Een TDD-databaseomgeving (Test Driven Development) is een benadering voor softwareontwikkeling waarbij een reeks testgevallen moet worden gevalideerd en moet worden bepaald of de validatie waar (geslaagd) of onwaar (mislukt) is. Zoiets als wat we in de onderstaande schermafbeelding hebben:

Afbeelding met dank aan guru99.com

Dit is een soort unit-testing die ongewenste bugs of logische fouten in uw toepassing en in uw database helpt voorkomen. Onthoud dat als er ongeldige gegevens in de database zijn opgeslagen, dit alle bedrijfsanalyses en transacties zou schaden, vooral als het complexe financiële berekeningen of wiskundige vergelijkingen betreft.

Als je vraagt, is het echt nodig om een unit-test uit te voeren na de upgrade? Natuurlijk is het! U hoeft dit niet per se onder de productieomgeving uit te voeren. Tijdens de testfasen, d.w.z. eerst uw QA's, ontwikkel-/staging-omgeving upgraden, moet het op dat gebied worden toegepast. Gegevens moeten een exacte kopie zijn die minimaal of bijna hetzelfde is als de productieomgeving. Uw doel hier is om ongewenste resultaten en zeker verkeerde logische resultaten te voorkomen. Je moet natuurlijk goed voor je gegevens zorgen en bepalen of de resultaten de validatietest doorstaan.

Als je van plan bent om met je productie te draaien, doe het dan. Wees echter niet zo rigide als uw testfase die wordt toegepast in de QA-, ontwikkelings- of staging-omgeving. Het is omdat u uw tijd moet plannen op basis van het beschikbare onderhoudsvenster en vertragingen en langere RTO moet vermijden.

Mijn ervaring is dat klanten tijdens de upgradefase een snellere aanpak kiezen die belangrijk is om te bepalen of een dergelijke functie het juiste resultaat oplevert. Bovendien kunt u een script hebben om het testen van een reeks logische bedrijfsfuncties of opgeslagen procedures te automatiseren, omdat het helpt om de query's in de cache op te slaan en uw database warm te maken.

Als u zich voorbereidt op Unit Test voor uw database, moet u voorkomen dat u het wiel opnieuw uitvindt. Bekijk in plaats daarvan de beschikbare tools die u kunt kiezen als deze goed zijn voor uw vereisten en behoeften. Bekijk Selenium, of ga naar deze blog.

Identiteit van zoekopdrachten verifiëren

De meest gebruikte tool is Percona's pt-upgrade. Het controleert of de queryresultaten identiek zijn op verschillende servers. Het voert query's uit op basis van de gegeven logs en geleverde verbinding (of genoemd als DSN), vergelijkt vervolgens de resultaten en rapporteert eventuele significante verschillen. Het biedt meer dan dat, zoals uw opties om de zoekopdrachten te verzamelen of te analyseren, bijvoorbeeld via tcpdump.

Het gebruik van de pt-upgrade is eenvoudig. U kunt bijvoorbeeld het volgende commando uitvoeren:

## 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

Het is een goede gewoonte dat zodra een upgrade, met name een grote release-upgrade, is uitgevoerd, pt-upgrade wordt gebruikt om door te gaan en query-analyses uit te voeren om verschillen te identificeren op basis van de resultaten. Het is een goede gewoonte om dit tijdens de testfase te doen terwijl u het doet in uw QA's of staging- en ontwikkelomgeving, zodat u kunt beslissen of het veiliger is om door te gaan. Je kunt dit toevoegen aan je automatiseringstool en dit als een draaiboek uitvoeren zodra het klaar is om zijn taak uit te voeren.

Hoe het testproces automatiseren?

In onze vorige blogs hebben we verschillende manieren gepresenteerd om uw databases te automatiseren. De meest voorkomende tools die in zwang zijn, zijn deze IaC-softwaretools (Infrastructure as Code). Je kunt Puppet, Chef, SaltStack of Ansible gebruiken om de klus te klaren.

Mijn voorkeur is altijd uitgegaan naar Ansible om mijn geautomatiseerde tests uit te voeren, het stelt me in staat om playbooks te maken op basis van zijn functie. Natuurlijk kan ik niet één hele dingsautomaat maken die alle dingen zal doen, omdat de situatie en de omgeving variëren. Op basis van de eerder gegeven upgradetypes (grote versus kleine upgrade), moet u onderscheid maken in het proces. Zelfs als het slechts een interne upgrade is, moet je er nog steeds voor zorgen dat je playbooks de juiste taak uitvoeren.

ClusterControl is uw vriend voor databaseautomatisering!

ClusterControl is een goede optie om eenvoudige en geautomatiseerde tests uit te voeren. ClusterControl is geen raamwerk voor testen; het is geen hulpmiddel om unit-tests te bieden. Het is echter een databasebeheer- en monitoringtool die veel geautomatiseerde implementaties bevat op basis van de gevraagde triggers van de gebruiker of beheerder van de software.

ClusterControl biedt kleine versie-upgrades, wat de DBA's gemak biedt bij het uitvoeren van upgrades. Het doet mysql_upgrade ook meteen. U hoeft het dus niet handmatig uit te voeren. ClusterControl detecteert ook nieuwe versies die moeten worden geüpgraded en raadt u de volgende stappen aan. Als er een fout wordt aangetroffen, zal de upgrade niet doorgaan.

Hier is een voorbeeld van de kleine upgradetaak:

Als je goed kijkt, wordt de mysql_upgrade succesvol uitgevoerd. Hoewel het een automatische upgrade van de master niet aanbeveelt en uitvoert, is dit omdat het niet de juiste aanpak is om door te gaan. In dat geval moet u de nieuwe slaaf promoveren en vervolgens de meester degraderen als slaaf om de upgrade uit te voeren.

Conclusie

Het mooie van ClusterControl is dat u het controleren van foutenlogboeken kunt opnemen, een eenheidstest kunt uitvoeren en de identiteit van query's kunt verifiëren door adviseurs te maken. Het is niet moeilijk om dat te doen. U kunt verwijzen naar onze vorige blog ClusterControl Advisor gebruiken om controles te maken voor SELinux en Meltdown/Spectre:Part One. Dit is een voorbeeld van hoe u kunt profiteren en de volgende taak kunt activeren zodra de upgrade is uitgevoerd. ClusterControl heeft ingebouwde waarschuwingen of alarmen die kunnen worden geïntegreerd in uw favoriete waarschuwingssystemen van derden om u op de hoogte te stellen van de huidige status van uw geautomatiseerde tests.