MySQL 8.0 har varit tillgängligt ett tag och Percona XtraDB Cluster 8.0 har också varit tillgängligt ett tag. Dessutom närmar sig MySQL 5.6 sitt slut och personer som använder PXC 5.6 kommer också att vilja migrera till en nyare version snart. Låt oss ta en titt på processen och dela med oss av några tips kring den.
Kom ihåg att det är MySQL Underneath...
Till att börja med måste du komma ihåg att Galera bara är ett plugin som fungerar med MySQL så du måste se till att du följer migreringsreglerna och processerna för just din MySQL-version som används i din PXC. Om vi kör PXC 5.7 och du vill uppgradera till PXC 8.0, måste du först markera alla rutorna på MySQL-uppgraderingschecklistan. Vi tog upp en del av det i vår blogg som beskriver uppgraderingsprocessen mellan MySQL 5.7 och MySQL 8.0. Det betyder också att endast uppgraderingsvägar som stöds av MySQL är genomförbara - till exempel kan du inte uppgradera PXC 5.6 direkt till PXC 8.0 eftersom direkt MySQL-uppgradering från 5.6 till 8.0 inte stöds.
Läs uppgraderingsdokumentationen
Som vanligt, när du planerar en uppgradering bör du bekanta dig med dokumentationen som utarbetats av leverantören. Percona har en webbsida dedikerad till att förklara uppgraderingsprocessen och varningar kring den. Vi kommer att gå över några av dessa punkter i det här blogginlägget.
Konfigurationsändringar
Det finns ett par ändringar i standardkonfigurationsinställningarna som kan utlösa problem i uppgraderingsprocessen - pxc_strict_mode är inställt på ENFORCING som standard. Detta läge blockerar alla typer av konfigurationer som är experimentella och kan påverka klustrets stabilitet. Kontroller omfattar bland annat använda lagringsmotorer, binärt loggformat, förekomst av primärnycklar och en del annat. När du uppgraderar kanske du vill ställa in den på TILLGÄNGLIG för att spåra inkompatibiliteterna i felloggen men annars låta PXC köras även om vissa saker inte är i bästa skick.
En annan inställning, pxc_encrypt_cluster_traffic, är också aktiverad som standard, vilket tvingar fram kryptering av Galera-kommunikationen mellan noder. Det är inte möjligt att blanda noder med krypterade och okrypterade noder i samma kluster, därför måste du antingen ställa in det på alla noder eller se till att du inaktiverar pxc_encrypt_cluster_traffic på de nya PXC 8.0-noderna.
Ändra standardinsticksprogrammet för autentisering
Vi nämnde detta i vårt blogginlägg om migrering till MySQL 8.0, men ändringen är så viktig att vi vill upprepa den här också - med MySQL 8.0 ändras standardinsticksprogrammet för autentisering till caching_sha2_password - detta kan göra några av de äldre applikationerna inkompatibla med MySQL 8.0. Naturligtvis kan du ändra den här inställningen men om du inte tar det i beaktande kan det slå tillbaka efter att uppgraderingen är klar.
Uppgraderingsprocesser
Tänk till att börja med att, även om det inte rekommenderas, med vissa är det möjligt att ha både PXC 5.7 och PXC 8.0-noder som körs i samma kluster. Detta öppnar en möjlighet att göra en live-uppgradering på plats. Processen skulle vara ganska enkel - stoppa PXC 5.7-noden, uppgradera den till PXC 8.0 genom att installera en ny version och starta den. I processen kommer datakatalogen att uppgraderas till den nya versionen och den nya PXC 8.0-noden bör kunna starta ordentligt och gå med i klustret. Sedan fortsätter du med noderna en efter en och migrerar dem från PXC 5.7 till PXC 8.0. Tänk på att du bör undvika SST eftersom en datakatalog från PXC 8.0-noden inte kan användas på 5.7. Tvärtom borde fungera ok. För att förhindra SST från att inträffa, se till att gcache-storleken är tillräckligt stor för att rymma skrivningar och tillåta IST att hända. IST själv kommer att fungera bra.
Om du har fler lediga noder kan du alltid utföra uppgraderingen med två kluster på olika huvudversioner som körs parallellt och anslutna genom asynkron replikering. Vad som är viktigt, ett sådant tillvägagångssätt låter dig testa PXC 8.0 mer noggrant eftersom du kommer att ha den igång ett tag (i princip så länge du behöver den) och du kan testa din applikation på detta kluster - när som helst i gång kan du flytta en del av den skrivskyddade arbetsbelastningen till PXC 8.0 och se hur frågor hanteras, om det finns några fel eller prestandaproblem.
Om du använder ClusterControl kan detta åstadkommas genom att använda jobbet "Skapa slavkluster".
Du kommer att bli ombedd att bestämma varifrån de ursprungliga uppgifterna ska komma, master PXC-nod eller från säkerhetskopian.
Du måste också skicka anslutningsinformation som SSH-användare och nyckelsökväg .
Då blir du ombedd att välja leverantör och version - du vill förmodligen för att använda PXC 5.7 för tillfället kommer du att uppgradera noderna senare och testa själva uppgraderingsprocessen.
Slutligen måste du skicka nodvärdnamnen eller IP-adresserna för ClusterControl till anslut till och börja ställa in noderna.
Som ett resultat kommer du att ha ett andra Percona XtraDB-kluster som körs i version 5.7 , replikerar från det ursprungliga klustret. Det klustret kan uppgraderas till den nya versionen och så småningom kan du byta trafik mot det. Vi har förklarat denna process i detalj i vårt tidigare blogginlägg.
Vi hoppas att detta korta blogginlägg hjälper dig att förbereda dig bättre för att uppgradera ditt Percona XtraDB-kluster till version 8.0.