Dela via


Transaktionsreplikering med Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Transaktionsreplikering är en funktion i Azure SQL Managed Instance och SQL Server som gör att du kan replikera data från en tabell i Azure SQL Managed Instance eller en SQL Server-instans till tabeller som placeras på fjärrdatabaser. Med den här funktionen kan du synkronisera flera tabeller i olika databaser.

Overview

Du kan använda transaktionsreplikering för att skicka ändringar som görs i en Hanterad Azure SQL-instans till att:

  • En SQL Server-databas (lokalt eller på en virtuell Azure-dator)
  • En databas i Azure SQL Database
  • En databas i Azure SQL Hanterad Instans

Note

Om du vill använda alla funktioner i Azure SQL Managed Instance måste du använda de senaste versionerna av SQL Server Management Studio (SSMS) och SQL Server Data Tools (SSDT).

Components

De viktigaste komponenterna i transaktionsreplikeringen är Utgivare, Distributör och Prenumerant, enligt följande bild:

Diagram över replikering med Azure SQL.

Role Azure SQL Database Hanterad instans i Azure SQL
Publisher No Yes
Distributor No Yes
Pull-prenumerant No Yes
Push-prenumerant Yes Yes

Utgivaren publicerar ändringar som gjorts i vissa tabeller (artiklar) genom att skicka uppdateringarna till distributören. Utgivaren kan vara en Hanterad Azure SQL-instans eller en SQL Server-instans.

Distributören samlar in ändringar i artiklarna från en utgivare och distribuerar dem till prenumeranterna. Distributören kan vara antingen en Azure SQL-hanterad instans eller en SQL Server-instans (vilken version som helst så länge den är lika med eller högre än Publisher-versionen).

Prenumeranten mottar ändringar som gjorts av utgivaren. En SQL Server-instans och azure SQL-hanterad instans kan både vara push- och pull-prenumeranter, men en pull-prenumeration stöds inte när distributören är en Azure SQL-hanterad instans och prenumeranten inte är det. En databas i Azure SQL Database kan bara vara push-prenumerant.

Azure SQL Managed Instance kan ha stöd för att vara prenumerant från följande versioner av SQL Server:

Note

För andra versioner av SQL Server som inte stöder publicering till objekt i Azure kan du använda metoden för att publicera om data för att flytta data till nyare versioner av SQL Server.

Försök att konfigurera replikering med en äldre version kan resultera i fel MSSQL_REPL20084 (processen kunde inte ansluta till Prenumerant) och MSSQL_REPL40532 (Det går inte att öppna servernamnet <> som begärdes vid inloggningen. Inloggningen misslyckades).

Typer av replikering

Det finns olika typer av replikering:

Replication Azure SQL Database Hanterad instans i Azure SQL
Standardtransaktion Ja (endast som prenumerant) Yes
Snapshot Ja (endast som prenumerant) Yes
Sammanfoga replikering No No
Peer-to-peer No No
Bidirectional No Yes
Uppdateringsbara prenumerationer No No

Supportmatris

Stödmatrisen för transaktions- och ögonblicksbildreplikering för Azure SQL Managed Instance är samma som för SQL Server:

