Större versionsuppgradering i Azure Database for MySQL – flexibel server

GÄLLER FÖR: Azure Database for MySQL – flexibel server

Kommentar

Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

Den här artikeln beskriver hur du kan uppgradera mySQL-huvudversionen på plats i Azure Database for MySQL – flexibel server. Den här funktionen gör det möjligt för kunder att utföra uppgraderingar på plats av sina MySQL 5.7-servrar till MySQL 8.0 utan någon dataflytt eller behovet av att göra några program anslutningssträng ändringar.

Viktigt!

• Stilleståndstiden varierar beroende på storleken på databasinstansen och antalet tabeller som den innehåller.
• När du initierar en större versionsuppgradering för Azure Database for MySQL – flexibel server via Rest API eller SDK bör du undvika att ändra andra egenskaper för tjänsten i samma begäran. Samtidiga ändringar är inte tillåtna och kan leda till oavsiktliga resultat eller fel i begäranden. Utför egenskapsändringar i separata åtgärder efter uppgraderingen.
• Vissa arbetsbelastningar kanske inte uppvisar förbättrade prestanda efter uppgradering från 5.7 till 8.0. Vi rekommenderar att du utvärderar arbetsbelastningens prestanda genom att först skapa en replikserver (som en testserver), sedan befordra den till en fristående server och sedan köra arbetsbelastningen på testservern innan du implementerar uppgraderingen i en produktionsmiljö.
• Det går inte att uppgradera den större MySQL-versionen. Distributionen kan misslyckas om verifieringen ser att servern har konfigurerats med funktioner som ska tas bort eller som är inaktuella. Du kan göra nödvändiga konfigurationsändringar på servern och försöka uppgradera igen.

Förutsättningar

• Read Replicas with MySQL version 5.7 should be upgraded before Primary Server for replication to be compatible between different MySQL versions, read more on Replication Compatibility between MySQL versions .
• 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 8.0, 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 regressionstest för att verifiera programkompatibiliteten med funktioner som tagits bort/inaktuella i den nya MySQL-versionen.

  Kommentar

  När du använder Oracles officiella verktyg för att kontrollera schemakompatibiliteten kan du stöta på några varningar som anger oväntade token i lagrade procedurer, till exempel: mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode Du kan ignorera dessa varningar på ett säkert sätt. De refererar till inbyggda lagrade procedurer med prefixet mysql., som används för att stödja Azure MySQL-funktioner. Dessa varningar påverkar inte funktionerna i databasen.

• Utlös säkerhetskopiering på begäran innan du utför en större versionsuppgradering på produktionsservern, som kan användas för att återställa till version 5.7 från den fullständiga säkerhetskopieringen på begäran.

Utför en planerad uppgradering av huvudversionen från MySQL 5.7 till MySQL 8.0 med hjälp av Azure Portal för SKU-servrar som kan bristas

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. Detta beror på att större versionsuppgraderingar är resursintensiva och kräver betydande cpu och minne. Burstable SKU-instanser som är kreditbaserade kan ha svårt att uppfylla 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 Generell användning 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 flexibla Server 5.7-server i Azure Database for MySQL.

   Viktigt!

   Vi rekommenderar att du uppgraderar först på en återställd kopia av servern 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 besök länken för lista över funktioner som tagits bort i MySQL 8.0. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server 5.7-server med hjälp av bladet Serverparametrar på Azure Portal 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.

   

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 8.0. Det här steget är avgörande för att säkerställa en smidig uppgraderingsprocess.

4. Beslut före uppgradering

   Innan du fortsätter med uppgraderingen måste du välja den beräkningsnivå som du vill uppgradera till för att utföra uppgraderingen av huvudversionen. Som standard uppgraderar systemet från Burstable SKU till den mest grundläggande Generell användning SKU, men du kan välja att uppgradera till en högre beräkningsnivå om det behövs.

   Kommentar

   Medan servern fungerar på nivån "Generell användning" under uppgraderingen debiteras du endast för de faktiska "Generell användning"-resurserna som användes under den här perioden.

5. Beslut efter uppgradering

   Bestäm om du vill behålla Generell användning SKU eller återgå till Burstable SKU efter uppgraderingen. Det här valet uppmanas under de första uppgraderingsstegen.

   Systemet uppgraderar automatiskt beräkningsnivån från Burstable SKU till den valda Generell användning SKU stöder 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.

   Kommentar

   Om uppgraderingen av huvudversionen misslyckas återgår beräkningsnivån inte automatiskt till den tidigare burstbara SKU:n. Detta gör att kunderna kan fortsätta uppgraderingen av huvudversionen utan att behöva utföra uppgraderingen på beräkningsnivån igen.

7. Automatisk omversion

   Baserat på ditt beslut före uppgraderingen behåller systemet antingen den Generell användning SKU:n eller återgår automatiskt till Burstable SKU när uppgraderingen är klar.

   Kommentar

   Om du väljer att automatiskt återgå till Burstable SKU återgår systemet som standard till B2S SKU.

Utför en planerad uppgradering av huvudversionen från MySQL 5.7 till MySQL 8.0 med hjälp av Azure Portal för Generell användning- och Affärskritisk SKU-servrar

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

1. I Azure Portal väljer du din befintliga flexibla Server 5.7-server i Azure Database for MySQL.

   Viktigt!

   Vi rekommenderar att du uppgraderar först på en återställd kopia av servern 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 besök länken för lista över funktioner som tagits bort i MySQL 8.0. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server 5.7-server med hjälp av bladet Serverparametrar på Azure Portal 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.

   

