Dela via

Automatisk migrering på plats från Azure Database for MySQL – enskild server till flexibel server

  • Artikel

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

Viktigt!

Vissa instanser av en enskild server kan kräva obligatoriska indata för att utföra en lyckad automatisk migrering på plats. Granska migreringsinformationen på bladet Migrering på Azure Portal för att ange dessa indata. Om du inte anger obligatoriska indata 2 dagar innan den schemalagda migreringen kommer det att leda till att migreringen schemaläggs på nytt till ett senare datum.

Automatisk migrering på plats från Azure Database for MySQL – enskild server till flexibel server är en tjänstinitierad migrering på plats under planerat underhållsperiod för databasarbetsbelastningar med enkel server med Basic, Generell användning eller minnesoptimerad SKU och inga komplexa funktioner (Read Replica, Virtual Network, Double Infra encryption, Service endpoint/VNet Rules) aktiverade. Berättigade servrar identifieras av tjänsten och får ett förhandsmeddelande med information om stegen för att granska migreringsinformationen.

Migreringen på plats ger en mycket elastisk och självåterställning offlinemigrering under ett planerat underhållsfönster, med mindre än 5 minuters stilleståndstid för Generell användning och minnesoptimerad SKU och upp till 30 minuter för Basic SKU.. Den använder säkerhetskopierings- och återställningsteknik för snabbare migreringstid. Den här migreringen tar bort kostnaderna för att migrera servern manuellt och se till att du kan dra nytta av fördelarna med flexibel server, inklusive bättre pris och prestanda, detaljerad kontroll över databaskonfiguration och anpassade underhållsfönster. Nedan beskrivs de viktigaste faserna i migreringen:

  • Flexibel målserver distribueras och ärver alla funktionsuppsättningar och egenskaper (inklusive serverparametrar och brandväggsregler) från källan Enskild server. Enskild källserver är inställd på skrivskyddad och säkerhetskopiering från källan Enskild server kopieras till målet Flexibel server.
  • DNS-växeln och snabbkopplingen utförs korrekt inom det planerade underhållsfönstret med minimal stilleståndstid, vilket möjliggör underhåll av samma anslutningssträng efter migreringen. Klientprogram ansluter sömlöst till den flexibla målservern utan några användardrivna manuella uppdateringar. Förutom att både anslutningssträng format (enkel och flexibel server) stöds på migrerad flexibel server stöds både användarnamnsformat – username@server_name och användarnamn på den migrerade flexibla servern.
  • Den migrerade flexibla servern är online och kan nu hanteras via Azure Portal/CLI. Stoppad enskild server tas bort sju dagar efter migreringen.

Kommentar

Om din enskild serverinstans har Basic SKU migreras den schemalagda instansen med ett avbrottsfönster på upp till 30 minuter. Instansen migreras till en högre Generell användning SKU för att säkerställa en lyckad migrering och skalas ned till Burstable SKU om 24–48 timmar. Om efter migreringen till Burstable SKU tar din instans slut på krediter på grund av hög CPU-arbetsbelastning, överväg att uppgradera till Generell användning SKU på den flexibla serverinstansen.

Kommentar

Om din enskild serverinstans har Generell användning V1-lagring genomgår den schemalagda instansen ytterligare en omstartsåtgärd 12 timmar före den schemalagda migreringstiden. Den här omstartsåtgärden används för att aktivera den log_bin serverparameter som behövs för att uppgradera instansen till Generell användning V2-lagring innan du genomgår den automatiska migreringen på plats.

Berättigande

Om du äger en enskild serverarbetsbelastning utan komplexa funktioner (Read Replica, Virtual Network, Double Infra encryption, Service Endpoint/VNet Rules) aktiverad kan du nu nominera dig själv (om den inte redan har schemalagts av tjänsten) för automatisk migrering genom att skicka serverinformationen via ett Azure-supportärende.

