Dela via

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

  • Artikel

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 som baseras på SQL Server-loggleveransteknik.

Kom igång genom att läsa Migrera databaser från SQL Server till Azure SQL Managed Instance med hjälp av Log Replay Service.

När du ska använda Log Replay Service

Azure Database Migration Service, Azure SQL-migreringstillägget för Azure Data Studio och LRS använder alla 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, när:

  • Du behöver mer kontroll för databasmigreringsprojektet.
  • Det finns liten tolerans för stilleståndstid under snabb migrering.
  • Det går inte att 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.
  • Azure SQL-migreringstillägget kan inte installeras i din miljö eller så kan det inte komma åt dina säkerhetskopior av databasen.
  • Ingen åtkomst till värdoperativsystemet är tillgänglig, eller så finns det inga 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.

Följande källor stöds:

  • 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)

Kommentar

  • Vi rekommenderar att du automatiserar migreringen av databaser från SQL Server till Azure SQL Managed Instance med hjälp av Azure SQL-migreringstillägget för Azure Data Studio. Överväg att använda LRS för att samordna migreringar när Azure SQL-migreringstillägget inte har fullt stöd för dina scenarier.
  • LRS är den enda metoden för att återställa differentiella säkerhetskopior på 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. Fullständiga säkerhetskopieringar, loggsäkerhetskopior och differentiella säkerhetskopior stöds. 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 läggs till efter att den fullständiga säkerhetskopian 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 inte någon specifik namngivningskonvention för säkerhetskopierade filer. 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ällningstillstånd under migreringsprocessen. Databaser återställs 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/files och 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 någon CHECKSUM aktivering för säkerhetskopior rekommenderar vi det starkt. Det tar längre tid att återställa databaser eftersom CHECKSUM SQL Managed Instance utför en integritetskontroll av säkerhetskopior som återställs utan CHECKSUM aktiverad.

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

Varning

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 automatiskt kompletteringslä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 startats. 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 har återställts. 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 detta läge för aktiva arbetsbelastningar som kräver datahämtning. 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 genomsöker regelbundet Azure Blob Storage-mappen och återställer eventuella nya logg- eller differentiella säkerhetskopieringsfiler som hittas.

När du är redo för snabbåtgärden stoppar du arbetsbelastningen på SQL Server-instansen, genererar den sista säkerhetskopieringsfilen och laddar sedan upp den. Kontrollera att den senaste säkerhetskopieringsfilen har återställts genom att kontrollera att den sista loggsvanssäkerhetskopian visas som återställd på SQL Managed Instance. Initiera sedan manuell snabbning. 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 automatisk komplettering eller manuellt via snabb åtkomst, kan du inte återuppta återställningsprocessen för en databas som har aktiverats 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

Ett typiskt migreringsarbetsflöde visas i följande bild och stegen beskrivs i tabellen.

Du behöver bara använda 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 där det inte krävs någon 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 för vilka datahämtning krävs.

Diagram that illustrates the Log Replay Service orchestration steps for SQL Managed Instance.

Operation Details
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. Du kan 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 LRS startas i automatiskt kompletteringsläge återställs alla säkerhetskopior via den angivna senaste säkerhetskopieringsfilen. Alla säkerhetskopierade filer måste laddas upp i förväg och det går inte att lägga till några nya säkerhetskopierade filer medan migreringen pågår. Det här läget rekommenderas för passiva arbetsbelastningar där det inte krävs någon datahämtning.

När LRS startas i kontinuerligt läge återställer den alla säkerhetskopior som ursprungligen laddades upp och bevakar sedan eventuella nya filer som har laddats upp till mappen. Tjänsten tillämpar kontinuerligt loggar baserat på LSN-kedjan (loggsekvensnummer) tills den stoppas manuellt. Vi rekommenderar det här läget för aktiva arbetsbelastningar för vilka datahämtning krävs.
2.1. Övervaka åtgärdens förlopp. Du kan övervaka förloppet för återställningsåtgärden med PowerShell (get-azsqlinstancedatabaselogreplay) eller Azure CLI (az_sql_midb_log_replay_show cmdletar).
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 LRS startades i automatiskt kompletteringsläge slutförs migreringen automatiskt efter att den angivna senaste säkerhetskopieringsfilen har återställts.

