Dela via

Översikt över Log Replay Service med Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln innehåller en översikt över Log Replay Service (LRS), som du kan använda för att migrera databaser från SQL Server till Azure SQL Managed Instance. LRS är en kostnadsfri molntjänst som är tillgänglig för Azure SQL Managed Instance och baseras på SQL Server-loggleveransteknik.

Obs.

Nu kan du migrera din SQL Server-instans som aktiveras av Azure Arc till Azure SQL Managed Instance direkt via Azure-portalen. Mer information finns i Migrera till Azure SQL Managed Instance.

Eftersom LRS återställer sql Server-standardsäkerhetsfiler kan du använda den för att migrera från SQL Server som finns var som helst (antingen lokalt eller i molnet) till Azure SQL Managed Instance.

Om du vill starta migreringen med LRS läser du Migrera databaser från SQL Server med hjälp av Log Replay Service.

Viktig

Innan du migrerar databaser till tjänstnivån Affärskritisk bör du överväga dessa begränsningar, som inte gäller för tjänstnivån Generell användning.

När du ska använda Log Replay Service

Azure Database Migration Serviceanvänder Azure SQL-migreringstillägget för Azure Data Studiooch LRS samma underliggande migreringsteknik och API:er. LRS möjliggör dessutom komplexa anpassade migreringar och hybridarkitekturer mellan lokala SQL Server-instanser och SQL Managed Instance-distributioner.

När du inte kan använda Azure Database Migration Service eller Azure SQL-tillägget för migrering kan du använda LRS direkt med PowerShell, Azure CLI-cmdletar eller API:er för att manuellt skapa och samordna databasmigreringar till SQL Managed Instance.

Överväg att använda LRS i följande fall:

  • Du behöver mer kontroll för databasmigreringsprojektet.
  • Det finns liten tolerans för driftstopp under migreringsövergången.
  • Du kan inte installera den körbara filen Database Migration Service i din miljö.
  • Den körbara filen Database Migration Service har inte filåtkomst till dina databassäkerhetskopior.
  • Du kan inte installera Azure SQL-migreringstillägget i din miljö eller så kan det inte komma åt dina säkerhetskopior av databasen.
  • Du har ingen åtkomst till värdoperativsystemet eller administratörsbehörigheter.
  • Du kan inte öppna nätverksportar från din miljö till Azure.
  • Problem med nätverksbegränsning eller proxyblockering finns i din miljö.
  • Säkerhetskopior lagras direkt i Azure Blob Storage-konton via alternativet TO URL.
  • Du måste använda differentiella säkerhetskopior.

Eftersom LRS fungerar genom att återställa sql Server-standardsäkerhetskopieringsfiler stöder det migreringar från alla källor. Följande källor har testats:

  • SQL Server lokalt installerad/box
  • SQL Server på virtuella datorer
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relationsdatabastjänst) för SQL Server
  • Google Compute Engine
  • Cloud SQL för SQL Server – GCP (Google Cloud Platform)
  • Alibaba Cloud RDS för SQL Server

Om du stöter på oväntade problem när du migrerar från en olistad källa, öppna ett supportärende för hjälp.

Obs.

  • LRS är den enda metoden för att återställa differentiella säkerhetskopior på SQL-hanterade instanser. Det går inte att återställa differentiella säkerhetskopior manuellt på hanterade instanser eller att manuellt ställa in NORECOVERY läget med hjälp av T-SQL.

Så här fungerar LRS

Att skapa en anpassad lösning för att migrera databaser till molnet med LRS kräver flera orkestreringssteg, som visas i diagrammet och tabellen senare i det här avsnittet.

Migrering består av databassäkerhetskopior på SQL Server och kopiering av säkerhetskopieringsfiler till ett Azure Blob Storage-konto. LRS stöder fullständiga säkerhetskopieringar, logg- och differentiella säkerhetskopior. Sedan använder du LRS-molntjänsten för att återställa säkerhetskopierade filer från Azure Blob Storage-kontot till SQL Managed Instance. Blob Storage-kontot fungerar som mellanlagring för säkerhetskopieringsfiler mellan SQL Server och SQL Managed Instance.