Utför följande steg för att göra din icke berättigade server berättigad till automatisk migrering:

  • Instansen för enskild server ska vara i klart tillstånd och bör inte vara i stoppat tillstånd under det planerade underhållsfönstret för automatisk migrering.
  • Om din källa i Azure Database for MySQL – enskild server har motorversion v8.x måste du uppgradera källserverns .NET-klientdrivrutinsversion till 8.0.32 för att undvika kodningskompatibiliteter efter migreringen till flexibel server.
  • Om källan Azure Database for MySQL Single Server har motorversion v8.x måste du uppgradera källserverns TLS-version från v1.0 eller v1.1 till TLS v1.2 innan migreringen eftersom de äldre TLS-versionerna har blivit inaktuella för flexibel server.
  • Om servern har läsrepliker släpper du Läsrepliker. Du kan konfigurera Skrivskyddade repliker efter automatisk migrering.
  • Om servern har tjänstslutpunkter (VNet-regler) eller konfiguration av virtuellt nätverk aktiverat kan du överväga att ta bort dem eller flytta till funktionen Private Link på din enskild serverinstans.
  • Om dubbel infrastrukturkryptering är aktiverad på servern kan du överväga att flytta till funktionen Kundhanterad nyckel (CMK) på din enskild serverinstans.

Konfigurera migreringsaviseringar

Servrar som är berättigade till automatisk migrering på plats skickas ett förhandsmeddelande från tjänsten.

Nedan beskrivs hur du kontrollerar och konfigurerar meddelanden om automatisk migrering:

  • Prenumerationsägare för enskilda servrar som är schemalagda för automatisk migrering får ett e-postmeddelande.
  • Konfigurera tjänsthälsoaviseringar för att ta emot migreringsschema på plats och förloppsaviseringar via e-post/SMS genom att följa stegen här.
  • Kontrollera migreringsmeddelandet på plats på Azure Portal genom att följa stegen här.

Granska och konfigurera migreringsschema och information

Nedan beskrivs hur du granskar migreringsschemat när du får meddelandet om automatisk migrering på plats:

Kommentar

Migreringsschemat är låst två dagar före det schemalagda migreringsfönstret, varefter du inte kan schemalägga om.

  • Översiktssidan för en enskild server för din instans visar en portalbanderoll med information om ditt migreringsschema.

  • För enskilda servrar som är schemalagda för automatisk migrering tänds ett nytt migreringsblad på portalen. Du kan granska migreringsschemat genom att gå till bladet Migrering för instansen av enskild server.

  • Om du vill skjuta upp migreringen kan du skjuta upp migreringen med en månad i taget genom att gå till migreringsbladet för din enskild serverinstans på Azure Portal och schemalägga migreringen igen genom att välja ett annat migreringsfönster inom en månad.

  • Om din enskild server har Generell användning SKU har du det andra alternativet för att aktivera hög tillgänglighet när du granskar migreringsschemat. Eftersom hög tillgänglighet endast kan aktiveras under skapandetiden för en flexibel MySQL-server rekommenderar vi starkt att du aktiverar den här funktionen när du granskar migreringsschemat.

  • Om din enskild serverinstans har en eller flera Av Private Link, Kundhanterad nyckel (CMK) och Microsoft Entra Admin aktiverat, kräver automatisk migrering på plats obligatoriska indata för att de privata slutpunkterna, CMK och Microsoft Entra Admin ska migreras från din enskild serverinstans till målinstansen för flexibel server. Användarens indata måste anges två dagar före det schemalagda migreringsfönstret. Om användarens indata inte tillhandahålls innan migreringsinformationen är låst schemaläggs migreringen till en senare tidpunkt. När du har angett alla indata måste du spara konfigurationen i guiden för automatisk migrering. Steg för att ange användarindata:

    • Gå till migreringsbladet för din enskild serverinstans och välj redigera schemalagd migrering.
    • I avsnittet Information om automatisk migrering klickar du på knappen Autentisera för att autentisera och spara ARM API-anslutningen för att migrera servern.
    • Om din server har konfigurerat Microsoft Entra Admin kan du ange indata under avsnittet Microsoft Entra Admin i guiden automatisk migrering:
      • Om du migrerar Microsoft Entra-administratören för målservern måste en identitet läggas till i Azure Database for MySQL – flexibel server. Identiteten kräver att följande behörigheter – User.Read.All, GroupMember.Read.All och Application.Read.All beviljas. Välj en lämplig användartilldelad hanterad identitet och bevilja rätt behörigheter genom att följa stegen här.
    • Om din server har konfigurerat kundhanterad nyckel kan du ange indata under avsnittet Datakryptering i guiden automatisk migrering:
      • För att migrera kundhanterad nyckelkryptering krävs att en identitet läggs till i Azure Database for MySQL – flexibel server. Välj en lämplig användartilldelad hanterad identitet. Den listade nyckelidentifieraren/nyckeln migreras från källan till målservern och bör beviljas följande behörigheter – Hämta, Omsluta nyckel, Packa upp nyckel för att få åtkomst till nyckelvalvet.
    • Om din enskild server har privata slutpunkter utför du följande obligatoriska steg när du granskar migreringsschemat minst 2 dagar före den schemalagda migreringen:
      • Granska de privata slutpunkter som anges för migrering. Se till att de är markerade som Redo att migrera. Om de har markerats som ej berättigade väljer du lämplig prenumeration och privat DNS-zon.
        • Anpassad Privat DNS zon stöds inte av automatisk migrering. Zonen Privat DNS måste vara privatelink.mysql.database.azure.com.
        • Metoden för godkännande av privata slutpunkter bör anges som automatiskt godkännande och inte manuellt godkännande. Privata slutpunkter för manuellt godkännande stöds inte av automatisk migrering.
      • Se till att du har rollen Deltagare på prenumerationsnivå eller resursgruppsnivå för att undvika eventuella behörighetsproblem när du autentiserar.
      • Markera kryssrutan bekräftelse när du har utfört de angivna nödvändiga kontrollerna för migrering av privata slutpunkter.

    Kommentar

    Om de obligatoriska indata för migrering inte tillhandahålls minst 2 dagar före den schemalagda migreringen schemaläggs migreringen om till ett senare datum.

    Kommentar

    För enskild serverinstans med privata slutpunkter tar du bort källinstansen för enskild server efter migreringsverifieringen. Om ingen serverborttagningsåtgärd utförs underhålls källinstansen tills 14 dagar efter vilken den tas bort av tjänsten.

