MySQL 8.0 har været tilgængelig i et stykke tid, og Percona XtraDB Cluster 8.0 har også været tilgængelig i nogen tid. MySQL 5.6 nærmer sig også sin End-of-Life, og folk, der bruger PXC 5.6, vil også snart migrere til en nyere version. Lad os tage et kig på processen og dele nogle tips omkring den.
Husk, det er MySQL Underneath...
Til at begynde med skal du huske på, at Galera kun er et plugin, der fungerer med MySQL, så du skal sikre, at du overholder migreringsreglerne og -processerne for netop din MySQL-version, der bruges i din PXC. Hvis vi kører PXC 5.7, og du vil opgradere til PXC 8.0, skal du først markere alle boksene på MySQL-opgraderingstjeklisten. Vi dækkede noget af det i vores blog, der beskriver opgraderingsprocessen mellem MySQL 5.7 og MySQL 8.0. Det betyder også, at kun opgraderingsstier understøttet af MySQL er levedygtige - for eksempel kan du ikke opgradere PXC 5.6 direkte til PXC 8.0, da direkte MySQL-opgradering fra 5.6 til 8.0 ikke understøttes.
Læs opgraderingsdokumentationen
Som sædvanligt, når du planlægger en opgradering, bør du gøre dig bekendt med dokumentationen udarbejdet af leverandøren. Percona har en webside dedikeret til at forklare opgraderingsprocessen og forbehold omkring den. Vi vil gennemgå nogle af disse punkter i dette blogindlæg.
Konfigurationsændringer
Der er et par ændringer i standardkonfigurationsindstillingerne, der kan udløse problemer i opgraderingsprocessen - pxc_strict_mode er som standard indstillet til ENFORCING. Denne tilstand blokerer enhver form for konfiguration, der er eksperimentel og kan påvirke klyngens stabilitet. Checks dækker blandt andet over brugte lagringsmotorer, binært logformat, eksistensen af primærnøgler og nogle andre ting. Når du opgraderer, vil du måske indstille den til TILLADELSE for at spore inkompatibiliteterne i fejlloggen, men ellers lade PXC'en køre, selvom nogle ting ikke er i den bedste form.
En anden indstilling, pxc_encrypt_cluster_traffic, er også aktiveret som standard, hvilket gennemtvinger kryptering af Galera-kommunikationen mellem noder. Det er ikke muligt at blande noder med krypterede og ukrypterede noder i den samme klynge, derfor skal du enten konfigurere det på alle noderne eller sikre, at du deaktiverer pxc_encrypt_cluster_traffic på de nye PXC 8.0 noder.
Ændring af standardgodkendelsesplugin
Vi nævnte dette i vores blogindlæg om migrering til MySQL 8.0, men ændringen er så vigtig, at vi også vil gentage den her - med MySQL 8.0 ændres standardgodkendelsesplugin'et til caching_sha2_password - dette kan muligvis gøre nogle af de ældre applikationer inkompatible med MySQL 8.0. Selvfølgelig kan du ændre denne indstilling, men hvis du ikke tager det i betragtning, kan det give bagslag, efter at opgraderingen er fuldført.
Opgraderingsprocesser
Til at begynde med skal du huske på, at selvom det ikke anbefales, er det med nogle muligt at have både PXC 5.7 og PXC 8.0 noder kørende i den samme klynge. Dette åbner en mulighed for at lave en live-opgradering på stedet. Processen ville være ret enkel - stop PXC 5.7 node, opgrader den til PXC 8.0 ved at installere en ny version og starte den. I processen vil databiblioteket blive opgraderet til den nye version, og den nye PXC 8.0 node skulle kunne starte korrekt og slutte sig til klyngen. Derefter fortsætter du med noderne én efter én, og migrerer dem fra PXC 5.7 til PXC 8.0. Husk at du bør undgå SST, da en datamappe fra PXC 8.0 node ikke kan bruges på 5.7. Den anden vej rundt burde virke ok. For at forhindre SST i at ske, skal du sikre, at gcache-størrelsen er stor nok til at rumme skrivninger og tillade IST at ske. IST selv vil fungere fint.
Hvis du har flere ledige noder, kan du altid udføre opgraderingen med to klynger på forskellige hovedversioner, der kører parallelt og forbundet gennem asynkron replikering. Hvad der er vigtigt, en sådan tilgang vil lade dig teste PXC 8.0 mere grundigt, da du vil have den oppe og køre i et stykke tid (dybest set så længe du har brug for den), og du kan teste din applikation på denne klynge - når som helst i gang kan du flytte noget af den skrivebeskyttede arbejdsbyrde til PXC 8.0 for at se, hvordan forespørgsler håndteres, hvis der er nogen fejl eller ydeevneproblemer.
Hvis du bruger ClusterControl, kan dette opnås ved at bruge "Create Slave Cluster"-jobbet.
Du bliver bedt om at bestemme, hvor de oprindelige data skal komme fra, master PXC-node eller fra sikkerhedskopien.
Du skal også videregive tilslutningsdetaljer som SSH-bruger og nøglesti .
Så bliver du bedt om at vælge leverandør og version - du vil sikkert gerne for at bruge PXC 5.7 indtil videre, vil du opgradere noderne senere og teste selve opgraderingsprocessen.
Til sidst skal du videregive nodeværtsnavnene eller IP-adresserne for ClusterControl til opret forbindelse til og start opsætning af noderne.
Som resultat vil du have en anden Percona XtraDB Cluster, der kører i version 5.7 , replikerer fra den originale klynge. Denne klynge kan opgraderes til den nye version, og i sidste ende kan du skifte din trafik til den. Vi har forklaret denne proces i detaljer i vores tidligere blogindlæg.
Vi håber, at dette korte blogindlæg vil hjælpe dig med at forberede dig bedre på at opgradere din Percona XtraDB Cluster til version 8.0.