Delen via

MySQL on-premises migreren naar Azure Database for MySQL: Evaluatie

  • Artikel

Het beoordelen van de migratie van MySQL-databases van on-premises omgevingen naar Azure Database for MySQL is een kritieke eerste stap om een soepele en succesvolle overgang te garanderen. In dit artikel worden de belangrijkste factoren en overwegingen in de evaluatiefase grondig onderzocht. U kunt weloverwogen beslissingen nemen die overeenkomen met de doelstellingen van uw organisatie door uw huidige infrastructuur te evalueren, potentiële uitdagingen te identificeren en inzicht te krijgen in de voordelen van de beheerde databaseservices van Azure. Of u nu de prestaties wilt verbeteren, de schaalbaarheid wilt verbeteren of operationele kosten wilt verlagen, deze handleiding biedt u de inzichten die nodig zijn om uw migratiestrategie effectief te plannen en uit te voeren.

Vereisten

MySQL on-premises migreren naar Azure Database for MySQL: representatieve use case

Overzicht

Voordat u meteen aan de slag gaat met het migreren van een MySQL-workload, is er een behoorlijke hoeveelheid due diligence die moet worden uitgevoerd. Dit omvat het analyseren van de gegevens, het hosten van omgevingen en toepassingsworkloads om te controleren of de Azure-landingszone correct is geconfigureerd en voorbereid om de binnenkort te migreren workloads te hosten.

Beperkingen

Azure Database for MySQL is een volledig ondersteunde versie van de MySQL-community-editie die als platform als een service wordt uitgevoerd. Er zijn echter enkele beperkingen waarmee u vertrouwd kunt raken bij het uitvoeren van een eerste evaluatie.