Kravkontroller för automatisk migrering på plats

Granska följande förutsättningar för att säkerställa en lyckad automatisk migrering på plats:

  • Instansen för enskild server ska vara i klart tillstånd och bör inte vara i stoppat tillstånd under det planerade underhållsfönstret för automatisk migrering.
  • Den enskilda serverinstansens serverparametrar, inställningar, konfiguration och brandväggsregler bör inte uppdateras under tvådagarsperioden före den schemalagda automatiska migreringen.
  • För enskild serverinstans med SSL aktiverat kontrollerar du att du har alla tre certifikaten (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA och DigiCertGlobalRootCA Root CA) tillgängliga i det betrodda rotarkivet. Om du har certifikatet fäst på anslutningssträng skapa ett kombinerat CA-certifikat med alla tre certifikaten före schemalagd automatisk migrering för att säkerställa affärskontinuitet efter migreringen.
  • MySQL-motorn garanterar ingen sorteringsordning om det inte finns någon SORT-sats i frågor. Efter automigration på plats kan du observera en ändring i sorteringsordningen. Om det är viktigt att bevara sorteringsordningen kontrollerar du att dina frågor uppdateras så att de innehåller SORT-satsen före den schemalagda automatiska migreringen på plats.
  • Om din källa i Azure Database for MySQL – enskild server har motorversion v8.x måste du uppgradera källserverns .NET-klientdrivrutinsversion till 8.0.32 för att undvika kodningskompatibiliteter efter migreringen till flexibel server.
  • Om källan Azure Database for MySQL Single Server har motorversion v8.x måste du uppgradera källserverns TLS-version från v1.0 eller v1.1 till TLS v1.2 innan migreringen eftersom de äldre TLS-versionerna har blivit inaktuella för flexibel server.
  • Om källan Azure Database for MySQL Single Server har brandväggsregelnamn som överstiger 80 tecken byter du namn på dem för att säkerställa att namnlängden är färre än 80 tecken. (Namnlängden för brandväggsregeln som stöds på flexibel server är 80 tecken medan den tillåtna längden är 12 8 tecken på enskild server.)
  • Om källan Azure Database for MySQL – enskild server använder nondefault-portar som 3308 3309 och 3310 ändrar du anslutningsporten till 3306 eftersom ovanstående nondefault-portar inte stöds på flexibel server.

Hur är målet MySQL – flexibel server automatiskt avetablerad?

Beräkningsnivån och SKU:n för den flexibla målservern etableras baserat på den enskilda källserverns prisnivå och virtuella kärnor baserat på informationen i följande tabell.