LRS övervakar ditt Blob Storage-konto för eventuella nya differentiella säkerhetskopior eller loggsäkerhetskopior som du lägger till när den fullständiga säkerhetskopieringen har återställts. LRS återställer sedan automatiskt dessa nya filer. Du kan använda tjänsten för att övervaka förloppet för säkerhetskopieringsfiler som återställs till SQL Managed Instance och stoppa processen om det behövs.

LRS kräver ingen specifik namngivningskonvention för säkerhetskopieringsfiler. Den söker igenom alla filer som placerats i Azure Blob Storage-kontot och konstruerar säkerhetskopieringskedjan från att endast läsa filhuvudena. Databaser är i ett återställnings- läge under migreringsprocessen. LRS återställer databaser i NORECOVERY-läge , så de kan inte användas för läs- eller skrivarbetsbelastningar förrän migreringsprocessen är klar.

Om du migrerar flera databaser måste du:

  • Placera säkerhetskopieringsfiler för varje databas i en separat mapp på Blob Storage-kontot i en platt filstruktur. Använd till exempel separata databasmappar: blobcontainer/database1/files, blobcontainer/database2/filesoch så vidare.
  • Använd inte kapslade mappar i databasmappar eftersom den kapslade mappstrukturen inte stöds. Använd till exempel inte undermappar som blobcontainer/database1/subfolder/files.
  • Starta LRS separat för varje databas.
  • Ange olika URI-sökvägar för att avgränsa databasmappar på Blob Storage-kontot.

Även om det inte krävs CHECKSUM aktiverat för säkerhetskopieringar rekommenderar vi det starkt. Det tar längre tid att återställa databaser utan CHECKSUM eftersom SQL Managed Instance utför en integritetskontroll av säkerhetskopior som återställs utan CHECKSUM aktiverat.

Mer information finns i Migrera databaser från SQL Server med hjälp av Log Replay Service.

Försiktighet

Säkerhetskopieringar på SQL Server med CHECKSUM aktiverad rekommenderas starkt eftersom det finns en risk för att återställa en skadad databas till Azure utan den.

Automatisk komplettering jämfört med migrering i kontinuerligt läge

Du kan starta LRS i antingen autofyllnadsläge eller kontinuerligt läge.

Använd automatiskt kompletteringsläge när du har skapat hela säkerhetskopieringskedjan i förväg och när du inte planerar att lägga till fler filer när migreringen har startat. Det här migreringsläget rekommenderas för passiva arbetsbelastningar som inte kräver datahämtning. Ladda upp alla säkerhetskopierade filer till Blob Storage-kontot och starta migreringen av automatiskt kompletteringsläge. Migreringen slutförs automatiskt när den senast angivna säkerhetskopieringsfilen återställs. Den migrerade databasen blir tillgänglig för läs-/skrivåtkomst på SQL Managed Instance.

Om du planerar att fortsätta lägga till nya säkerhetskopierade filer medan migreringen pågår använder du kontinuerligt läge. Vi rekommenderar det här läget för aktiva arbetsbelastningar som kräver att data kommer ifatt. Ladda upp den för närvarande tillgängliga säkerhetskopieringskedjan till Blob Storage-kontot, starta migreringen i kontinuerligt läge och fortsätt att lägga till nya säkerhetskopieringsfiler från din arbetsbelastning efter behov. Systemet söker regelbundet igenom Azure Blob Storage-mappen och återställer eventuella nya logg- eller differentiella säkerhetskopieringsfiler som hittas.

När du är redo för övergången, stoppar du belastningen på SQL Server-instansen, genererar den sista säkerhetskopian och laddar sedan upp den. Se till att den senaste säkerhetskopieringsfilen återställs genom att verifiera att den sista loggsvanssäkerhetskopian visas som återställd på SQL Managed Instance. Initiera sedan manuell övergång. Det sista snabbsteget gör databasen online och tillgänglig för läs-/skrivåtkomst på SQL Managed Instance.

