Huvudversionsuppgradering i Azure Database for MySQL

Den här artikeln beskriver hur du uppgraderar din MySQL-huvudversion i Azure Database for MySQL – flexibel server. Den här funktionen gör det möjligt för kunder att utföra större versionsuppgraderingar (till exempel från MySQL 5.7 till 8.0 eller 8.0 till 8.4) utan att flytta data eller ändra anslutningssträngar för program.

Förutsättningar

• Läsrepliker med en äldre MySQL-version bör uppgraderas innan den primära servern för replikering ska vara kompatibel mellan olika MySQL-versioner. Läs mer om replikeringskompatibilitet mellan MySQL-versioner.
• Innan du uppgraderar dina produktionsservrar är det nu enklare och effektivare med vår inbyggda Valideringsfunktion i Azure Portal. Det här verktyget kontrollerar i förväg databasschemats kompatibilitet med MySQL-målversionen, vilket belyser potentiella problem. Även om vi erbjuder det här praktiska alternativet rekommenderar vi också starkt att du använder det officiella verktyget Oracle MySQL Upgrade checker för att testa databasschemakompatibiliteten och utföra nödvändiga regressionstester för att verifiera programkompatibiliteten med funktioner som tagits bort/inaktuella i den nya MySQL-versionen.
• Utlös säkerhetskopiering på begäran innan du utför en större versionsuppgradering på produktionsservern. Säkerhetskopior som gjorts innan uppgraderingen kan användas för att återställa till den tidigare versionen från den fullständiga säkerhetskopieringen på begäran.
• Innan du fortsätter med huvudversionsuppgraderingen kontrollerar du att det inte finns några aktiva eller väntande XA-transaktioner i databasen, eftersom pågående XA-transaktioner potentiellt kan leda till att uppgraderingsprocessen misslyckas. För att undvika det här problemet kontrollerar du först om det finns XA-transaktioner i tillståndet "förberedd" genom att köra XA RECOVER;. För alla identifierade transaktioner använder du XA ROLLBACK '{xid}'; för att återställa varje transaktion och ersätta {xid} med transaktions-ID:t. Kontrollera att alla XA-transaktioner antingen har checkats in eller återställts innan uppgraderingen initieras för att upprätthålla transaktionskonsekvensen och minska risken för uppgraderingsfel.

Utföra en planerad uppgradering av högre version med hjälp av Azure-portalen för Burstable SKU-servrar

För att utföra en större versionsuppgradering för en Azure Database for MySQL Burstable SKU-beräkningsnivå krävs ett specialiserat arbetsflöde. Större versionsuppgraderingar är resursintensiva och kräver betydande cpu och minne. Burstable SKU-instanser, som är kreditbaserade, kan kämpa under dessa krav, vilket kan leda till att uppgraderingsprocessen misslyckas. När du uppgraderar en burstbar SKU uppgraderar systemet därför först beräkningsnivån till en General-Purpose SKU för att säkerställa att tillräckliga resurser är tillgängliga för uppgraderingen.

Följ dessa steg för att utföra en större versionsuppgradering för en Azure Database for MySQL Burstable SKU-beräkningsnivå med hjälp av Azure Portal:

1. I Azure Portal väljer du din befintliga Azure Database for MySQL – flexibel serverinstans.

   Viktigt!

   Vi rekommenderar att du utför en uppgradering först på en återställd serverkopia i stället för att uppgradera produktionen direkt. Se hur du utför återställning till tidpunkt.

2. På sidan Översikt går du till verktygsfältet och väljer Uppgradera.

   Viktigt!

   Innan du uppgraderar går du till länken för listan över funktioner som tagits bort i MySQL-målversionen. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server med hjälp av bladet Serverparametrar på Azure-portalen för att undvika distributionsfel. sql_mode med värden NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS och NO_TABLE_OPTIONS stöds inte längre i MySQL 8.0 och senare.

   

3. Validering av schemakompatibilitet

   Innan du fortsätter med uppgraderingen kör du Oracles officiella MySQL Upgrade Checker-verktyg för att verifiera att ditt aktuella databasschema är kompatibelt med mySQL-målversionen. Det här steget är avgörande för att säkerställa en smidig uppgraderingsprocess.

4. Beslut före uppgradering

   Innan du uppgraderar måste du välja beräkningsnivå för att uppgradera för att utföra huvudversionsuppgradningen. Som standard uppgraderas systemet från Burstable SKU till den mest grundläggande SKU:n för generell användning, men du kan uppgradera till en högre beräkningsnivå om det behövs. Observera att medan servern körs på nivån "Generell användning" under uppgraderingen debiteras du endast för de faktiska "Generell användning"-resurser som används under den här perioden.

