Migratiefasen en overwegingen

Voltooid

Bij een geslaagde migratie worden overwegingen in verschillende fasen verdeeld.

Migratiefasen

Migraties worden in verschillende fasen uitgevoerd. Plan eerst het migratiebereik: detectie en evaluatie van databasebronnen, bedrijfsvereisten zoals downtime en een terugvalplan als de migratie mislukt. Bereid vervolgens de migratie voor door de juiste resources in te richten en connectiviteit tussen bron- en doelomgevingen in te stellen. Nadat de migratiebenadering is ingesteld en resources gereed zijn, wilt u over het algemeen een drooguitvoering uitvoeren in een faseringsomgeving om problemen te identificeren vóór de productiemigratie. Ten slotte voert u de laatste migratie uit en valideert u de lopende voortgang en geslaagde voltooiing.

Deze module is gericht op de voorbereidingsfase (2) en de laatste migratiefase (4, 5).

Overwegingen bij migratie

U moet vereisten evalueren voor downtime van toepassingen, versiecompatibiliteit, netwerken en beveiliging, prestaties, kosten en bedrijfscontinuïteit.

Uitvaltijd van toepassingen

Een van de eerste dingen die u moet overwegen, is hoeveel downtime uw bedrijfsscenario kan opvangen. Het antwoord beperkt uw beschikbare migratieopties sterk.

De beste downtime is een downtime die gebruikers niet merken. In de praktijk zijn migraties complexe procedures en beslissingen met betrekking tot de overwegingen in deze module bepalen de vereiste downtime. De afwegingen omvatten beschikbaarheid versus de kosten en het risico van de migratie. Vanwege de complexiteit die gepaard gaat met het verminderen van downtime tot minuten of zelfs seconden, is het belangrijk om veronderstellingen te testen en te bepalen hoeveel downtime van de migratie acceptabel is.

Offlinemigraties

Met een offlinemigratie moet u de toepassing afsluiten om de database te verplaatsen. Dit garandeert dat er tijdens de migratie geen wijzigingen in de gegevens zijn. Deze aanpak vereist echter dat de database wordt uitgeschakeld om de gegevensexport te voltooien. De downtime duurt minimaal zolang het duurt om de gegevens over te dragen. Een offlinemigratie omvat:

1. Alle apps loskoppelen van de brondatabase.
2. De inhoud van de brondatabase exporteren.
3. De brongegevens importeren in de doeldatabase.
4. Toepassingen opnieuw verbinden met de doeldatabase nadat het importeren is voltooid.

Sommige toepassingen hebben geplande onderhoudsvensters tijdens perioden met weinig verkeer. Dit zijn geweldige momenten om offlinemigraties uit te voeren.

Een incrementele offlinemigratie vermindert downtime door het grootste deel van de gegevens te verplaatsen voordat u de toepassing offline haalt. Migreer eerst een volledige databaseback-up. Migreer vervolgens de wijzigingen in de database die is toegevoegd sinds de vorige migratie. Wanneer de benodigde tijd voor het migreren van deze nieuwe wijzigingen binnen uw acceptabele downtime past, zet u de toepassing offline om de gegevens te blokkeren en de migratie te voltooien. Het kan zijn dat één migratieverhoging voldoende is om downtime te verminderen op volgorde van grootte of meer, met name voor databases met jaren van geschiedenis. Voor grote en drukke databases moet u mogelijk verschillende stappen migreren om acceptabele downtime te bereiken.

Onlinemigraties

Met een onlinemigratie kunt u de noodzaak van downtime aanzienlijk verminderen of zelfs elimineren door tijdens de migratie wijzigingen van de bronserver naar de doelserver te repliceren en vervolgens over te schakelen naar de doelserver wanneer de replicatie volledig wordt gesynchroniseerd.

Soms is downtime ongewenst of zelfs onaanvaardbaar. In dit geval is het onmogelijk om de databasestatus te 'blokkeren' door de toepassing uit te schakelen. In plaats daarvan wordt de brondatabase tijdens normale bewerkingen gerepliceerd naar de doeldatabase. Wanneer het doel volledig wordt onderschept met de bron, knipt de toepassing over naar de doeldatabase.

Voor een onlinemigratie moet u het volgende doen:

1. Begin met het repliceren van de brondatabase naar de doeldatabase.
2. Wanneer de doeldatabase wordt onderschept, blokkeert u de brondatabase door de toepassing te onderbreken of door af te dwingen dat schrijfbewerkingen mislukken door de modus Alleen-lezen in te schakelen.
3. Wanneer de doeldatabase 100% is onder de wijzigingen, schakelt u de replicatie in het doel uit.
4. Alle clients omleiden naar de doeldatabase en hervattingsbewerkingen.
5. Sluit de verouderde brondatabase af.

Online- en offlinemigraties vergelijken