När LRS har stoppats, antingen automatiskt via autoslut eller manuellt via övergång, kan återställningsprocessen inte återupptas för en databas som du gjorde tillgänglig online på SQL Managed Instance. När migreringen är klar kan du till exempel inte längre återställa fler differentiella säkerhetskopior för en onlinedatabas. Om du vill återställa fler säkerhetskopierade filer när migreringen är klar måste du ta bort databasen från den hanterade instansen och starta om migreringen från början.

Arbetsflöde för migrering

Bilden i det här avsnittet visar ett typiskt migreringsarbetsflöde medan tabellen beskriver stegen.

Använd endast automatiskt kompletteringsläge när alla säkerhetskopieringskedjefiler är tillgängliga i förväg. Vi rekommenderar det här läget för passiva arbetsbelastningar som inte kräver datahämtning.

Använd migrering i kontinuerligt läge när du inte har hela säkerhetskopieringskedjan i förväg och när du planerar att lägga till nya säkerhetskopieringsfiler när migreringen pågår. Vi rekommenderar det här läget för aktiva arbetsbelastningar som kräver att data kommer ifatt.

Diagram som illustrerar log replay-tjänstens orkestreringssteg för SQL Managed Instance.

Verksamhet Detaljer
1. Kopiera databassäkerhetskopior från SQL Server-instansen till Blob Storage-kontot. Kopiera fullständiga säkerhetskopior, differentiella säkerhetskopior och loggsäkerhetskopior från SQL Server-instansen till Blob Storage-containern med hjälp av AzCopy eller Azure Storage Explorer.

Använd alla filnamn. LRS kräver ingen specifik filnamngivningskonvention.

Använd en separat mapp för varje databas när du migrerar flera databaser.
2. Starta LRS i molnet. Starta tjänsten med PowerShell (start-azsqlinstancedatabaselogreplay) eller Azure CLI (az_sql_midb_log_replay_start cmdlets). Välj mellan automatiskt kompletteringsläge eller kontinuerligt migreringsläge.

Starta LRS separat för varje databas som pekar på en säkerhetskopieringsmapp på Blob Storage-kontot.

När tjänsten har startats tar den säkerhetskopior från Blob Storage-containern och börjar återställa dem till SQL Managed Instance.

När du startar LRS i automatiskt kompletteringsläge återställs alla säkerhetskopior via den angivna senaste säkerhetskopieringsfilen. Du måste ladda upp alla säkerhetskopierade filer i förväg och du kan inte lägga till några nya säkerhetskopierade filer medan migreringen pågår. Det här läget rekommenderas för passiva arbetsbelastningar som inte kräver datahämtning.

När du startar LRS i kontinuerligt läge återställs alla säkerhetskopior som du först laddade upp och bevakar sedan eventuella nya filer som du laddar upp till mappen. Tjänsten tillämpar kontinuerligt loggar baserat på loggsekvensnummerkedjan (LSN) tills den stoppas manuellt. Vi rekommenderar det här läget för aktiva arbetsbelastningar som kräver att data kommer ifatt.
2.1. Övervaka åtgärdens förlopp. Övervaka förloppet för den pågående återställningsåtgärden med PowerShell (get-azsqlinstancedatabaselogreplay) eller Azure CLI (az_sql_midb_log_replay_show cmdlets). Om du vill spåra ytterligare information om en misslyckad begäran använder du PowerShell-kommandot Get-AzSqlInstanceOperation eller använder Azure CLI-kommandot az sql mi op show.
2.2. Stoppa åtgärden om det behövs (valfritt). Om du behöver stoppa migreringsprocessen använder du PowerShell (stop-azsqlinstancedatabaselogreplay) eller Azure CLI (az_sql_midb_log_replay_stop).

Om du stoppar åtgärden tas databasen som du återställer till SQL Managed Instance bort. När du har stoppat en åtgärd kan du inte återuppta LRS för en databas. Du måste starta om migreringsprocessen från början.
3. Klipp över till molnet när du är redo. Om du startar LRS i automatiskt kompletteringsläge slutförs migreringen automatiskt efter att den angivna senaste säkerhetskopieringsfilen har återställts.