Om LRS startades i kontinuerligt läge stoppar du programmet och arbetsbelastningen. Ta den senaste loggsvanssäkerhetskopian och ladda upp den till Azure Blob Storage-distributionen. Kontrollera att den senaste loggsvanssäkerhetskopian har återställts på den hanterade instansen. Slutför snabben genom att initiera en LRS-åtgärd complete med PowerShell (complete-azsqlinstancedatabaselogreplay) eller 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.

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

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 avbryter systemuppdateringar och förlänger migreringsjobben. Vi rekommenderar starkt att du använder ett 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 allmänna hanterade instanser, och de startas om för Affärskritisk 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

Du startar migreringen genom att starta LRS. Du kan starta tjänsten i antingen automatiskt kompletteringsläge eller kontinuerligt läge. Mer information finns i Migrera med LRS.

  • Autokompletteringsläge. När du använder automatiskt kompletteringsläge slutförs migreringen automatiskt när den sista av de angivna säkerhetskopieringsfilerna har återställts. 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 du använder automatiskt kompletteringsläge för passiva arbetsbelastningar som inte behöver komma ifatt data.

  • 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 efter att den manuella snabbåtgärden har begärts.

    Du måste använda 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.

Kommentar

När du migrerar flera databaser måste LRS startas separat för varje databas som pekar på den fullständiga URI-sökvägen för Azure Blob Storage-containern och den enskilda databasmappen.

LRS-begränsningar

Överväg följande begränsningar i LRS:

  • Endast databas .bak, .logoch .diff filer stöds av LRS. Dacpac- och bacpac-filer stöds inte.
  • Under migreringsprocessen kan databaser som migreras inte användas för skrivskyddad åtkomst på SQL Managed Instance.
  • Du måste konfigurera ett underhållsperiod för att tillåta schemaläggning av systemuppdateringar vid en viss dag och tidpunkt. Planera att köra och slutföra migreringar utanför det schemalagda underhållsfönstret.
  • Databassäkerhetskopior som tas utan CHECKSUM tar längre tid att återställa än databassäkerhetskopior med CHECKSUM aktiverat.
  • Den SAS-token (signatur för delad åtkomst) som LRS använder måste genereras för hela Azure Blob Storage-containern och den måste endast ha läs- och listbehörighet. Om du till exempel beviljar läs-, list- och skrivbehörigheter kan LRS inte starta på grund av den extra skrivbehörigheten.
  • Det går inte att använda SAS-token som skapats med behörigheter som anges genom att definiera en lagrad åtkomstprincip . Följ anvisningarna i den här artikeln om du vill ange läs- och listbehörigheter manuellt för SAS-token.
  • Du måste placera säkerhetskopieringsfiler för olika databaser i separata mappar på Blob Storage-kontot i en platt filstruktur. Kapsling av mappar i databasmappar stöds inte.
  • Om du använder automatiskt kompletteringsläge måste hela säkerhetskopieringskedjan vara tillgänglig i förväg på Blob Storage-kontot. Det går inte att lägga till nya säkerhetskopieringsfiler i automatiskt kompletteringsläge. Använd kontinuerligt läge om du behöver lägga till nya säkerhetskopierade filer medan migreringen pågår.
  • Du måste starta LRS separat för varje databas som pekar på den fullständiga URI-sökvägen som innehåller en enskild databasmapp.
  • Säkerhetskopierings-URI-sökvägen, containernamnet eller mappnamnen ska inte innehålla backup eller backups eftersom dessa är reserverade nyckelord.
  • När du startar flera Log Replay-återställningar parallellt, med samma lagringscontainer som mål, kontrollerar du att samma giltiga SAS-token tillhandahålls för varje återställningsåtgärd.
  • LRS kan stödja upp till 100 samtidiga återställningsprocesser per enskild hanterad instans.
  • Ett enda LRS-jobb kan köras i högst 30 dagar, varefter det avbryts automatiskt.
  • Även om det är möjligt att använda ett Azure Storage-konto bakom en brandvägg krävs extra konfiguration, och lagringskontot och den hanterade instansen måste antingen finnas i samma region eller i två parkopplade regioner. Mer information finns i Konfigurera brandvägg .

Dricks

Om du kräver att en databas ska vara skrivskyddad under migreringen, med en mycket längre tidsram för att utföra migreringen och med minimal stilleståndstid, bör du överväga att använda länkfunktionen Azure SQL Managed Instance som en rekommenderad migreringslösning.

Nästa steg