Migrera MySQL lokalt till Azure Database for MySQL: Assessment
Att utvärdera migreringen av MySQL-databaser från lokala miljöer till Azure Database for MySQL är ett viktigt första steg för att säkerställa en smidig och lyckad övergång. I den här artikeln går vi igenom de viktigaste faktorerna och övervägandena i utvärderingsfasen. Du kan fatta välgrundade beslut som överensstämmer med organisationens mål genom att utvärdera din nuvarande infrastruktur, identifiera potentiella utmaningar och förstå fördelarna med Azures hanterade databastjänster. Oavsett om du vill förbättra prestanda, förbättra skalbarheten eller minska driftskostnaderna, ger den här guiden dig de insikter som behövs för att effektivt planera och genomföra din migreringsstrategi.
Förutsättningar
Migrera MySQL lokalt till Azure Database for MySQL: Representativt användningsfall
Översikt
Innan du börjar migrera en MySQL-arbetsbelastning finns det en hel del due diligence som måste utföras. Detta omfattar analys av data, värdmiljö och programarbetsbelastningar för att verifiera att Azure Landing-zonen är korrekt konfigurerad och förberedd för att vara värd för de snart migrerade arbetsbelastningarna.
Begränsningar
Azure Database for MySQL är en version som stöds fullt ut av MySQL Community Edition som körs som en plattform som en tjänst. Det finns dock vissa begränsningar att bekanta sig med när du gör en första utvärdering.
Det viktigaste är bland annat:
Stöd för lagringsmotor för
InnoDBochMemoryendastBegränsat
Privilegestöd (DBA,SUPER,DEFINER)Inaktiverade datamanipuleringsinstruktioner (
SELECT ... INTO OUTFILE,LOAD DATA INFILE)Automatisk betydande databasmigrering (5.6 till 5.7, 5.7 till 8.0)
När du använder MySQL Server User Defined Functions (UDF:er) är det enda fungerande värdalternativet virtuella Azure-värddatorer, eftersom det inte finns någon möjlighet att ladda upp komponenten
soellerdlltill Azure Database for MySQL.
Många av de andra objekten är operativa aspekter som administratörer bör bekanta sig med som en del av livscykelhanteringen för driftdataarbetsbelastning. Den här guiden utforskar många av dessa operativa aspekter i avsnittet Hantering efter migrering.
MySQL-versioner
MySQL har en omfattande historia från och med 1995. Sedan dess har det utvecklats till ett allmänt använt databashanteringssystem. Azure Database for MySQL började med stöd för MySQL version 5.6 och har fortsatt till 5.7 och nyligen 8.0. Det senaste om stöd för Azure Database for MySQL-version finns i Azure Database for MySQL-serverversioner som stöds. I avsnittet Hantering efter migrering granskar vi hur uppgraderingar (till exempel 5.7.20 till 5.7.21) tillämpas på MySQL-instanserna i Azure.
Kommentar
Hoppet från 5.x till 8.0 berodde till stor del på Oracle-förvärvet av MySQL. Om du vill läsa mer om MySQL-historiken går du till Sidan MySQL-wiki.
Det är viktigt att känna till mySQL-källans version. De program som använder systemet kan använda databasobjekt och funktioner som är specifika för den versionen. Om du migrerar en databas till en lägre version kan det orsaka kompatibilitetsproblem och funktionsförlust. Vi rekommenderar också att data- och programinstansen testas noggrant innan de migreras till en nyare version eftersom de funktioner som introduceras kan bryta ditt program.
Exempel som kan påverka migreringssökvägen och -versionen:
5.6: TIMESTAMP-kolumn för korrekt lagring av millisekunder och fulltextsökning
5.7: Stöd för intern JSON-datatyp
8.0: Stöd för NoSQL-dokumentarkiv, atomiska och kraschsäkra DDL- och JSON-tabellfunktioner
Kommentar
MySQL 5.6 förlorar allmänt stöd i februari 2021. MySQL-arbetsbelastningar måste migreras till MySQL-version 5.7 eller senare.
Så här kontrollerar du MySQL-serverversionen:
SHOW VARIABLES LIKE "%version%";
Databaslagringsmotorer
Azure Database for MySQL stöder endast innoDB - och minnesdatabaslagringsmotorer . Andra lagringsmotorer, till exempel MyISAM, måste migreras till en lagringsmotor som stöds. Skillnaderna mellan MyISAM och InnoDB är driftfunktionerna och prestandautdata. Tabeller på högre nivå och schemastruktur ändras vanligtvis inte mellan motorerna, men index- och tabellkolumntyperna kan ändras av lagrings- och prestandaskäl. Även om InnoDB är känt för att ha stora datafilstorlekar hanteras lagringsinformationen av Azure Database for MySQL-tjänsten.
Migrera från MyISAM till InnoDB
MyISAM-databasen och tabellerna måste konverteras till InnoDB-tabeller. Efter konverteringen bör program testas för kompatibilitet och prestanda. I de flesta fall kräver testning att tabellen återskapas och mållagringsmotorn ändras via DDL-instruktioner. Det är osannolikt att den här ändringen behöver utföras under migreringen eftersom den inträffar när schemat skapas i Azure-målet. Mer information finns i dokumentationen om att konvertera tabeller som utvecklar på MySQL-webbplatsen.
Använd den här frågan för att hitta användbar tabellinformation:
SELECT
tab.table_schema,
tab.table_name,
tab.engine as engine_type,
tab.auto_increment,
tab.table_rows,
tab.create_time,
tab.update_time,
tco.constraint_type
FROM information_schema.tables tab
LEFT JOIN information_schema.table_constraints tco
ON (tab.table_schema = tco.table_schema
AND tab.table_name = tco.table_name
)
WHERE
tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
AND tab.table_type = 'BASE TABLE';
Kommentar
Att köra frågor mot INFORMATION_SCHEMA i flera databaser kan påverka prestandan. Kör under perioder med låg användning.
Om du vill konvertera en tabell från MyISAM till InnoDB kör du följande:
ALTER TABLE {table\_name} ENGINE=InnoDB;
Kommentar
Den här konverteringsmetoden gör att tabellen låses och alla program kan vänta tills åtgärden har slutförts. Tabelllåsningen gör att databasen visas offline under en kort period.
I stället kan tabellen skapas med samma struktur men med en annan lagringsmotor. När du har skapat dem kopierar du raderna till den nya tabellen:
INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}
Kommentar
För att den här metoden ska lyckas måste den ursprungliga tabellen tas bort och sedan byta namn på den nya tabellen. Den här aktiviteten orsakar en kort stilleståndstid.
Databasdata och -objekt
Data är en komponent i databasmigreringen. Databasens stödobjekt måste migreras och valideras för att säkerställa att programmen fortsätter att köras på ett tillförlitligt sätt.
Här är en lista över objekt som du bör inventera före och efter migreringen:
Tabeller (schema)
Primärnycklar, sekundärnycklar
Index
Funktioner
Förfaranden
Utlösare
Vyer
Användardefinierade funktioner
MySQL tillåter användning av funktioner som anropar extern kod. Dataarbetsbelastningar med användardefinierade funktioner (UDF:er) med extern kod kan tyvärr inte migreras till Azure Database for MySQL. Det beror på att den nödvändiga MySQL-funktionens säkerhetskopiering så eller dll-kod inte kan laddas upp till Azure-servern.
Kör följande fråga för att hitta alla UDF:er som kan vara installerade:
SELECT * FROM mysql.func;
Källsystem
Mängden förberedelse av migrering kan variera beroende på källsystemet och dess plats. Utöver databasobjekten bör du överväga hur du hämtar data från källsystemet till målsystemet. Det kan bli svårt att migrera data när brandväggar och andra nätverkskomponenter finns mellan källan och målet.
Dessutom kan det gå långsammare att flytta data via Internet än att använda dedikerade kretsar till Azure. När du flyttar många gigabyte, terabyte och petabyte med data bör du därför överväga att konfigurera en ExpressRoute-anslutning mellan källnätverket och Azure-nätverket.
Om ExpressRoute redan finns är det troligt att anslutningen används av andra program. Att utföra en migrering över en befintlig väg kan orsaka belastning på nätverkets dataflöde och potentiellt orsaka betydande prestanda för både migreringen och andra program som använder nätverket.
Slutligen måste diskutrymmet utvärderas. När du exporterar en stor databas bör du tänka på storleken på data. Se till att systemet där verktyget körs och att exportplatsen i slutändan har tillräckligt med diskutrymme för att utföra exportåtgärden.
Molnleverantörer
Migrering av databaser från molntjänstleverantörer som Amazon Web Services (AWS) kan kräva ett extra nätverkskonfigurationssteg för att få åtkomst till de molnbaserade MySQL-instanserna. Migreringsverktyg, till exempel Data Migration Services, kräver åtkomst utanför IP-intervall och kan annars blockeras.
Lokal
Precis som molnleverantörer måste en sökväg skapas mellan den lokala instansen och Azure Database for MySQL om MySQL-dataarbetsbelastningen ligger bakom brandväggar eller andra nätverkssäkerhetslager.
Verktyg
Många verktyg och metoder kan användas för att utvärdera MySQL-dataarbetsbelastningar och miljöer. Varje verktyg innehåller en annan uppsättning utvärderings- och migreringsfunktioner. Som en del av den här guiden granskar vi de vanligaste verktygen för att utvärdera MySQL-dataarbetsbelastningar.
Azure migrerar
Även om Azure Migrate inte stöder direkt migrering av MySQL-databasarbetsbelastningar kan det användas när administratörer är osäkra på vilka användare och program som använder data, oavsett om de finns på en virtuell eller maskinvarubaserad dator. Beroendeanalys kan utföras genom att installera och köra övervakningsagenten på den dator som är värd för MySQL-arbetsbelastningen. Agenten samlar in informationen under en viss period, till exempel en månad. Beroendedata kan analyseras för att hitta okända anslutningar som görs till databasen. Anslutningsdata kan hjälpa dig att identifiera programägare som behöver meddelas om den väntande migreringen.
Utöver beroendeanalysen av program och användaranslutningsdata kan Azure Migrate också användas för att analysera Hyper-V-, VMware- eller fysiska servrar för att tillhandahålla användningsmönster för databasarbetsbelastningarna för att föreslå rätt målmiljö.
Telgraf för Linux
Linux-arbetsbelastningar kan använda Microsoft Monitoring Agent (MMA) för att samla in data på dina virtuella och fysiska datorer. Överväg också att använda Telegraf-agenten och dess breda uppsättning plugin-program för att samla in dina prestandamått.
Tjänstnivåer
Utrustad med utvärderingsinformationen (CPU, minne, lagring osv.) är migreringsanvändarens nästa val att bestämma vilken Azure Database for MySQL-prisnivå som ska börja användas.
Det finns för närvarande tre nivåer:
Grundläggande: Arbetsbelastningar som kräver lätt beräkning och I/O-prestanda.
Generell användning: De flesta företagsarbetsbelastningar som kräver balanserad beräkning och minne med skalbart I/O-dataflöde.
Minnesoptimerad: Databasarbetsbelastningar med höga prestanda som kräver minnesintern prestanda för snabbare transaktionsbearbetning och högre samtidighet.
Nivåbeslutet kan påverkas av RTO- och RPO-kraven för dataarbetsbelastningen. När dataarbetsbelastningen kräver över 4 TB lagringsutrymme krävs ett extra steg. Granska och välj en region som har stöd för upp till 16 TB lagringsutrymme.
Normalt fokuserar beslutsfattandet på behovet av lagring och IOPS, eller indata-/utdataåtgärder per sekund. Målsystemet behöver därför alltid minst lika mycket lagringsutrymme som i källsystemet. Eftersom IOPS allokeras 3/GB är det dessutom viktigt att matcha IOP:ernas behov med den slutliga lagringsstorleken.
| Faktorer | Nivå |
|---|---|
| Grundläggande | Utvecklingsdator, inget behov av höga prestanda med mindre än 1 TB lagring. |
| Generell användning | Behov av IOPS mer än vad grundläggande nivå kan tillhandahålla, men för lagring som är mindre än 16 TB och mindre än 4 GB minne. |
| Minnesoptimerad | Dataarbetsbelastningar som använder hög minnesanvändning eller hög cachelagring och buffertrelaterad serverkonfiguration, till exempel hög samtidighet innodb_buffer_pool_instances, stora BLOB-storlekar, system med många replikeringskopior. |
Kostnader
Efter att ha utvärderat hela WWI MySQL-dataarbetsbelastningarna fastställde WWI att de skulle behöva minst 4 virtuella kärnor och 20 GB minne och minst 100 GB lagringsutrymme med en IOP-kapacitet på 450 IOPS. På grund av kravet på 450 IOPS måste de allokera minst 150 GB lagringsutrymme på grund av allokeringsmetoden Azure Database for MySQL IOPs. Dessutom kräver de minst upp till 100 % av din etablerade serverlagring som lagring av säkerhetskopior och en läsreplik. De förväntar sig inte en utgående utgående utgående trafik på mer än 5 GB.
Med priskalkylatorn för Azure Database for MySQL kunde WWI fastställa kostnaderna för Azure Database for MySQL-instansen. Från och med 9/2020 visas de totala ägandekostnaderna (TCO) i följande tabell för WWI-konferensdatabasen.
| Resurs | beskrivning | Antal | Kostnad |
|---|---|---|---|
| Beräkning (Generell användning) | 4 virtuella kärnor, 20 GB | 1 @ $0.351/hr | $3074.76 /år |
| Storage | 5 GB | 12 x 150 @ $0.115 | $207/år |
| Säkerhetskopiering | Upp till 100 % av den etablerade lagringen | Ingen extra kostnad på upp till 100 % av den etablerade serverlagringen | $0.00/år |
| Läs replik | Replik i 1 sekund | compute + storage | $3281.76 /år |
| Nätverk | < Utgående 5 GB/månad | Kostnadsfri | |
| Totalt | $6563.52 /år |
Efter att ha granskat de initiala kostnaderna bekräftade WWI:s CIO att de finns i Azure under en period som är mycket längre än tre år. De bestämde sig för att använda 3-åriga reservinstanser för att spara ytterligare ~$4K/år.
| Resurs | beskrivning | Antal | Kostnad |
|---|---|---|---|
| Beräkning (Generell användning) | 4 virtuella kärnor | 1 @ $0.1375/hr | $1204.5 /år |
| Storage | 5 GB | 12 x 150 @ $0.115 | $207/år |
| Säkerhetskopiering | Upp till 100 % av den etablerade lagringen | Ingen extra kostnad på upp till 100 % av den etablerade serverlagringen | $0.00/år |
| Nätverk | < Utgående 5 GB/månad | Kostnadsfri | |
| Läs replik | Replik i 1 sekund | compute + storage | $1411.5 /år |
| Totalt | $2,823 /år |
Som tabellen ovan visar måste säkerhetskopior, utgående nätverk och alla läsrepliker beaktas i den totala ägandekostnaden (TCO). När fler databaser läggs till är lagrings- och nätverkstrafiken som genereras den enda extra kostnadsbaserade faktorn att tänka på.
Kommentar
Uppskattningarna ovan omfattar inte några ExpressRoute-, Azure App Gateway-, Azure Load Balancer- eller App Service-kostnader för programskikten.
Ovanstående priser kan ändras när som helst och varierar beroende på region.
Programkonsekvenser
När du flyttar till Azure Database for MySQL är konverteringen till SSL-baserad kommunikation (Secure Sockets Layer) sannolikt en av de viktigaste ändringarna för dina program. SSL är aktiverat som standard i Azure Database for MySQL, och det är troligt att det lokala programmet och dataarbetsbelastningen inte har konfigurerats för att ansluta till MySQL med SSL. När det är aktiverat lägger SSL-användningen till extra bearbetningskostnader och bör övervakas.
Kommentar
Även om SSL är aktiverat som standard har du möjlighet att inaktivera det.
Följ aktiviteterna i Konfigurera SSL-anslutning i ditt program för att på ett säkert sätt ansluta till Azure Database for MySQL för att konfigurera om programmet för att stödja den här starka autentiseringssökvägen.
Slutligen ändrar du servernamnet i programmet anslutningssträng eller växlar DNS till den nya Azure Database for MySQL-servern.
WWI-scenario
WWI startade utvärderingen genom att samla in information om deras MySQL-dataegendom, enligt följande tabell.
| Name | Source | Db-motor | Storlek | IOPS | Version | Ägare | Driftstopp |
|---|---|---|---|---|---|---|---|
| WwwDB | AWS (PaaS) | InnoDB | 1 GB | 150 | 5.7 | Marknadsföringsdept | 1 tim |
| BlogDB | AWS (PaaS) | InnoDB | 1 GB | 100 | 5.7 | Marknadsföringsdept | 4 timmar |
| ConferenceDB | Lokal | InnoDB | 5 GB | 50 | 5,5 | Försäljningsdept | 4 timmar |
| CustomerDB | Lokal | InnoDB | 10 GB | 75 | 5,5 | Försäljningsdept | 2 timmar |
| SalesDB | Lokal | InnoDB | 20 GB | 75 | 5,5 | Försäljningsdept | 1 tim |
Varje databasägare kontaktades för att fastställa den godkända stilleståndstiden. Den valda planerings- och migreringsmetoden baserades på den godkända databasavbrottstiden.
För den första fasen fokuserade WWI enbart på ConferenceDB-databasen. Teamet behövde migreringsupplevelsen för att hjälpa till med migrering av dataarbetsbelastningar. ConferenceDB-databasen valdes på grund av den enkla databasstrukturen och den stora godtagbara stilleståndstiden. När databasen har migrerats fokuserade teamet på att migrera programmet till den säkra Azure-landningszonen.
Checklista för utvärdering
Testa att arbetsbelastningen körs på målsystemet.
Se till att rätt nätverkskomponenter finns på plats för migreringen.
Förstå resurskraven för dataarbetsbelastning.
Beräkna de totala kostnaderna.
Förstå kraven på stilleståndstid.
Var beredd på att göra programändringar.