Transaktionsreplikering med Azure SQL Managed Instance

  • Artikel

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.

Översikt

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 instansdatabas i Azure SQL Managed Instance

Kommentar

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

Komponenter

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

Diagram of replication with Azure SQL.

Roll Azure SQL Database Hanterad Azure SQL-instans
Utgivare Inga Ja
Distributör Inga Ja
Pull-prenumerant Inga Ja
Push-prenumerant Ja Ja

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 tar emot ändringar som gjorts på 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:

Kommentar

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:

Replikering Azure SQL Database Hanterad Azure SQL-instans
Vanlig transaktionsreplikering Ja (endast som prenumerant) Ja
Ögonblicksbild Ja (endast som prenumerant) Ja
Sammanslagen replikering Inga Inga
Peer-to-peer Inga Inga
Dubbelriktad Inga Ja
Uppdateringsbara prenumerationer Inga Nej

Supportmatris

Stödmatrisen för transaktionsreplikering för Azure SQL Managed Instance är samma som för SQL Server.

Utgivare Distributör Abonnent
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Användningsområde för

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

Kategori Datasynkronisering Transaktionsreplikering
Fördelar – Aktivt stöd
– Dubbelriktad mellan lokal databas och Azure SQL Database		 - Kortare svarstid
– Transaktionskonsekvens
– Återanvänd befintlig topologi efter migrering
Nackdelar – 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

Single instance as Publisher and Distributor.

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.

Separate instances for Publisher and 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 as subscriber.

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.

Behov

  • Använd SQL-autentisering för anslutning mellan replikeringsdeltagare.
  • Använd en Azure Storage-kontoresurs för arbetskatalogen som används av 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 den utgående säkerhetsregeln för sql-hanterad instans NSG för allow_linkedserver_outbound port 1433-måltjänsten från virtualnetwork till internet.
  • 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.

Kommentar

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.

Begränsningar

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 distributionsagenter som körs 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.

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. <name of publication> Ersätt värdena 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 sql-prenumerationshanterad instans finns i en redundansgrupp ska publikationen konfigureras för att ansluta till lyssnarslutpunkten för redundansgruppen för den sql-hanterade prenumerantens instans. I händelse av en redundansväxling beror efterföljande åtgärder av SQL-administratören för den hanterade instansen på vilken typ av redundans 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 replikering också. 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ök vanliga problem

Transaktionslogg och transaktionsreplikering

I vanliga fall används tillfälliga loggar 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 transaktionsloggar tills ändringar i loggen bearbetas av loggläsarjobbet. 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 skrivarbetsbelastningar och blir i praktiken skrivskyddad databas.

Inaktiverad loggläsaragent

Ibland konfigureras transaktionsreplikeringspublikation för en databas, men loggläsaragenten är inte konfigurerad 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 transcation-loggen. 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äsarjobb inte göra några effektiva framsteg på grund av upprepade tidsgränser för frågor. Ett sätt att åtgärda tidsgränser för frågor är att öka tidsgränsinställningen för frågan 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örsök med eller högre för frågetimeout-värdet 21600 . Starta slutligen jobbet igen.

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 trunkeras. Det innebär i praktiken att återstående transaktioner i loggen inte replikeras och att du måste initiera replikeringen igen.

Kommentar

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 å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:

Se även