Om du startar LRS i kontinuerligt läge stoppar du programmet och arbetsbelastningen. Ta den senaste transaktionsloggsäkerhetskopian och ladda upp den till distributionen i Azure Blob Storage. Se till att den senaste säkerhetskopieringen av loggen återställs på den SQL-hanterade instansen. Slutför övergången genom att initiera en LRS-complete-operation med PowerShell (complete-azsqlinstancedatabaselogreplay) eller med Azure CLI-az_sql_midb_log_replay_complete. Den här åtgärden stoppar LRS och gör att databasen är online för läs-/skrivarbetsbelastningar på SQL Managed Instance.

Ompeka anslutningssträngen för applikationen från SQL Server-instansen till SQL Managed Instance. Du måste orkestrera det här steget själv, antingen via en manuell ändring av anslutningssträngen i ditt program eller automatiskt (till exempel om programmet kan läsa anslutningssträngen från en egenskap eller en databas).

Viktig

Efter övergången kan SQL Managed Instance med Business Critical tjänstnivå ta betydligt längre tid än General Purpose för att vara tillgänglig eftersom tre sekundära repliker måste seedas för tillgänglighetsgruppen. Varaktigheten för åtgärden beror på datastorleken. För mer information, se varaktigheten för hanteringsåtgärder .

Migrera stora databaser

Om du migrerar stora databaser med flera terabyte i storlek bör du tänka på följande:

  • Ett enda LRS-jobb kan köras i högst 30 dagar. När den här perioden upphör att gälla avbryts jobbet automatiskt.
  • För långvariga jobb kan systemuppdateringar avbryta och förlänga migreringsjobb. Vi rekommenderar starkt att du använder en underhållsperiod för att schemalägga planerade systemuppdateringar. Planera migreringen runt det schemalagda underhållsfönstret.
  • Migreringsjobb som avbryts av systemuppdateringar pausas och återupptas automatiskt för generella SQL-hanterade instanser, och de startas om för affärskritiska SQL-hanterade instanser. Dessa uppdateringar påverkar tidsramen för migreringen.
  • Om din infrastruktur har tillräcklig nätverksbandbredd kan du överväga att använda parallellisering med flera trådar för att öka uppladdningshastigheten för dina SQL Server-säkerhetskopieringsfiler till Blob Storage-kontot.

Starta migreringen

Starta migreringen genom att starta LRS. Du kan starta tjänsten i antingen automatiskt kompletteringsläge eller kontinuerligt läge. Mer information finns i Migrera databaser från SQL Server med hjälp av Log Replay Service.

  • Automatiskt kompletteringsläge. När du använder automatiskt kompletteringsläge slutförs migreringen automatiskt när den sista av de angivna säkerhetskopieringsfilerna återställs. Det här alternativet:

    • Kräver att hela säkerhetskopieringskedjan är tillgänglig i förväg och laddas upp till Azure Blob Storage-kontot.
    • Tillåter inte att nya säkerhetskopieringsfiler läggs till medan migreringen pågår.
    • Kräver startkommandot för att ange filnamnet för den senaste säkerhetskopieringsfilen.

    Vi rekommenderar att använda autokompletteringsläge för passiva arbetsbelastningar där datainhämtning inte krävs.

  • Kontinuerligt läge. När du använder kontinuerligt läge söker tjänsten kontinuerligt igenom Mappen Azure Blob Storage och återställer alla nya säkerhetskopieringsfiler som läggs till medan migreringen pågår.

    Migreringen slutförs först när du har begärt den manuella övergången.

    Använd migrering i kontinuerligt läge när du inte har hela säkerhetskopieringskedjan i förväg och när du planerar att lägga till nya säkerhetskopieringsfiler när migreringen pågår.

    Vi rekommenderar att du använder kontinuerligt läge för aktiva arbetsbelastningar för vilka datahämtning krävs.

Planera att slutföra ett enda LRS-migreringsjobb inom högst 30 dagar. När den här perioden går ut avbryts LRS-jobbet automatiskt.

Obs.

När du migrerar flera databaser måste varje databas finnas i en egen mapp. Starta LRS separat för varje databas och peka på den fullständiga URI-sökvägen för Azure Blob Storage-containern och den enskilda databasmappen. Kapslade mappar i databasmappar stöds inte.

Begränsningar i LRS

För information, se begränsningar vid användning av LRS.

Relaterat innehåll