MySQL 8.0 is al een tijdje beschikbaar en Percona XtraDB Cluster 8.0 is ook al een tijdje beschikbaar. Ook MySQL 5.6 nadert het einde van zijn levensduur en mensen die PXC 5.6 gebruiken, zullen binnenkort ook willen migreren naar een recentere versie. Laten we het proces eens bekijken en er enkele tips over delen.
Denk eraan, het is MySQL hieronder...
Om te beginnen moet u er rekening mee houden dat Galera slechts een plug-in is die werkt met MySQL, dus u moet ervoor zorgen dat u zich houdt aan de migratieregels en -processen voor uw specifieke MySQL-versie die wordt gebruikt in uw PXC. Als we PXC 5.7 gebruiken en u wilt upgraden naar PXC 8.0, moet u eerst alle vakjes op de MySQL-upgradechecklist aanvinken. We hebben een deel daarvan behandeld in onze blog waarin het upgradeproces tussen MySQL 5.7 en MySQL 8.0 wordt beschreven. Het betekent ook dat alleen upgradepaden die door MySQL worden ondersteund, levensvatbaar zijn - u kunt PXC 5.6 bijvoorbeeld niet rechtstreeks upgraden naar PXC 8.0 omdat een directe MySQL-upgrade van 5.6 naar 8.0 niet wordt ondersteund.
Lees de upgradedocumentatie
Zoals gewoonlijk moet u, wanneer u een upgrade plant, vertrouwd raken met de documentatie die door de leverancier is opgesteld. Percona heeft een webpagina gewijd aan het uitleggen van het upgradeproces en de waarschuwingen eromheen. We zullen enkele van die punten in deze blogpost bespreken.
Configuratiewijzigingen
Er zijn een aantal wijzigingen in de standaardconfiguratie-instellingen die problemen kunnen veroorzaken in het upgradeproces - pxc_strict_mode is standaard ingesteld op ENFORCING. Deze modus blokkeert elke vorm van configuratie die experimenteel is en de stabiliteit van het cluster kan beïnvloeden. Controles hebben onder meer betrekking op gebruikte opslagengines, binaire logindeling, het bestaan van primaire sleutels en nog een aantal andere dingen. Wanneer u een upgrade uitvoert, wilt u deze misschien op PERMISSIEF instellen om de incompatibiliteiten in het foutenlogboek bij te houden, maar laat u de PXC anders draaien, zelfs als sommige dingen niet in de beste staat zijn.
Een andere instelling, pxc_encrypt_cluster_traffic, is ook standaard ingeschakeld, waardoor versleuteling van de Galera-communicatie tussen knooppunten wordt afgedwongen. Het is niet mogelijk om knooppunten te combineren met versleutelde en niet-versleutelde knooppunten in hetzelfde cluster, daarom moet u het ofwel op alle knooppunten instellen of ervoor zorgen dat u de pxc_encrypt_cluster_traffic op de nieuwe PXC 8.0-knooppunten uitschakelt.
Wijziging in de standaard authenticatie plug-in
We hebben dit vermeld in onze blogpost over migratie naar MySQL 8.0, maar de wijziging is zo belangrijk dat we het hier ook willen herhalen - met MySQL 8.0 verandert de standaard authenticatie-plug-in in caching_sha2_password - dit kan sommige van de oudere applicaties incompatibel maken met MySQL 8.0. U kunt deze instelling natuurlijk wijzigen, maar als u er geen rekening mee houdt, kan het averechts werken nadat de upgrade is voltooid.
Upgrade-processen
Om te beginnen, houd er rekening mee dat, hoewel niet aanbevolen, het bij sommige mogelijk is om zowel PXC 5.7- als PXC 8.0-nodes in hetzelfde cluster te laten draaien. Dit opent de mogelijkheid om een in-place, live upgrade uit te voeren. Het proces zou vrij eenvoudig zijn - stop de PXC 5.7-node, upgrade deze naar PXC 8.0 door een nieuwe versie te installeren en deze te starten. In de procesdatadirectory wordt geüpgraded naar de nieuwe versie en het nieuwe PXC 8.0-knooppunt zou correct moeten kunnen starten en lid kunnen worden van het cluster. Vervolgens ga je één voor één verder met de nodes en migreer je ze van PXC 5.7 naar PXC 8.0. Houd er rekening mee dat u SST moet vermijden, aangezien een gegevensmap van PXC 8.0-knooppunt niet kan worden gebruikt op 5.7. Andersom zou goed moeten werken. Om te voorkomen dat SST plaatsvindt, moet u ervoor zorgen dat de gcache-grootte groot genoeg is om schrijfbewerkingen mogelijk te maken en IST te laten plaatsvinden. IST zelf zal prima werken.
Als je meer vrije nodes hebt, kun je de upgrade altijd uitvoeren met twee clusters op verschillende hoofdversies die parallel lopen en verbonden zijn via asynchrone replicatie. Wat belangrijk is, met een dergelijke aanpak kunt u de PXC 8.0 grondiger testen, aangezien u hem een tijdje zult gebruiken (in principe zo lang als u hem nodig heeft) en u uw toepassing op dit cluster kunt testen - op elk moment in tijd kunt u een deel van de alleen-lezen werklast naar de PXC 8.0 verplaatsen om te zien hoe query's worden afgehandeld, of er fouten of prestatieproblemen zijn.
Als u ClusterControl gebruikt, kan dit worden bereikt door de taak "Slaafcluster maken" te gebruiken.
U wordt gevraagd te beslissen waar de initiële gegevens vandaan moeten komen, meester PXC-knooppunt of van de back-up.
U moet ook de verbindingsdetails doorgeven, zoals SSH-gebruiker en sleutelpad .
Vervolgens wordt u gevraagd de leverancier en versie te kiezen - die u waarschijnlijk wilt om PXC 5.7 voorlopig te gebruiken, moet je de nodes later upgraden en het upgradeproces zelf testen.
Ten slotte moet u de knooppunthostnamen of IP-adressen voor ClusterControl doorgeven aan maak verbinding met en begin met het instellen van de knooppunten.
Als resultaat heeft u een tweede Percona XtraDB Cluster in versie 5.7 , repliceren van het oorspronkelijke cluster. Dat cluster kan worden geüpgraded naar de nieuwe versie en uiteindelijk kunt u uw verkeer ernaartoe verleggen. We hebben dit proces in detail uitgelegd in onze vorige blogpost.
We hopen dat deze korte blogpost u zal helpen om u beter voor te bereiden op het upgraden van uw Percona XtraDB Cluster naar versie 8.0.