3. Utföra validering före uppgradering

   Innan du fortsätter med uppgraderingen klickar du på knappen Verifiera för att kontrollera serverns kompatibilitet med MySQL 8.0.

   

   Viktigt!

   När du använder funktionen Verifiera för att kontrollera databasschemat för kompatibilitet med MySQL 8.0 bör du tänka på att det innebär att du låser tabellerna för att utvärdera hela schemat korrekt. Den här processen kan leda till tidsgränser för frågor. Därför rekommenderar vi att du inte utför validering under hög belastning på kontorstid eller när databasen har hög trafik. Om du väljer en period med låg aktivitet för validering kan du minimera påverkan på dina åtgärder.

4. I sidofältet Uppgradera i textrutan MySQL-version för uppgradering kontrollerar du den större MySQL-version som du vill uppgradera till, dvs. 8.0.

   

   Innan du kan uppgradera den primära servern måste du först ha uppgraderat alla associerade skrivskyddade replikservrar. Uppgraderingen inaktiveras 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.

   

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

Utföra en planerad huvudversionsuppgradering från MySQL 5.7 till MySQL 8.0 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 5.7-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 version 2.40.0 eller senare av Azure CLI. 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 8
   

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ör en huvudversionsuppgradering från MySQL 5.7 till MySQL 8.0 på en läsreplikserver med hjälp av Azure Portal

Utför följande steg för att utföra en större versionsuppgradering av en flexibel Azure Database for MySQL-server 5.7-server till MySQL 8.0 på en läsreplik med hjälp av Azure Portal.

1. I Azure Portal väljer du din befintliga azure database for MySQL– flexibel server 5.7 läsreplikserver.

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

Viktigt!

Innan du uppgraderar besök länken för lista över funktioner som tagits bort i MySQL 8.0. Kontrollera inaktuella sql_mode värden och ta bort/avmarkera dem från din aktuella flexibla Azure Database for MySQL-server 5.7-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 flexibel Server 5.7-replikserver för Azure Database for MySQL till MySQL 8.0.

   Ett meddelande verkar bekräfta att uppgraderingen har slutförts.

4. På sidan Översikt kontrollerar du att den flexibla skrivskyddade replikservern i Azure Database for MySQL är version 8.0.

5. Gå nu till den primära servern och utför uppgradering av huvudversioner på den.

Utför minimal versionsuppgradering av driftstopp från MySQL 5.7 till MySQL 8.0 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 5.7-server till MySQL 8.0 med minimal stilleståndstid med hjälp av skrivskyddade replikservrar.

1. I Azure Portal väljer du din befintliga flexibla Server 5.7-server i Azure Database for MySQL.

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

3. Uppgradera din läsreplik till version 8.0.

4. När du har bekräftat att replikservern kör version 8.0 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 att 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 **** ä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å upphöjd primär.

9. Peka programmet på den nya primära (tidigare repliken) som kör server 8.0. 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.

Vanliga frågor och svar

• Kommer detta att orsaka stilleståndstid för servern och i så fall hur länge?

  Om du vill ha minimal stilleståndstid under uppgraderingar följer du stegen som anges under Utför minimal nedtid större versionsuppgradering från MySQL 5.7 till MySQL 8.0 med hjälp av läsrepliker. Servern kommer inte att vara tillgänglig under uppgraderingsprocessen, så vi rekommenderar att du utför den här åtgärden under fönstret planerat underhåll. Den uppskattade stilleståndstiden beror på databasens storlek, den etablerade lagringsstorleken (etablerade IOP:er) och antalet tabeller i databasen. Uppgraderingstiden är direkt proportionell mot antalet tabeller på servern. För att beräkna driftstoppet för servermiljön rekommenderar vi att du först uppgraderar den återställde kopian av servern.

• Vad händer med mina säkerhetskopior efter uppgraderingen?

  Alla säkerhetskopior (automatiserade/på begäran) som görs före huvudversionsuppgradering, när de används för återställning, återställs alltid till en server med äldre version (5.7). Alla säkerhetskopior (automatiserade/på begäran) som görs efter huvudversionsuppgradering återställs till servern med uppgraderad version (8.0). Vi rekommenderar starkt att du säkerhetskopierar på begäran innan du utför uppgraderingen av huvudversionen för en enkel återställning.

• Jag använder för närvarande Burstable SKU, planerar Microsoft att stödja större versionsuppgradering för denna SKU i framtiden?

  Burstbar SKU kan inte stödja större versionsuppgradering på grund av prestandabegränsningen för den här SKU:n.

  Om du behöver utföra en större versionsuppgradering på din flexibla Azure Database for MySQL-serverinstans och för närvarande använder Burstable SKU, skulle en tillfällig lösning vara att uppgradera till Generell användning eller Affärskritisk SKU, utföra uppgraderingen och sedan växla tillbaka till Burstable SKU.

  Observera att uppgradering till en högre SKU kan innebära en ändring av prissättningen och kan leda till ökade kostnader för distributionen. Men eftersom uppgraderingsprocessen inte förväntas ta lång tid bör de extra kostnaderna inte vara betydande.

Nästa steg

• Läs mer om hur du konfigurerar schemalagt underhåll för azure database for MySQL– flexibel serverinstans.
• Läs mer om nyheter i MySQL version 8.0.