De belangrijkste hiervan zijn:

  • Ondersteuning voor opslagengines voor InnoDB en Memory alleen

  • Beperkte Privilege ondersteuning (DBA, SUPER, DEFINER)

  • Uitgeschakelde instructies voor gegevensmanipulatie (SELECT ... INTO OUTFILE, LOAD DATA INFILE)

  • Automatische significante databasemigratie (5.6 tot 5.7, 5.7 tot 8.0)

  • Wanneer u Door de gebruiker gedefinieerde functies (UDF's) van MySQL Server gebruikt, is de enige optie voor het hosten van door Azure gehoste VM's, omdat er geen mogelijkheid is om het so of dll onderdeel te uploaden naar Azure Database for MySQL.

Veel van de andere items zijn operationele aspecten waarmee beheerders vertrouwd moeten raken als onderdeel van het levenscyclusbeheer van operationele gegevensworkloads. In deze handleiding worden veel van deze operationele aspecten besproken in de sectie Post Migration Management.

MySQL-versies

MySQL heeft een rijke geschiedenis vanaf 1995. Sindsdien is het uitgegroeid tot een veelgebruikt databasebeheersysteem. Azure Database for MySQL is gestart met de ondersteuning van MySQL versie 5.6 en is nog steeds 5.7 en onlangs 8.0. Raadpleeg ondersteunde versies van Azure Database for MySQL voor de nieuwste versie van Azure Database for MySQL. In de sectie Post Migration Management bekijken we hoe upgrades (zoals 5.7.20 tot 5.7.21) worden toegepast op de MySQL-exemplaren in Azure.

Notitie

De sprong van 5.x naar 8.0 was grotendeels te wijten aan de Oracle-overname van MySQL. Als u meer wilt lezen over mySQL-geschiedenis, gaat u naar de MySQL-wikipagina.

Het is essentieel om de MySQL-bronversie te kennen. De toepassingen die het systeem gebruiken, gebruiken mogelijk databaseobjecten en -functies die specifiek zijn voor die versie. Het migreren van een database naar een lagere versie kan compatibiliteitsproblemen en verlies van functionaliteit veroorzaken. Het wordt ook aanbevolen om de gegevens en het toepassingsexemplaren grondig te testen voordat u naar een nieuwere versie migreert, omdat de geïntroduceerde functies uw toepassing kunnen breken.

Voorbeelden die van invloed kunnen zijn op het migratiepad en de versie:

  • 5.6: TIMESTAMP-kolom voor de juiste opslag van milliseconden en zoeken in volledige tekst

  • 5.7: Ondersteuning voor systeemeigen JSON-gegevenstype

  • 8.0: Ondersteuning voor NoSQL-documentopslag, atomische en crashveilige DDL- en JSON-tabelfuncties

    Notitie

    MySQL 5.6 verliest algemene ondersteuning in februari 2021. MySQL-workloads moeten worden gemigreerd naar MySQL-versie 5.7 of hoger.

Ga als volgende te werk om de MySQL-serverversie te controleren:

SHOW VARIABLES LIKE "%version%";

Databaseopslagengines

Azure Database for MySQL biedt alleen ondersteuning voor innoDB - en geheugendatabaseopslagengines . Andere opslagengines, zoals MyISAM, moeten worden gemigreerd naar een ondersteunde opslagengine. De verschillen tussen MyISAM en InnoDB zijn de operationele functies en prestatie-uitvoer. De tabellen en schemastructuur op een hoger niveau veranderen doorgaans niet tussen de engines, maar de index- en tabelkolomtypen kunnen om opslag- en prestatieredenen veranderen. Hoewel InnoDB bekend is dat ze grote bestandsgrootten hebben, worden deze opslaggegevens beheerd door de Azure Database for MySQL-service.

Migreren van MyISAM naar InnoDB

De MyISAM-database en -tabellen moeten worden geconverteerd naar InnoDB-tabellen. Na de conversie moeten toepassingen worden getest op compatibiliteit en prestaties. In de meeste gevallen moet u de tabel opnieuw maken en de doelopslagengine wijzigen via DDL-instructies. Het is onwaarschijnlijk dat deze wijziging moet worden uitgevoerd tijdens de migratie, omdat deze zich voordoet tijdens het maken van het schema in het Azure-doel. Raadpleeg de documentatie voor ontwikkelaars van converterende tabellen op de MySQL-website voor meer informatie.

Gebruik deze query om nuttige tabelgegevens te vinden:

    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';

Notitie

Het uitvoeren van query's op INFORMATION_SCHEMA in meerdere databases kan van invloed zijn op de prestaties. Wordt uitgevoerd tijdens perioden met weinig gebruik.

Als u een tabel wilt converteren van MyISAM naar InnoDB, voert u het volgende uit:

ALTER TABLE {table\_name} ENGINE=InnoDB;

Notitie

Deze conversiebenadering zorgt ervoor dat de tabel wordt vergrendeld en alle toepassingen kunnen wachten totdat de bewerking is voltooid. De tabelvergrendeling zorgt ervoor dat de database gedurende een korte periode offline wordt weergegeven.

In plaats daarvan kan de tabel worden gemaakt met dezelfde structuur, maar met een andere opslagengine. Nadat u de rijen hebt gemaakt, kopieert u de rijen naar de nieuwe tabel:

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Notitie

Als u deze aanpak wilt lukken, moet de oorspronkelijke tabel worden verwijderd en vervolgens de nieuwe tabel hernoemd. Deze taak veroorzaakt een korte downtimeperiode.

Databasegegevens en -objecten

Gegevens zijn één onderdeel van databasemigratie. De database ondersteunende objecten moeten worden gemigreerd en gevalideerd om ervoor te zorgen dat de toepassingen betrouwbaar blijven werken.

Hier volgt een lijst met items die u vóór en na de migratie moet inventariseren:

  • Tabellen (schema)

  • Primaire sleutels, refererende sleutels

  • Indexen

  • Functies

  • Procedures

  • Triggers

  • Weergaven

Door de gebruiker gedefinieerde functies

MySQL maakt het gebruik mogelijk van functies die externe code aanroepen. Gegevensworkloads met door de gebruiker gedefinieerde functies (UDF's) met externe code kunnen helaas niet worden gemigreerd naar Azure Database for MySQL. Dit komt doordat de back-up van de vereiste MySQL-functie zodat of dll-code niet kan worden geüpload naar de Azure-server.

Voer de volgende query uit om te zoeken naar UDF's die mogelijk zijn geïnstalleerd:

SELECT * FROM mysql.func;

Bronsystemen

De hoeveelheid migratievoorbereiding kan variëren, afhankelijk van het bronsysteem en de locatie ervan. Naast de databaseobjecten kunt u overwegen hoe u de gegevens van het bronsysteem naar het doelsysteem kunt ophalen. Het migreren van gegevens kan lastig worden wanneer firewalls en andere netwerkonderdelen zich tussen de bron en het doel bevinden.

Bovendien kan het verplaatsen van gegevens via internet langzamer zijn dan het gebruik van toegewezen circuits naar Azure. Overweeg daarom bij het verplaatsen van veel gigabytes, terabytes en petabytes aan gegevens een ExpressRoute-verbinding tussen het bronnetwerk en het Azure-netwerk in te stellen.

Als ExpressRoute al aanwezig is, wordt de verbinding waarschijnlijk gebruikt door andere toepassingen. Het uitvoeren van een migratie via een bestaande route kan leiden tot belasting van de netwerkdoorvoer en kan een aanzienlijke prestatietreffer veroorzaken voor zowel de migratie als andere toepassingen die het netwerk gebruiken.

Ten slotte moet schijfruimte worden geëvalueerd. Houd bij het exporteren van een grote database rekening met de grootte van de gegevens. Zorg ervoor dat het systeem waarop het hulpprogramma wordt uitgevoerd, en uiteindelijk beschikt de exportlocatie over voldoende schijfruimte om de exportbewerking uit te voeren.

Cloudproviders

Het migreren van databases van cloudservicesproviders zoals Amazon Web Services (AWS) vereist mogelijk een extra netwerkconfiguratiestap om toegang te krijgen tot de mySQL-exemplaren in de cloud. Migratiehulpprogramma's, zoals Data Migration Services, vereisen toegang van buiten IP-bereiken en kunnen anders worden geblokkeerd.

On-premises

Net als bij cloudproviders, moet er een pad worden gemaakt tussen het on-premises exemplaar en Azure Database for MySQL als de werkbelasting van MySQL zich achter firewalls of andere netwerkbeveiligingslagen bevindt.

Hulpprogramma's

Veel hulpprogramma's en methoden kunnen worden gebruikt om de MySQL-gegevensworkloads en -omgevingen te evalueren. Elk hulpprogramma biedt een andere set evaluatie- en migratiefuncties en -functionaliteit. Als onderdeel van deze handleiding bekijken we de meest gebruikte hulpprogramma's voor het beoordelen van MySQL-gegevensworkloads.

Azure migreert

Hoewel Azure Migrate niet rechtstreeks ondersteuning biedt voor het migreren van MySQL-databaseworkloads, kan deze worden gebruikt wanneer beheerders niet zeker weten welke gebruikers en toepassingen de gegevens gebruiken, ongeacht of ze worden gehost op een virtuele machine of op basis van hardware. Afhankelijkheidsanalyse kan worden uitgevoerd door de bewakingsagent te installeren en uit te voeren op de computer waarop de MySQL-workload wordt gehost. De agent verzamelt de informatie gedurende een ingestelde periode, zoals een maand. De afhankelijkheidsgegevens kunnen worden geanalyseerd om onbekende verbindingen met de database te vinden. De verbindingsgegevens kunnen helpen bij het identificeren van toepassingseigenaren die op de hoogte moeten worden gesteld van de migratie die in behandeling is.

Naast de afhankelijkheidsanalyse van toepassingen en gebruikersconnectiviteitsgegevens kan Azure Migrate ook worden gebruikt om de Hyper-V-, VMware- of fysieke servers te analyseren om gebruikspatronen van de databaseworkloads te bieden om de juiste doelomgeving voor te stellen.

Telgraf voor Linux

Linux-workloads kunnen gebruikmaken van de Microsoft Monitoring Agent (MMA) om gegevens op uw virtuele en fysieke machines te verzamelen. U kunt ook de Telegraf-agent en de breed scala aan invoegtoepassingen gebruiken om uw prestatiegegevens te verzamelen.

Servicelagen

Uitgerust met de evaluatie-informatie (CPU, geheugen, opslag, enzovoort), is de volgende keuze van de migratiegebruiker om te bepalen welke prijscategorie Azure Database for MySQL moet worden gebruikt.

Er zijn momenteel drie lagen:

  • Basis: Workloads die lichte reken- en I/O-prestaties vereisen.

  • Algemeen gebruik: de meeste zakelijke workloads die een evenwichtige rekenkracht en geheugen vereisen met schaalbare I/O-doorvoer.

  • Geoptimaliseerd voor geheugen: databaseworkloads met hoge prestaties die prestaties in het geheugen vereisen voor snellere transactieverwerking en hogere gelijktijdigheid.

De laagbeslissing kan worden beïnvloed door de RTO- en RPO-vereisten van de gegevensworkload. Wanneer voor de gegevensworkload meer dan 4 TB opslagruimte is vereist, is een extra stap vereist. Controleer en selecteer een regio die ondersteuning biedt voor maximaal 16 TB aan opslagruimte.

Normaal gesproken richt de besluitvorming zich op de opslag- en IOPS- of invoer-/uitvoerbewerkingen per seconde. Daarom heeft het doelsysteem altijd minstens zoveel opslagruimte nodig als in het bronsysteem. Omdat IOPS 3/GB wordt toegewezen, is het bovendien belangrijk dat de IOPS overeenkomen met de uiteindelijke opslaggrootte.

Factoren Laag
Basic Ontwikkelcomputer, geen behoefte aan hoge prestaties met minder dan 1 TB opslag.
Algemeen doel Er is meer behoefte aan IOPS dan wat de basic-laag kan bieden, maar voor opslag minder dan 16 TB en minder dan 4 GB geheugen.
Geoptimaliseerd voor geheugen Gegevensworkloads die gebruikmaken van een hoog geheugen of een hoge cache en buffergerelateerde serverconfiguratie, zoals hoge gelijktijdigheid innodb_buffer_pool_instances, grote BLOB-grootten, systemen met veel replicatiekopieën.

Kosten

Na de evaluatie van de volledige WWI MySQL-gegevensworkloads heeft WWI vastgesteld dat ze ten minste 4 vCores en 20 GB geheugen en ten minste 100 GB opslagruimte nodig hebben met een IOP-capaciteit van 450 IOPS. Vanwege de 450 IOPS-vereiste moeten ze ten minste 150 GB opslagruimte toewijzen vanwege de toewijzingsmethode van Azure Database for MySQL IOPS. Daarnaast vereisen ze ten minste 100% van uw ingerichte serveropslag als back-upopslag en één leesreplica. Ze verwachten geen uitgaande uitgaand verkeer van meer dan 5 GB.

Met behulp van de prijscalculator van Azure Database for MySQL kon WWI de kosten voor het Azure Database for MySQL-exemplaar bepalen. Vanaf 9/2020 worden de totale eigendomskosten (TCO) weergegeven in de volgende tabel voor de WWI Conference Database.

Bron Beschrijving Hoeveelheid Kosten
Compute (algemeen gebruik) 4 vCores, 20 GB 1 @ $0,351/uur $ 3074,76 / yr
Storage 5 GB 12 x 150 @ $ 0,115 $ 207 / yr
Een back-up maken Maximaal 100% van de ingerichte opslag Geen extra kosten tot 100% van de ingerichte serveropslag $ 0,00 / yr
Leesreplica 1 seconde regioreplica compute + opslag $ 3281,76 / yr
Netwerk < Uitgaand verkeer van 5 GB per maand Gratis
Totaal $ 6563,52 / jaar

Na beoordeling van de initiële kosten heeft de CIO van WWI bevestigd dat ze zich gedurende een periode van veel langer dan drie jaar in Azure bevinden. Ze besloten om 3 jaar reserve instanties te gebruiken om een extra ~$4K/yr te besparen.

Bron Beschrijving Hoeveelheid Kosten
Compute (algemeen gebruik) 4 vCores 1 @ $0,1375/uur $ 1204,5 / yr
Storage 5 GB 12 x 150 @ $ 0,115 $ 207 / yr
Een back-up maken Maximaal 100% van de ingerichte opslag Geen extra kosten tot 100% van de ingerichte serveropslag $ 0,00 / yr
Netwerk < Uitgaand verkeer van 5 GB per maand Gratis
Leesreplica 1 seconde regioreplica compute + opslag $ 1411,5 / yr
Totaal $ 2.823 / yr

Zoals in de bovenstaande tabel wordt weergegeven, moeten back-ups, netwerkuitgangen en leesreplica's worden overwogen in de totale eigendomskosten (TCO). Naarmate er meer databases worden toegevoegd, zou het gegenereerde opslag- en netwerkverkeer de enige extra kostenfactor zijn om rekening mee te houden.

Notitie

De bovenstaande schattingen omvatten geen ExpressRoute-, Azure-app Gateway-, Azure Load Balancer- of App Service-kosten voor de toepassingslagen.

De bovenstaande prijzen kunnen op elk gewenst moment worden gewijzigd en variëren afhankelijk van de regio.

Gevolgen voor toepassingen

Wanneer u overstapt naar Azure Database for MySQL, is de conversie naar ssl-gebaseerde communicatie (Secure Sockets Layer) waarschijnlijk een van de belangrijkste wijzigingen voor uw toepassingen. SSL is standaard ingeschakeld in Azure Database for MySQL en waarschijnlijk is de on-premises toepassing en de gegevensworkload niet ingesteld om verbinding te maken met MySQL via SSL. Indien ingeschakeld, voegt SSL-gebruik extra verwerkingsoverhead toe en moet worden bewaakt.

Notitie

Hoewel SSL standaard is ingeschakeld, hebt u de mogelijkheid om deze uit te schakelen.

Volg de activiteiten in SSL-connectiviteit configureren in uw toepassing om veilig verbinding te maken met Azure Database for MySQL om de toepassing opnieuw te configureren om dit sterke verificatiepad te ondersteunen.

Wijzig ten slotte de servernaam in de toepassing verbindingsreeks s of wijzig de DNS zodat deze verwijst naar de nieuwe Azure Database for MySQL-server.

WWI-scenario

WWI heeft de evaluatie gestart door informatie over hun MySQL-gegevensdomein te verzamelen, zoals wordt weergegeven in de volgende tabel.

Naam Source Db Engine Tekengrootte IOPS Versie Eigenaar Uitvaltijd
WwwDB AWS (PaaS) InnoDB 1 GB 150 5.7 Marketingafdeling 1 uur
BlogDB AWS (PaaS) InnoDB 1 GB 100 5.7 Marketingafdeling 4 uur
ConferenceDB On-premises InnoDB 5 GB 50 5.5 Verkoopafdeling 4 uur
CustomerDB On-premises InnoDB 10 GB 75 5.5 Verkoopafdeling 2 uur
SalesDB On-premises InnoDB 20 GB 75 5.5 Verkoopafdeling 1 uur

Elke database-eigenaar is gecontacteerd om de acceptabele downtimeperiode te bepalen. De geselecteerde plannings- en migratiemethode zijn gebaseerd op de acceptabele downtime van de database.

Voor de eerste fase richt WWI zich uitsluitend op de ConferenceDB-database. Het team heeft de migratie-ervaring nodig om de migratie van gegevensworkloads te helpen. De ConferenceDB-database is geselecteerd vanwege de eenvoudige databasestructuur en de grote acceptabele downtime. Zodra de database is gemigreerd, heeft het team zich gericht op het migreren van de toepassing naar de beveiligde Azure-landingszone.

Controlelijst voor evaluatie

  • Test de werkbelasting wordt uitgevoerd op het doelsysteem.

  • Zorg ervoor dat de juiste netwerkonderdelen aanwezig zijn voor de migratie.

  • Inzicht in de resourcevereisten voor gegevensworkloads.

  • Maak een schatting van de totale kosten.

  • Inzicht in de downtimevereisten.

  • Wees voorbereid om toepassingswijzigingen aan te brengen.

Volgende stap

MySQL on-premises migreren naar Azure Database for MySQL: Planning