Hoewel offlinemigraties downtime vereisen, vermindert de incrementele migratietechniek die eerder is besproken, de downtime aanzienlijk. Met meerdere stappen kan de uiteindelijke migratie naar de gegevenswaarde van een dag of minder worden verkleind. Geautomatiseerde services zoals Azure DMS minimaliseren downtime door een reeks steeds kleinere migraties uit te voeren. Incrementele offlinemigraties kunnen ook handmatig worden uitgevoerd als netwerkinstellingen automatisering voorkomen.

Onlinemigraties coördineren een delicate bewerking tussen database- en toepassingsteams. Clienttoepassingen moeten worden gebruikt om probleemloos te reageren op schrijffouten om gegevensverlies tijdens de migratie te voorkomen. Clients moeten ook ondersteuning bieden voor het maken van verbinding met een nieuwe databaseserver zonder de gebruikerservaring te onderbreken. Als deze toepassingshulpprogramma's nog niet bestaan, kan het behoorlijk duur zijn om te bouwen.

Versiecompatibiliteit

De meeste toepassingsbewerkingen zijn compatibel met MySQL-upgrades. In sommige gevallen werken toepassingsonderdelen of databasegebruik echter alleen met bepaalde MySQL-versies.

Controleer of alle toepassingsonderdelen compatibel zijn met de doeldatabaseversie. Overweeg om versie-upgrades te scheiden van migraties die een database verplaatsen of opnieuw configureren. Als u bijvoorbeeld migreert van on-premises MySQL 5.7 naar een flexibele Azure Database for MySQL-server met MySQL 8.0, kunt u overwegen om van on-premises naar een flexibele Azure Database for MySQL-server met MySQL 5.7 te migreren en vervolgens van 5.7 naar 8.0 in-place te migreren.

Netwerken en beveiliging

Voor databasemigraties moeten gegevens van de brondatabase worden overgebracht naar het doel. Hoe dit gebeurt en hoe snel, is grotendeels afhankelijk van de verbinding tussen de twee netwerken. Als u geen liveverbinding tot stand kunt brengen van de bron naar het doel, moet u fysieke gegevensbestanden op een andere manier overdragen, bijvoorbeeld via een tussenstation of server. Zorg er in dat geval voor dat u voldoende schijfruimte hebt om de momentopnamen op elk systeem op te slaan.

Het is ook essentieel om tijdens de migratie rekening te houden met beveiligingsvereisten. U hebt de juiste verificatie en machtigingen nodig voor bron- en doeldatabases. U kunt ook serviceaccounts maken om enkele of alle migratiestappen uit te voeren. Vervolgens kunt u de toegang verwijderen nadat deze zijn voltooid.

Of de brondatabase zich nu on-premises bevindt of zich in een andere cloudprovider bevindt, netwerkinstellingen staan doorgaans geen externe verbindingen toe. U moet het netwerk configureren om verbindingen met Azure toe te staan.

Als de brondatabase on-premises is en het gegevensvolume groot is, kan het verplaatsen van terabytes aan gegevens via een normale internetverbinding onpraktisch traag zijn. In dit scenario kunt u overwegen om een Azure ExpressRoute-verbinding tussen uw netwerk en Azure in te stellen.

Zelfs als u een ExpressRoute gebruikt, levert de verbinding die deze heeft waarschijnlijk ook ander verkeer en kunnen de twee elkaar verstoren. Afhankelijk van conflicten kan de prestatietreffer voor bestaande toepassingen en het migratieproces aanzienlijk zijn.

Prestaties

Databasemigraties zijn een uitstekende mogelijkheid om de capaciteit te vergroten door de grootte van de infrastructuur te wijzigen. Uw databasegebruik kan profiteren van verhoogde CPU-, RAM- of I/O-resources.

Voordat u de doelserver inricht, moet u rekening houden met het huidige databasegebruik. Bewaak prestatiegegevens, zoals CPU-gebruik, samen met groeiprognoses en SLA's om te bepalen of u een grotere rekenkracht moet toewijzen. U kunt daarentegen merken dat uw capaciteit overbezet is en dat de kosten omlaag worden gebracht.

Kosten

Wanneer u migreert naar Azure, kunt u profiteren van transparante prijzen. Met behulp van uw geselecteerde SKU en andere parameters, zoals redundantie en hoge beschikbaarheid, kunt u met de Azure-prijscalculator uw kosten na de migratie schatten tijdens de planning. U kunt de calculator ook gebruiken om afwegingen te maken, zoals beschikbaarheid versus kosten.

Bedrijfscontinuïteit

Databasemigraties zijn een goed moment om metrische gegevens en doelstellingen voor bedrijfscontinuïteit te bekijken. Het kan handig zijn om bewaarbeleid voor back-ups te wijzigen of over te schakelen naar geografisch redundante back-ups of hoge beschikbaarheid. Houd rekening met uw historische uptime versus SLA en hersteltijd van storingen. Migraties bieden ook praktijkvoorbeelden van het opzetten van een nieuwe database vanuit fysieke gegevensbestanden, die noodherstelplannen kunnen informeren.