5. Beslut efter uppgradering

   Efter uppgraderingen bestämmer du om du vill behålla SKU:n för generell användning eller återgå till burstbar SKU. Det här valet uppmanas under de första uppgraderingsstegen.

   Systemet uppgraderar automatiskt beräkningsnivån från Burstable SKU till den valda SKU:n för generell användning för att stödja uppgraderingen av huvudversionen.

6. Huvudversionsuppgradering

   När beräkningsnivån har uppgraderats initierar systemet uppgraderingsprocessen för huvudversionen. Övervaka uppgraderingens förlopp via Azure Portal. Uppgraderingsprocessen kan ta lite tid, beroende på databasens storlek och aktivitet. Observera att om huvudversionsuppgraderingen misslyckas återgår beräkningsnivån inte automatiskt till den tidigare burstbara SKU:n. På så sätt kan kunderna fortsätta uppgraderingen av huvudversionen utan att utföra uppgraderingen av beräkningsnivån igen.

7. Automatisk omversion

   Baserat på ditt fördefinierade beslut behåller systemet antingen SKU:n för generell användning eller återställs automatiskt till Burstable SKU efter uppgraderingen. Om du automatiskt återgår till Burstable SKU återgår systemet som standard till B2S SKU.

Utföra en planerad större versionsuppgradering med hjälp av Azure-portalen för allmänna och affärskritiska SKU-servrar

Utför följande steg för att utföra en större versionsuppgradering av en flexibel Azure Database for MySQL-server med hjälp av Azure-portalen.

1. I Azure Portal väljer du din befintliga Azure Database for MySQL – flexibel serverinstans.

   Viktigt!

   Vi rekommenderar att du utför en uppgradering först på en återställd serverkopia i stället för att uppgradera produktionen direkt. Se hur du utför återställning till tidpunkt.

2. På sidan Översikt går du till verktygsfältet och väljer Uppgradera.

   Viktigt!

   Innan du uppgraderar går du till länken för listan över funktioner som tagits bort i MySQL-målversionen. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server med hjälp av bladet Serverparametrar på Azure-portalen för att undvika distributionsfel. sql_mode med värden NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS och NO_TABLE_OPTIONS stöds inte längre i MySQL 8.0 och senare.

   

3. Utföra validering före uppgradering

   Innan du fortsätter med uppgraderingen väljer du knappen Verifiera för att kontrollera serverns kompatibilitet med MySQL-målversionen.

   

   Kommentar

   Onlineverifiering stöds för närvarande inte för 8.0 till 8.4 större versionsuppgradering, kunden rekommenderas att använda community-verktyget för att utföra validering före uppgraderingen. Onlineverifiering för 8.0 till 8.4 support levereras inom en snar framtid.
   När du använder funktionen Validera för att utvärdera databasschemat för kompatibilitet med MySQL-målversionen bör du tänka på följande:

   • Tabelllåsning under validering: Valideringsprocessen omfattar låsning av tabeller för att inspektera hela schemat korrekt. Detta kan leda till tidsgränser för frågor om databasen är hårt belastad.   Rekommendation: Undvik att köra validering under hög belastning på kontorstid eller när databasen hanterar hög trafik. Schemalägg i stället valideringen under perioder med låg aktivitet för att minska påverkan på åtgärderna.
   • Potential för hängande på grund av stora resultatuppsättningar: I vissa fall, särskilt med komplexa databaser som innehåller många objekt, kan valideringsresultatet bli för stort för att bearbetas eller visas i onlinearbetsflödet. Detta kan leda till att operationen "Validate" verkar hänga eller vara i progress obestämt.   Rekommendation: Om du stöter på det här problemet rekommenderar vi att du utför verifieringen lokalt med hjälp av Oracles officiella uppgraderingskontrollverktyg på klientsidan, till exempel det som ingår i MySQL Shell. Den här metoden undviker storleksbegränsningar för resultat på plattformssidan och ger mer detaljerade och tillförlitliga valideringsutdata.
   • Rekommenderade användningsfall för onlineverifiering: Funktionen "Verifiera" online är utformad för enkla eller måttligt komplexa scheman. För storskaliga produktionsmiljöer – till exempel de med tusentals tabeller, vyer, rutiner eller andra schemaobjekt – rekommenderar vi starkt att du använder Oracles uppgraderingskontrollverktyg på klientsidan för att utföra kompatibilitetskontrollen. Detta säkerställer att det fullständiga schemat analyseras på ett omfattande sätt och undviker potentiella problem som rör resultatstorlek eller tidsgränser för validering.

