Metodtips för databas­migrering

Att migrera en databas är mer komplext än att flytta en VM, eftersom databaser är tillståndsbevarande och ofta har aktiva anslutningar dygnet runt. En naiv kopierings- och återställningsmetod kräver flera timmars driftstopp, vilket inte är acceptabelt för produktionssystem. Bästa praxis för databas­migrering använder kontinuerlig datareplikering för att hålla källan och målet synkroniserade medan målet valideras. Därefter genomförs en kort, planerad övergång när trafiken dirigeras om till den nya Azure-databasen.

Azure Database Migration Service (DMS) är en fullständigt hanterad tjänst som samordnar online-migreringar (nästan utan driftstopp) och offline-migreringar (baserade på driftstopp) från populära lokala databasmotorer till Azure-hanterade databastjänster. DMS stöder källor som SQL Server, MySQL, PostgreSQL, MongoDB, Oracle och mål som Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL och Azure Cosmos DB. Tjänsten integreras med Data Migration Assistant (DMA) för kompatibilitetskontroller före migreringen.

Innan du migrerar SQL Server ska du köra Data Migration Assistant (DMA) mot källdatabasen. DMA identifierar: kompatibilitetsproblem (funktioner som används i databasen men som inte stöds av Azure SQL-målet), bakåtinkompatibla ändringar, utfasade funktioner och prestandarekommendationer. Verktyget genererar en detaljerad HTML-rapport som prioriterar problemen efter allvarlighetsgrad, så att teamet kan åtgärda dem innan migreringsfönstret börjar.

En offline-migrering tar källdatabasen offline under hela migreringen. Det är acceptabelt för små databaser eller icke-kritiska system där ett underhållsfönster är möjligt. En online-migrering använder change data capture (CDC) eller transaktionsloggsändning för att kontinuerligt replikera ändringar medan den nya databasen läses in, vilket begränsar driftstoppet till det avslutande övergångssteget. Online-migrering rekommenderas för databaser som är större än 1 GB eller har SLA:er som kräver mindre än 1 timmes driftstopp.

Ett DMS-migreringsprojekt anger källanslutningen (servernamn, autentisering och databasnamn), målanslutningen (Azure SQL-anslutningssträng) och migreringsläget (online eller offline). Du väljer även vilka databaser och tabeller som ska migreras. DMS validerar anslutningen innan starten. Migreringsprojektet sparas i Azure-portalen, så att du kan övervaka förloppet, försöka migrera misslyckade tabeller igen och visa detaljerade aktivitetsloggar.

Migrera alltid schemat före data. Använd DMA eller SQL Server Management Studio (SSMS) för att skapa skript för och distribuera tabeller, vyer, lagrade procedurer, funktioner och index till Azure SQL Database-målet. Kontrollera att alla schemaobjekt finns och kompileras utan fel innan du låter DMS börja överföra data. Schemafel som upptäcks under migreringen kan förstöra migreringskörningen och tvinga dig att börja om från början.

DMS genomför en fullständig datainläsning genom att läsa källdatabasen tabell för tabell och skriva rader till Azure SQL-målet med hjälp av bulk insert. Under den fullständiga inläsningen hanterar tjänsten stora tabeller genom att dela upp dem i batchar. Index på målet inaktiveras under inläsningen för att maximera genomströmningen och återskapas sedan. För mycket stora databaser (i terabyteklass) bör Ni överväga att använda Azure Data Factory eller bacpac-exporter för att läsa in data i förväg och minska DMS-körtiden.

Vid onlinemigreringar aktiverar DMS SQL Server Change Data Capture (CDC) på källan för att fånga INSERT-, UPDATE- och DELETE-åtgärder som sker medan den fullständiga inläsningen pågår. När den fullständiga inläsningen är klar spelar DMS upp de fångade ändringarna på målet och minskar gradvis skillnaden. När latensen sjunker till nära noll är databasen redo för växling. CDC kräver att SQL Server Agent körs och att källdatabasen använder läget full recovery.

När CDC-fördröjningen är minimal initierar Ni växlingen i DMS-portalen. DMS slutar ta emot nya CDC-händelser, tillämpar återstående ändringar och markerar migreringen som slutförd. Därefter omdirigerar Ni programmets anslutningssträngar till Azure SQL-slutpunkten. Kör frågor för datavalidering som jämför radantal och kontrollsummeaggregat mellan källa och mål för kritiska tabeller. Behåll källdatabasen i skrivskyddat läge i 24–48 timmar efter växlingen, ifall en återställning skulle behövas.

Efter migreringen kan Azure SQL Database fungera annorlunda än SQL Server lokalt, på grund av skillnader i cachelagring av frågeplaner, statistik och maskinvara. Kör Database Experimentation Assistant (DEA) för att spela upp arbetsbelastningsspår på Azure-målet och jämföra exekveringsplaner. Aktivera Automatic Tuning i Azure SQL så att tjänsten automatiskt kan skapa eller ta bort index och tvinga fram frågeplaner utan prestandaregressioner, vilket förbättrar prestandan över tid utan manuella åtgärder.

DMS migrerar även open source-motorer: MySQL till Azure Database for MySQL med mönstret mysqldump + binlog replication och PostgreSQL till Azure Database for PostgreSQL med logiska replikeringsplatser. Vid migreringar från MongoDB till Cosmos DB använder Ni Cosmos DB for MongoDB API och den inbyggda pipelinen mongodump / mongorestore eller Azure Data Factorys MongoDB-anslutning för inkrementell CDC. Testa alltid migreringen på en kopia som inte är en produktionsmiljö innan Ni kör den mot aktiva data.

I den här lektionen har Ni lärt Er att Azure Database Migration Service samordnar online- och offlinemigreringar av databaser, att förmigreringsutvärdering med DMA upptäcker kompatibilitetsproblem före migreringsfönstret och att change data capture möjliggör växling med nästan ingen driftstoppstid för produktionsdatabaser. Nästa avsnitt handlar om att optimera Azure-kostnader.