Prisnivå för enskild server Virtuella kärnor för enskild server Flexibel servernivå SKU-namn för flexibel server
Grundläggande 1 Burstbar Standard_B1s
Grundläggande 2 Burstbar Standard_B2s
Generell användning 2 GeneralPurpose Standard_D2ds_v4
Generell användning 4 GeneralPurpose Standard_D4ds_v4
Generell användning 8 GeneralPurpose Standard_D8ds_v4
Generell användning 16 GeneralPurpose Standard_D16ds_v4
Generell användning 32 GeneralPurpose Standard_D32ds_v4
Generell användning 64 GeneralPurpose Standard_D64ds_v4
Minnesoptimerad 4 MemoryOptimized Standard_E4ds_v4
Minnesoptimerad 8 MemoryOptimized Standard_E8ds_v4
Minnesoptimerad 16 MemoryOptimized Standard_E16ds_v4
Minnesoptimerad 32 MemoryOptimized Standard_E32ds_v4
  • MySQL-versionen, regionen, *lagringsstorleken, prenumerationen och resursgruppen för den flexibla målservern är samma som för källans enskild server.
  • För enskilda servrar med mindre än 20 GiB-lagring anges lagringsstorleken till 20 GiB eftersom det är den minsta lagringsgränsen för Azure Database for MySQL – flexibel server.
  • Båda användarnamnsformaten – username@server_name (enskild server) och användarnamn (flexibel server) stöds på den migrerade flexibla servern.
  • Både anslutningssträng format – enskild server och flexibel server stöds på den migrerade flexibla servern.
  • För enskild serverinstans med Query Store aktiverat är serverparametern "slow_query_log" på målinstansen inställd på PÅ för att säkerställa funktionsparitet vid migrering till flexibel server. För vissa arbetsbelastningar kan detta påverka prestanda och om du ser någon prestandaförsämring anger du den här serverparametern till "OFF" på den flexibla serverinstansen.

Steg efter migrering

Här är den information du behöver veta efter migreringen på plats:

Kommentar

Starta inte om den stoppade instansen av en enskild server efter migreringen eftersom det kan hämma klient- och programanslutningen.

  • Kopiera följande egenskaper från källans enskild server för att rikta migreringen till flexibel server efter att migreringen på plats har slutförts:
    • Inställningar för övervakningssidor (aviseringar, mått och diagnostikinställningar) och låsinställningar
    • Alla Terraform-/CLI-skript som du är värd för för att hantera en enskild serverinstans bör uppdateras med referenser för flexibel server.
  • För enskild serverinstans med Query Store aktiverat är serverparametern "slow_query_log" på målinstansen inställd på PÅ för att säkerställa funktionsparitet vid migrering till flexibel server. Observera att för vissa arbetsbelastningar kan detta påverka prestanda och om du ser någon prestandaförsämring anger du den här serverparametern till "OFF" på den flexibla serverinstansen.
  • För enskild serverinstans med privata slutpunkter tar du bort källinstansen för enskild server efter migreringsverifieringen. Om ingen serverborttagningsåtgärd utförs underhålls källinstansen tills 14 dagar efter vilken den tas bort av tjänsten.
  • För enskild serverinstans med Microsoft Defender för molnet aktiverat migreras aktiveringstillståndet. Om du vill uppnå paritet i Flexibel server efter automigration för egenskaper som du kan konfigurera i Enskild server bör du överväga informationen i följande tabell:
Property Konfiguration
Ignorera specifika aviseringstyper Inaktivera specifika aviseringstyper med Microsoft Defender för molnet-plattformen. Mer information finns i Guiden Förhindra aviseringar från Microsoft Defender för molnet.

Användare med enskild server kan använda API-egenskapen:
properties.disabledAlerts
E-postmeddelanden Definiera e-postavisering för Microsoft Defender för molnet-aviseringar för alla resurser i en prenumeration. Mer information finns i Konfigurera e-postaviseringar för säkerhetsaviseringar.

Användare med enskild server kan använda API-egenskaperna:
properties.emailAccountAdmins,
properties.emailAddresses
Exportera aviseringar för vidare bearbetning och/eller arkivering Aviseringar lagras på Microsoft Defender för molnet-plattformen och exponeras via Azure Resource Graph.
Du kan exportera aviseringar till ett annat lager och hantera kvarhållning separat. Mer information finns i Konfigurera kontinuerlig export i Azure Portal – Microsoft Defender för molnet.