4. I sidofältet Uppgradera i textrutan MySQL-version för uppgradering kontrollerar du den större MySQL-version som du vill uppgradera till (till exempel 8.0 eller 8.4).

   

   Innan du kan uppgradera den primära servern måste du först uppgradera alla associerade skrivskyddade replikservrar. Uppgraderingen är inaktiverad tills den har slutförts.

5. På den primära servern väljer du bekräftelsemeddelandet för att verifiera att alla replikservrar har uppgraderats och väljer sedan Uppgradera.

   

   Uppgradering är aktiverat som standard på skrivskyddade repliker och fristående servrar.

Utföra en planerad uppgradering av huvudversionen med hjälp av Azure CLI

Utför följande steg för att utföra en större versionsuppgradering av en flexibel Azure Database for MySQL-server med hjälp av Azure CLI.

1. Installera Azure CLI för Windows eller använd Azure CLI i Azure Cloud Shell för att köra uppgraderingskommandona.

   Den här uppgraderingen kräver Azure CLI version 2.40.0 eller senare. Om du använder Azure Cloud Shell är den senaste versionen redan installerad. Kör az version om du vill hitta versionen och de beroende bibliotek som är installerade. Om du vill uppgradera till den senaste versionen kör du az upgrade.

2. När du har loggat in kör du kommandot az MySQL server upgrade .

   az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version {target major version}
   

   Ersätt {target major version} med den version som du vill uppgradera till (till exempel 8 eller 8.4).

3. Under bekräftelseprompten skriver du y för att bekräfta eller n för att stoppa uppgraderingsprocessen och trycker sedan på Retur.

Utföra en huvudversionsuppgradering på en läsreplikserver med hjälp av Azure-portalen

Utför följande steg för att utföra en större versionsuppgradering av en flexibel Azure Database for MySQL-server med hjälp av Azure-portalen.

1. välj din befintliga flexibla Azure Database for MySQL-server och läs replikservern i Azure-portalen.

2. På sidan Översikt går du till verktygsfältet och väljer Uppgradera.

   Viktigt!

   Innan du uppgraderar går du till länken för listan över funktioner som tagits bort i MySQL-målversionen. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server med hjälp av bladet Serverparametrar på Azure-portalen för att undvika distributionsfel.

3. I avsnittet Uppgradera väljer du Uppgradera för att uppgradera en Azure Database for MySQL – flexibel server för läsreplikserver till målversionen. Ett meddelande verkar bekräfta att uppgraderingen har slutförts.

4. På sidan Översikt kontrollerar du att din Azure Database for MySQL – flexibel server för läsreplikserver kör målversionen.

5. gå till din primära server och utföra en större versionsuppgradering.

Utför minimal nedtidsuppgradering av högre version med hjälp av läsrepliker

Utför följande steg för att utföra en större versionsuppgradering av en flexibel Azure Database for MySQL-server med minimal stilleståndstid med hjälp av skrivskyddade replikservrar.

1. välj din befintliga Azure Database for MySQL Flexible Server-instans i Azure-portalen.

2. Skapa en läsreplik från den primära servern.

3. Uppgradera din läsreplik till huvudversionen av målet.

4. När du har bekräftat att replikservern kör målversionen stoppar du programmet från att ansluta till den primära servern.

5. Kontrollera replikeringsstatusen för att säkerställa att repliken har kommit ikapp den primära, så att alla data är synkroniserade och inga nya åtgärder utförs på den primära.

6. Bekräfta med kommandot visa replikstatus på replikservern för att visa replikeringsstatusen.

   SHOW SLAVE STATUS\G
   

   Om tillståndet för Slave_IO_Running och Slave_SQL_Running är ja och värdet för Seconds_Behind_Master är 0 fungerar replikeringen bra. Seconds_Behind_Master anger hur sent repliken är. Om värdet inte är 0 bearbetar repliken fortfarande uppdateringar. När du har bekräftat att värdet för Seconds_Behind_Master är 0 är det säkert att stoppa replikeringen.

7. Höj upp läsrepliken till primär genom att stoppa replikeringen.

8. Ange serverparametern read_only till 0 (OFF) för att börja skriva på den upphöjda primära.

9. Peka ditt program till den nya primära (tidigare repliken) som kör målversionen. Varje server har en unik anslutningssträng. Uppdatera programmet så att det pekar på (tidigare) repliken i stället för källan.

   Kommentar

   Det här scenariot medför endast driftstopp under steg 4 till och med 7.

Relaterat innehåll

• Uppgradera vanliga frågor och svar
• Så här konfigurerar du schemalagt underhåll
• MySQL version 8.0