Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
Azure SQL Managed Instance
Den här artikeln jämför Log Replay Service (LRS) med länken Hanterad instans när du migrerar till Azure SQL Managed Instance.
Översikt
Log Replay Service (LRS) har använts för migreringar till Azure SQL Managed Instance sedan tjänsten lanserades i november 2018. Under huven förlitar sig LRS på implementeringen av loggleverans, som även driver Azure Database Migration Service (DMS) och Azure SQL-migreringstillägget för Azure Data Studio.
I mars 2022 introducerades länken för hanterad instans (MI-länk) som ett mer högpresterande migreringsalternativ, med ett löfte om bästa möjliga minsta stilleståndstidsmigrering. Länken Hanterad instans använder distribuerad AlwaysOn-tillgänglighetsgruppsteknik för att replikera data nära realtid från SQL Server till Azure SQL Managed Instance. Med hjälp av länken kan du också återgå till online-läge från SQL Managed Instance till SQL Server 2022 eller senare som en försäkring vid migrering.
LRS och MI-länken kompletterar varandra i funktioner, där varje teknik passar olika affärsbehov. Granska funktionerna i varje verktyg för att avgöra vilket som är bäst att använda för migrering baserat på dina specifika omständigheter.
Jämför LRS- och MI-länk
Den grundläggande skillnaden mellan LRS och MI-länken beror på den underliggande tekniken. Eftersom LRS baseras på loggleverans hämtas differentiella och transaktionsloggssäkerhetskopior kontinuerligt från SQL Server, laddas upp till Azure Blob Storage och återställs till SQL Managed Instance. Processen är inte i realtid eftersom det tar tid att säkerhetskopiera filer, ladda upp dem och återställa dem. Prestandan för LRS baseras på storleken på säkerhetskopieringsklumparna.
Däremot använder MI-länken AlwaysOn-tillgänglighetsgruppteknik för att skicka transaktionsloggposter nästan i realtid från SQL Server till SQL Managed Instance, vilket gör det till en betydligt mer högpresterande migreringslösning. Men för att konfigurera MI-länken måste du konfigurera ett VPN mellan SQL Server och SQL Managed Instance och öppna lämpliga portar i brandväggen medan LRS fungerar direkt med hjälp av en offentlig slutpunkt. LRS kan användas för alla utgåvor av SQL Server 2008 och senare, medan MI-länk kan användas för SQL Server 2016 och senare, endast för Standard-, Enterprise- och Developer-utgåvor.
Anmärkning
Förhandsversionen av SQL Server 2025 introducerar separata versioner av SQL Server för företagsutvecklare och standardutvecklare.
En stor fördel med MI-länken är möjligheten att utföra en omvänd migrering tillbaka till SQL Server 2022 och senare, vilket inte är möjligt med LRS. En annan viktig fördel med att migrera med MI-länken är att databasen på SQL Managed Instance kan användas för skrivskyddade arbetsbelastningar medan migreringen pågår. Den här funktionen är inte tillgänglig med LRS eftersom databasen är i ett återställningstillstånd tills migreringen är klar. På samma sätt, när du utför en omvänd migrering tillbaka till SQL Server 2022 och senare, är databasen tillgänglig för skrivskyddade arbetsbelastningar på SQL Server medan migreringen pågår.
I följande tabell jämförs både LRS- och MI-länken i detalj:
| Funktionalitet | Länk till hanterad instans (MI-länk) | Log Replay Service (LRS) | Anteckningar |
|---|---|---|---|
| Underliggande teknik | Distribuerade tillgänglighetsgrupper (AG) | Loggöverföring | MI-länken använder en distribuerad tillgänglighetsgrupp för replikering, vilket är nyare och mer avancerat jämfört med loggleveranstekniken som används av LRS. |
| Replikeringsprestanda | Nästan i realtid. | Återställs med några minuters mellanrum. | Replikering av data via MI-länken är betydligt mer högpresterande än att tillämpa säkerhetskopieringar av transaktionsloggar med LRS. |
| Lägsta källversion som stöds | SQL Server 2016 och senare | SQL Server 2008 och senare | LRS kan ha stöd för mycket äldre SQL Server-versioner än MI-länk. |
| Lägsta Windows Server-version som stöds | Windows Server 2012 R2 | Windows Server 2008 | LRS kan ha stöd för mycket äldre Windows Server-versioner än MI-länk. |
| Skrivskyddad sekundär | Stöds. | Stöds inte. | Medan replikeringen pågår kan SQL Managed Instance-databaser som replikeras via länken användas för skrivskyddade arbetsbelastningar, vilket gör att du kan testa migreringen innan du skär över eller använda dina databaser innan du migrerar till Azure. På samma sätt, när du utför en omvänd migrering tillbaka till SQL Server 2022 och senare, är databasen tillgänglig för skrivskyddade arbetsbelastningar på SQL Server medan migreringen pågår. Den här funktionen är inte tillgänglig med LRS. |
| Replikering av TDE-krypterade databaser | Ja, kräver import av säkerhetsnycklar till SQL Managed Instance. | Ja, kräver import av säkerhetsnycklar till SQL Managed Instance. | Kravet och proceduren för att migrera motsvarande krypteringscertifikat från SQL Server till sql-hanterad instans innan migreringen påbörjas är densamma för båda migreringsalternativen. |
| Nätverksanslutningstyp | – Privat slutpunkt – VPN som konfigurerats med både inkommande och utgående portar |
Offentlig slutpunkt | Även om MI-länken ger ytterligare säkerhetslager och erbjuder ett VPN som ett alternativ, är nätverk svårare att konfigurera jämfört med LRS. Som standard ger LRS en förenklad upplevelse så att du kan använda den omedelbart utan någon nätverks- eller VPN-konfiguration. LRS använder en offentlig slutpunkt som standard, vilket är mindre säkert än VPN som används med MI-länken, och det kanske inte uppfyller några av de mest krävande säkerhetskrav eftersom det använder ett offentligt exponerat Azure Blob Storage-konto som mellanhand för att spara data innan det återställs till SQL Managed Instance. Även om det är möjligt att använda en privat slutpunkt med LRS för att göra överföringen av data säkrare, ökar den inledande konfigurationskomplexiteten. |
| Datakryptering vid överföring | – Data krypterade med AES och – SSL används för kryptering av dataöverföring. |
SSL används för kryptering av dataöverföring. | MI-länken använder ytterligare ett AES-krypteringslager för data. SSL används för överföring av data för migreringsverktyg. |
| Autentisering för replikering | Certifikat som signerats av en betrodd utfärdare (CA) | Hanterade identiteter eller SAS-token | MI-länken kräver att en certifikatutfärdare (CA) signerar ett certifikat för autentisering. För LRS är det säkrare att använda hanterade identiteter än att använda självgenererade SAS-token. |
| Påverkas av systemuppdateringar eller felövergång | Nej, förutom ett kort avbrott för en kort omkoppling. | – För generell användning pausas migreringen automatiskt och återupptas efter avbrott. – För affärskritiska instanser avbryts migreringsprocessen för avbrott och måste startas om manuellt. |
MI-länken är elastisk och migreringen påverkas inte av SQL Managed Instance-redundansväxlingar. Omvänt fördröjs LRS-migreringar av omstarter eller redundansväxlingar av SQL-hanterade instanser på tjänstnivån Generell användning och migreringen startas om för instanser på tjänstnivån Affärskritisk. |
| Replikeringstid | Obegränsad replikeringstid med hjälp av länken (månader och till och med år i taget). | LRS-jobbet kan köras i upp till 30 dagar. | En MI-länk kan köras under en obegränsad tid. LRS är begränsad till maximalt 30 dagars kontinuerlig loggöverföring, varefter migreringen stoppas automatiskt och behöver påbörjas från början. |
| Typ av migrering | Sann onlinemigrering med endast en kort redundansväxling (mätt i sekunder). | – Onlinemigrering med förväntad stilleståndstid under övergången för den tid som krävs för att återställa den senaste säkerhetskopian. – Övergången tar betydligt längre tid för databasinstanser på tjänstnivån Affärskritisk. |
MI-länken är den enda lösningen som erbjuder en lösning för minsta stilleståndstid (<1 minut) för alla SQL Managed Instance-tjänstnivåer. Med LRS håller den sista säkerhetskopieringsfilen fortfarande på att återställas under övergångsprocessen, så beroende på storleken på den sista säkerhetskopieringsfilen och den tid det tar att återställa den kan det uppstå en betydande väntan tills databasen blir tillgänglig på SQL Managed Instance. När du använder LRS för att migrera till tjänstnivån Affärskritisk kan stilleståndstiden för migreringen vara betydligt längre eftersom hela databasen måste replikeras till de sekundära noderna från den primära noden innan databasen är tillgänglig för arbetsbelastningar på den primära. Beroende på den totala databasstorleken kan replikering till de andra noderna, och därmed stilleståndstid, ibland ta timmar. Därför kan databaser komma online betydligt långsammare med LRS än med MI-länken, som kan vara nästan omedelbar. |
| Underhåll krävs på källan | Ja, regelbundna säkerhetskopieringar av transaktionsloggar. | Nej. | MI-länken kräver regelbundna säkerhetskopieringar av transaktionsloggen för SQL Server-källinstansen under migreringen för att trunkera transaktionsloggen och förhindra att diskutrymmet börjar ta slut. Däremot krävs inget underhåll för LRS. |
| Återhämtning | Återupptar automatiskt länkreplikeringen om SQL Server startas om. | – Migreringen stannar om det finns en bruten säkerhetskopieringskedja eller en felaktigt angiven sista säkerhetskopieringsfil. – Stöder inte säkerhetskopiering av filer från flera databaser i samma mapp (migreringen misslyckas). |
MI-länken är mer elastisk än LRS eftersom replikeringen automatiskt återupptas efter problem (till exempel oväntad stilleståndstid, uppgraderingar, förlust av nätverksanslutning och många andra) har lösts. Dessutom är MI-länken motståndskraftig mot SQL MI-felövergångar eller tjänstuppdateringar. Vissa villkor resulterar i att LRS stannar. LRS-migrering startas om automatiskt om migreringen till tjänstnivån Generell användning avbryts, men måste startas om om en migrering till tjänstnivån Affärskritisk avbryts. |
| Omvänd migrering från SQL MI tillbaka till SQL Server | Offline- och onlinemigrering tillbaka till SQL Server 2022 och senare stöds. | Stöds inte. | MI-länken är den enda lösningen som erbjuder omvänd migrering online och offline till SQL Server 2022 och senare versioner – omvänd migrering är inte tillgänglig för äldre versioner av SQL Server. |
Vad ska man välja?
Valet mellan LRS och MI-länken beror på dina omständigheter och affärsbehov. Den anmärkningsvärda skillnaden mellan migreringslösningarna är prestanda. LRS har en enklare inledande konfiguration som gör att du snabbt kan migrera. Även om den inledande konfigurationen för MI-länken är mer komplex, ger den större återhämtning, säkerhet och flexibilitet.
Dessutom är övergångstiden betydligt kortare med MI-länk, vilket är en viktig fördel för många kunder. Faktum är att den potentiellt stora stilleståndstiden vid migrering till tjänstnivån Affärskritisk med LRS är anledningen till att MI-länken kallas den enda "sanna onlinemigreringen" till tjänstnivån Affärskritisk.
Om du behöver databasen tillgänglig för skrivskyddade arbetsbelastningar på migreringsmålet medan migreringen pågår, eller om du behöver utföra en omvänd migrering tillbaka till SQL Server 2022 och senare, är MI-länken det enda alternativet som stöder dessa scenarier.