Användare med enskild server kan använda API-egenskaperna:
properties.retentionDays,
properties.storageAccountAccessKey,
properties.storageEndpoint

Vanliga frågor (FAQ)

F. Varför migreras jag automatiskt?

A. Din Azure Database for MySQL – instans av enskild server är berättigad till migrering på plats till vår flaggskeppsprodukt Azure Database for MySQL – flexibel server. Denna migrering på plats tar bort omkostnaderna för att manuellt migrera servern och säkerställer att du kan dra nytta av fördelarna med flexibel server, inklusive bättre prisprestanda, detaljerad kontroll över databaskonfigurationen och anpassade underhållsperioder.

F. Hur sker den automatiska migreringen? Vad migrerar allt?

A. Den flexibla servern etableras så att den matchar samma virtuella datorer och lagring som den enskilda servern. Sedan stoppas den enskilda källservern, ögonblicksbilden av datafilen tas och kopieras till den flexibla servern. DNS-växlingen utförs för att dirigera alla befintliga anslutningar till målet och den flexibla målservern aktiveras. Automatisk migrering migrerar hela serverns datafiler (inklusive schema, data, inloggningar) utöver serverparametrar (alla ändrade serverparametrar på källan kopieras till målet, oförändrade serverparametrar tar upp standardvärdet som definieras av flexibel server) och brandväggsregler. Detta är en offlinemigrering där du ser driftstopp på upp till 5 minuter eller mindre.

F. Hur kan jag konfigurera eller visa migreringsaviseringar på plats?

A. Så här kan du konfigurera aviseringar:

  • Konfigurera tjänsthälsoaviseringar för att ta emot migreringsschema på plats och förloppsaviseringar via e-post/SMS genom att följa stegen här.
  • Kontrollera migreringsmeddelandet på plats på Azure Portal genom att följa stegen här.

F. Hur kan jag skjuta upp den schemalagda migreringen?

A. Du kan granska migreringsschemat genom att gå till bladet Migrering för instansen av enskild server. Om du vill skjuta upp migreringen kan du skjuta upp med högst en månad genom att gå till migreringsbladet för din enskild serverinstans på Azure Portal och schemalägga migreringen igen genom att välja ett annat migreringsfönster inom en månad. Migreringsinformationen är låst sju dagar före det schemalagda migreringsfönstret, varefter du inte kan schemalägga om. Denna migrering på plats kan skjutas upp varje månad fram till den 16 september 2024.

F. Vilket användarnamn och vilken anslutningssträng stöds för den migrerade flexibla servern? ​​

A. Både användarnamnsformat – username@server_name (enkel serverformat) och användarnamn (format för flexibel server) stöds för den migrerade flexibla servern, och därför behöver du inte uppdatera dem för att behålla programkontinuiteten efter migreringen. Dessutom stöds både anslutningssträng format (enkel och flexibel server) för den migrerade flexibla servern.

F. Hur aktiverar jag HA (hög tillgänglighet) för min automatiskt migrerade server??

A. Som standard konfigurerar automatisk migrering en migrering till en icke-HA-instans. Eftersom HA endast kan aktiveras när servern skapas bör du aktivera HA före den schemalagda automigrationen med redigeringsalternativet för schemaschema för automatisk migrering på portalen. HA kan endast aktiveras för Generell användning\Minnesoptimerade SKU:er på flexibel målserver eftersom basic-till-burst-SKU-migrering inte stöder HA-konfiguration.

F. Jag ser en prisskillnad på min potentiella övergång från MySQL Basic – enskild server till MySQL – flexibel server??

A. Få servrar kan se en liten prisökning efter migreringen (uppskattade kostnader kan ses genom att välja alternativet för automatisk migreringsschemaredigering på portalen), eftersom den minsta lagringsgränsen för båda erbjudandena skiljer sig (5 GiB på enskild server, 20 GiB på flexibel server) och lagringskostnaden (0,1$ på enskild server; 0,115$ på flexibel server) för flexibel server är något högre än enskild server. För berörda servrar ger den här prisökningen i flexibel server bättre dataflöde och prestanda jämfört med enskild server.

Relaterat innehåll