Publisher Distributor Subscriber
Azure SQL Managed InstanceAUTD Azure SQL Managed InstanceAUTD Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2025
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Azure SQL Managed Instance2025 Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2025
Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2025
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Azure SQL Managed Instance2022 Azure SQL Managed InstanceAUTDAzure SQL Managed Instance2025
Azure SQL Managed Instance2022
Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2022 (16.x) Förhandsversion av SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
Azure SQL Database
SQL-databas i Microsoft Fabric Preview1
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2025
Azure SQL Managed Instance2022
Förhandsversion av SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2019 (15.x) Förhandsversion av SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2025
Azure SQL Managed Instance2022
Förhandsversion av SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2017 (14.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2016 (13.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2014 (12.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)

AUTD gäller för Azure SQL Managed Instance som konfigurerats med Always-up-to-date uppdateringsprincipen.
2025 gäller för Azure SQL Managed Instance som konfigurerats med SQL Server 2025-uppdateringsprincipen.
2022 gäller för Azure SQL Managed Instance som konfigurerats med uppdateringsprincipen SQL Server 2022.
1 Gäller baserat på kraven i de konfigurationer som stöds för SQL-databasen i Microsoft Fabric.

När man ska använda

Transaktionsreplikering är användbart i följande scenarier:

  • Publicera ändringar som gjorts i en eller flera tabeller i en databas och distribuera dem till en eller flera databaser i en SQL Server-instans eller Azure SQL Database som prenumererar på ändringarna.
  • Behåll flera distribuerade databaser i synkroniserat tillstånd.
  • Migrera databaser från en SQL Server-instans eller Azure SQL Managed Instance till en annan databas genom att kontinuerligt publicera ändringarna.

Jämför datasynkronisering med transaktionsreplikering

Category Data Sync Transaktionsreplikering
Advantages – Aktivt stöd
– Dubbelriktad mellan lokal SQL-databas och Azure SQL Database
- Kortare svarstid
– Transaktionskonsekvens
– Återanvänd befintlig topologi efter migrering
Disadvantages – Ingen transaktionskonsekvens
– Högre prestandapåverkan
– Det går inte att publicera från Azure SQL Database
– Höga underhållskostnader

Vanliga konfigurationer

I allmänhet måste utgivaren och distributören vara antingen i molnet eller lokalt. Följande konfigurationer stöds:

Utgivare med lokal distributör på SQL Managed Instance

Enskild instans som utgivare och distributör.

Utgivare och distributör konfigureras i en enda SQL-hanterad instans och distribuerar ändringar till en annan SQL-hanterad instans, SQL Database eller SQL Server-instans.

Utgivare med fjärrdistributör på SQL Managed Instance

I den här konfigurationen publicerar en SQL-hanterad instans ändringar till en distributör som placeras på en annan SQL-hanterad instans som kan hantera många sql-källhanterade instanser och distribuera ändringar till ett eller flera mål i Azure SQL Database, Azure SQL Managed Instance eller SQL Server.

Separata instanser för Publisher och Distributor.

Utgivare och distributör konfigureras på två hanterade instanser. Det finns vissa begränsningar med den här konfigurationen:

  • Båda hanterade instanserna finns i samma virtuella nätverk.
  • Båda hanterade instanserna finns på samma plats.

Lokal utgivare/distributör med fjärrprenumerant

Azure SQL Database som prenumerant.

I den här konfigurationen är en databas i Azure SQL Database eller Azure SQL Managed Instance prenumerant. Den här konfigurationen stöder migrering från lokal plats till Azure. Om en prenumerant är en databas i Azure SQL Database måste den vara i push-läge.

Requirements

  • Använd SQL-autentisering för anslutning mellan replikeringsdeltagare.
  • Använd en Azure Storage-lagringsdelning för den arbetskatalog som används vid replikering.
  • Öppna utgående TCP-port 445 i undernätets säkerhetsregler för att få åtkomst till Azure-filresursen.
  • Öppna utgående TCP-port 1433 när DEN SQL-hanterade instansen är utgivare/distributör och prenumeranten inte är det. Du kan också behöva ändra SQL-hanterad instans NSG:s utgående säkerhetsregel för port 1433 allow_linkedserver_outbound från till virtualnetwork.
  • Placera både utgivaren och distributören i molnet, eller både lokalt.
  • Konfigurera VPN-peering mellan de virtuella nätverken för replikeringsdeltagare om de virtuella nätverken skiljer sig.

Note

Du kan stöta på fel 53 när du ansluter till en Azure Storage-fil om den utgående nätverkssäkerhetsgruppen (NSG) port 445 blockeras när distributören är en Azure SQL Managed Instance-databas och prenumeranten är lokal. Uppdatera den virtuella nätverkssäkerhetsgruppen för att lösa problemet.

Security

TLS 1.3-stöd

Azure SQL Managed Instance har stöd för TLS 1.3 för replikeringsanslutningar som initierats av agenter som konfigurerats för att köras på en SQL-hanterad instans. Detta gäller för en replikeringstopologi mellan två SQL-hanterade instanser och även för alla versioner av SQL Server som prenumerant från en SQL-hanterad instansutgivare och distributör.

Om du använder TLS 1.3 för att skydda anslutningarna mellan instanser i en replikeringstopologi anger du värdet 3 eller 4 för parametern -EncryptionLevel för varje replikeringsagent:

Värdet 3 för framtvingar TLS 1.3-anslutningar till SQL-hanterade instanser, men påverkar inte anslutningar till SQL-servrar. Värdet 4 tvingar TLS 1.3-anslutningar mellan SQL-hanterade instanser. Det gäller också anslutningar från SQL-hanterade instanser till SQL Server och kräver att du installerar certifikatet på värdsystemet för SQL Server.

Logga in replAgentUser

För transaktionsreplikering har en SQL-hanterad instans en i förväg skapad inloggning med namnet replAgentUser. Den här inloggningen är medlem i serverrollen sysadmin och används av replikeringsagenter som behöver ansluta till en SQL-hanterad instans som deltar i konfigurationen av transaktionsreplikering.

Om transaktionsreplikering inte används kan inloggningen replAgentUser inaktiveras. Den kan återaktiveras senare om du bestämmer dig för att börja använda transaktionsreplikering.

Limitations

Transaktionsreplikering har vissa begränsningar som är specifika för Azure SQL Managed Instance. Läs mer om dessa begränsningar i det här avsnittet.

Ögonblicksbildfiler tas inte bort från Azure Storage-kontot

Azure SQL Managed Instance använder användarkonfigurerat Azure Storage-konto för ögonblicksbildfiler som används för transaktionsreplikering. Till skillnad från SQL Server i den lokala miljön tar Azure SQL Managed Instance inte bort ögonblicksbildfiler från Azure Storage-kontot. När filerna inte längre behövs bör du ta bort dem. Detta kan göras via Azure Storage-gränssnittet på Azure-portalen, Microsoft Azure Storage Explorer eller via kommandoradsklienter (Azure PowerShell eller CLI) eller Azure Storage Management REST API.

Här är ett exempel på hur du kan ta bort filen och hur du kan ta bort en tom mapp.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Antal agenter för distribution som kör kontinuerligt

Antalet distributionsagenter som konfigurerats att köras kontinuerligt är begränsat till 30 på Azure SQL Managed Instance. Om du vill ha fler distributionsagenter måste de köras antingen på begäran eller med ett definierat schema. Schemat kan definieras med daglig frekvens och förekomst var 10:e sekund (eller mer), så även om det inte är kontinuerligt kan du fortfarande ha en distributör som introducerar svarstid som bara är flera sekunder. När ett stort antal distributörer behövs rekommenderar vi att du använder schemalagd och inte kontinuerlig konfiguration.

Med redundansgrupper

Användning av transaktionsreplikering med instanser som finns i en redundansgrupp stöds. Men om du konfigurerar replikering innan du lägger till din SQL-hanterade instans i en redundansgrupp pausar replikeringen när du börjar skapa redundansgruppen och replikeringsövervakaren visar statusen Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikeringen återupptas när redundansgruppen har skapats framgångsrikt.

Om en utgivare eller distributör av sql-hanterad instans finns i en redundansgrupp måste SQL-administratören för den hanterade instansen rensa alla publikationer på den gamla primära och konfigurera om dem på den nya primära när en redundansväxling har inträffat. Följande aktiviteter behövs i det här scenariot:

  1. Stoppa alla replikeringsjobb som körs i databasen, om det finns några.

  2. Ta bort prenumerationsmetadata från utgivaren genom att köra följande skript i utgivarens databas. Ersätt värdena för <name of publication> och <name of subscriber>.

    EXEC sp_dropsubscription @publication = '<name of publication>',
        @article = 'all',
        @subscriber = '<name of subscriber>'
    
  3. Ta bort prenumerationsmetadata från prenumeranten. Kör följande skript i prenumerationsdatabasen på den sql-hanterade prenumerantinstansen. Ersätt värdet <full DNS of publisher> . Till exempel example.ac2d23028af5.database.windows.net:

    EXEC sp_subscription_cleanup
       @publisher = N'<full DNS of publisher>',
       @publisher_db = N'<publisher database>',
       @publication = N'<name of publication>';
    
  4. Släpp med kraft alla replikeringsobjekt från utgivaren genom att köra följande skript i den publicerade databasen:

    EXEC sp_removedbreplication;
    
  5. Släpp med kraft den gamla distributören från den ursprungliga primära SQL-hanterade instansen (om du växlar tillbaka till en gammal primär som tidigare hade en distributör). Kör följande skript på master databasen i den gamla sql-hanterade distributörsinstansen:

    EXEC sp_dropdistributor 1, 1;
    

Om en prenumerant-SQL-hanterad instans finns i en redundansgrupp ska publikationen konfigureras för att ansluta till lyssnarslutpunkten för redundansgruppen för prenumerantens SQL-hanterade instans. I händelse av ett failover beror efterföljande åtgärder av administratören för SQL-hanterad instans på vilken typ av failover som inträffade.

  • Vid en redundansväxling utan dataförlust fortsätter replikeringen att fungera efter redundansväxlingen.
  • Vid redundansväxling med dataförlust fungerar också replikering. Den replikerar de förlorade ändringarna igen.
  • Vid en redundansväxling med dataförlust, men dataförlusten ligger utanför kvarhållningsperioden för distributionsdatabasen, måste administratören för DEN SQL-hanterade instansen initiera om prenumerationsdatabasen.

Felsökning av vanliga problem

Transaktionslogg och transaktionsreplikering

I vanliga fall används transaktionsloggen för att registrera ändringar av data i en databas. Ändringar registreras i transaktionsloggen och det gör att logglagringsförbrukningen ökar. Det finns också en automatisk process som möjliggör säker trunkering av transaktionsloggen, och den här processen minskar det använda lagringsutrymmet för loggen. När publicering för transaktionsreplikering konfigureras förhindras trunkering av transaktionsloggen tills ändringar i loggen bearbetas av loggläsarprocessen. I vissa fall blockeras bearbetningen av transaktionsloggen effektivt, och det tillståndet kan leda till att hela lagringen som är reserverad för transaktionsloggen fylls. När det inte finns något ledigt utrymme för transaktionsloggen och det inte finns mer utrymme för att transaktionsloggen ska växa har vi en fullständig transaktionslogg. I det här tillståndet kan databasen inte längre bearbeta någon skrivaktivitet och blir i praktiken en endast läsbar databas.

Inaktiverad loggläsaragent

Ibland är en publikation för transaktionsreplikering konfigurerad för en databas, men loggläsaragenten är inte konfigurerad för att köras. I så fall ackumuleras ändringar i transaktionsloggen och de bearbetas inte. Detta leder till konstant tillväxt av transaktionsloggen och slutligen till den fullständiga transaktionsloggen. Användaren bör se till att loggläsarjobbet finns och är aktivt. Ett alternativ är att inaktivera transaktionsreplikering om det inte behövs.

Tidsgränser för frågekörning för loggläsare

Ibland kan loggläsarjobbet inte göra några effektiva framsteg på grund av upprepade frågeavbrott. Ett sätt att åtgärda tidsgränser för frågor är att öka inställningen för tidsgränsen för frågor för loggläsaragentjobbet.

Du kan öka tidsgränsen för frågor för loggläsarjobbet med SSMS. Leta reda på det jobb som du vill ändra under SQL Server Agent i objektutforskaren. Stoppa det först och öppna sedan dess egenskaper. Hitta step 2 och redigera den. Lägg till kommandovärdet med -QueryTimeout <timeout_in_seconds>. För frågetimeout-värdet, försök med 21600 eller ett högre värde. Starta jobbet igen slutligen.

Logglagringsstorleken har nått maxgränsen på 2 TB

När lagringsstorleken för transaktionsloggar når maxgränsen, vilket är 2 TB, kan loggen fysiskt inte växa mer än så. I det här fallet är den enda tillgängliga åtgärden att markera alla transaktioner som ska replikeras som bearbetade, så att transaktionsloggen kan kapas. Det innebär i praktiken att återstående transaktioner i loggen inte replikeras och att du måste initiera replikeringen igen.

Note

När du har utfört åtgärden måste du initiera replikeringen igen, vilket innebär att hela datauppsättningen replikeras igen. Det här är storleken på dataåtgärden och kan vara tidskrävande, beroende på mängden data som ska replikeras.

För att utföra riskminskningsåtgärden måste du först stoppa loggläsaragenten på distributören. Sedan bör du köra den sp_repldone lagrade proceduren med reset flaggan inställd 1 på på utgivardatabasen för att tillåta trunkering av transaktionsloggar. Det här kommandot bör se ut så här EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. Därefter måste du initiera replikeringen igen.

Nästa steg

Mer information om hur du konfigurerar transaktionsreplikering finns i följande självstudier: