Transactionele replicatie met Azure SQL Managed Instance

Van toepassing op:Azure SQL Managed Instance

Transactionele replicatie is een functie van Azure SQL Managed Instance en SQL Server waarmee u gegevens uit een tabel in Azure SQL Managed Instance of een SQL Server-exemplaar kunt repliceren naar tabellen die zijn geplaatst op externe databases. Met deze functie kunt u meerdere tabellen in verschillende databases synchroniseren.

Overview

U kunt transactionele replicatie gebruiken om wijzigingen die zijn aangebracht in een met Azure SQL beheerd exemplaar te pushen naar:

• Een SQL Server-database (on-premises of op een virtuele Azure-machine)
• Een database in Azure SQL Database
• Een database in Azure SQL Managed Instance

Components

De belangrijkste onderdelen in transactionele replicatie zijn de uitgever, distributeur en abonnee, zoals wordt weergegeven in de volgende afbeelding:

De uitgever publiceert wijzigingen die zijn aangebracht in sommige tabellen (artikelen) door de updates naar de distributeur te verzenden. De uitgever kan een met Azure SQL beheerd exemplaar of een SQL Server-exemplaar zijn.

De distributeur verzamelt wijzigingen in de artikelen van een uitgever en distribueert deze naar de abonnees. De distributeur kan een beheerd Exemplaar van Azure SQL of een SQL Server-exemplaar zijn (elke versie zolang deze gelijk is aan of hoger is dan de Publisher-versie).

De abonnee ontvangt wijzigingen die zijn aangebracht in publisher. Een SQL Server-exemplaar en een met Azure SQL beheerd exemplaar kunnen zowel push- als pull-abonnees zijn, maar een pull-abonnement wordt niet ondersteund wanneer de distributeur een door Azure SQL beheerd exemplaar is en de abonnee niet. Een database in Azure SQL Database kan alleen een pushabonnee zijn.

Azure SQL Managed Instance kan ondersteuning bieden voor abonnee zijn vanuit de volgende versies van SQL Server:

• SQL Server 2016 en latere versies
• SQL Server 2014 RTM CU10 (12.0.4427.24) of SP1 CU3 (12.0.2556.4)
• SQL Server 2012 SP2 CU8 (11.0.5634.1) of SP3 (11.0.6020.0) of SP4 (11.0.7001.0)

Typen replicatie

Er zijn verschillende soorten van replicatie:

Ondersteuningsmatrix

De ondersteuningsmatrix voor transactionele en momentopnamereplicatie voor Azure SQL Managed Instance is hetzelfde als voor SQL Server:

^AUTD- Geldt voor Azure SQL Managed Instance die is geconfigureerd met het Always-up-to-date updatebeleid.
²⁰²⁵ Is van toepassing op Azure SQL Managed Instance dat is geconfigureerd met het updatebeleid voor SQL Server 2025.
²⁰²² Is van toepassing op Azure SQL Managed Instance dat is geconfigureerd met het updatebeleid voor SQL Server 2022.
¹ Is van toepassing op basis van de vereisten van de ondersteunde configuraties voor SQL-database in Microsoft Fabric.

Wanneer te gebruiken

Transactionele replicatie is handig in de volgende scenario's:

• Publiceer wijzigingen die zijn aangebracht in een of meer tabellen in een database en distribueer ze naar een of meer databases in een SQL Server-exemplaar of Azure SQL Database die zijn geabonneerd op de wijzigingen.
• Houd verschillende gedistribueerde databases gesynchroniseerd.
• Migreer databases van één SQL Server-exemplaar of Azure SQL Managed Instance naar een andere database door de wijzigingen continu te publiceren.

Data Sync vergelijken met transactionele replicatie

Algemene configuraties

Over het algemeen moeten de uitgever en de distributeur zich in de cloud of on-premises bevinden. De volgende configuraties worden ondersteund:

Uitgever met lokale distributeur op SQL Managed Instance

Publisher en distributeur worden geconfigureerd binnen één SQL-beheerd exemplaar en distribueren wijzigingen naar een ander beheerd SQL-exemplaar, een SQL-database of een SQL-serverexemplaar.

Uitgever met externe distributietool in SQL Managed Instance

In deze configuratie publiceert een met SQL beheerd exemplaar wijzigingen naar een distributeur die zich op een ander beheerd SQL-exemplaar bevindt en die veel bron-SQL-beheerde exemplaren kan bedienen en wijzigingen kan distribueren naar een of meerdere doelen op Azure SQL Database, Azure SQL Managed Instance of SQL Server.

Publisher en distributeur zijn geconfigureerd op twee beheerde instances. Er zijn enkele beperkingen met deze configuratie:

• Beide beheerde exemplaren bevinden zich in hetzelfde vNet.
• Beide beheerde exemplaren bevinden zich op dezelfde locatie.

On-premises uitgever/distributeur met externe abonnee

In deze configuratie is een database in Azure SQL Database of Azure SQL Managed Instance een abonnee. Deze configuratie ondersteunt migratie van on-premises naar Azure. Als een abonnee een database in Azure SQL Database is, moet deze zich in de pushmodus bevinden.

Requirements

• GEBRUIK SQL-verificatie voor connectiviteit tussen replicatiedeelnemers.
• Gebruik een Azure Storage-accountshare voor de werkmap die wordt gebruikt door replicatie.
• Open TCP-uitgaande poort 445 in de beveiligingsregels van het subnet voor toegang tot de Azure-bestandsshare.
• Open TCP-uitgaande poort 1433 wanneer het beheerde SQL-exemplaar de Publisher/Distributor is en de abonnee dat niet is. Mogelijk moet u ook de NSG-uitgaande beveiligingsregel voor de SQL Managed Instance wijzigen voor de doelservicetag van poort 1433 van allow_linkedserver_outbound naar .
• Plaats zowel de uitgever als de distributeur in de cloud, of beide on-premises.
• Configureer VPN-peering tussen de virtuele netwerken van replicatiedeelnemers als de virtuele netwerken verschillen.

Security

Ondersteuning voor TLS 1.3

Azure SQL Managed Instance ondersteunt TLS 1.3 voor replicatieverbindingen die zijn geïnitialiseerd door agents die zijn geconfigureerd voor uitvoering op een met SQL beheerd exemplaar. Dit is van toepassing op een replicatietopologie tussen twee met SQL beheerde exemplaren en ook op elke versie van SQL Server als abonnee van een uitgever en distributeur van een beheerd SQL-exemplaar.

Als u TLS 1.3 gebruikt om de verbindingen tussen exemplaren in een replicatietopologie te beveiligen, geeft u een waarde van 3 of 4 op voor de parameter -EncryptionLevel van elke replicatieagent:

• Distributieagent
• Agent voor logboeklezer
• Snapshot Agent

Een waarde van 3 dwingt TLS 1.3-verbindingen met beheerde SQL-instanties af, maar heeft geen invloed op verbindingen met SQL-servers. Een waarde van 4 dwingt TLS 1.3-verbindingen af tussen SQL-beheerde exemplaren, evenals verbindingen van SQL-beheerd exemplaar naar SQL Server, en vereist dat u het certificaat op de SQL Server-host installeert.

Inloggen replAgentUser

Voor transactionele replicatie heeft een beheerd SQL-exemplaar een vooraf gemaakte aanmelding(en) met de naam replAgentUser. Deze aanmelding is lid van de sysadmin serverfunctie en wordt gebruikt door replicatieagents die verbinding moeten maken met een door SQL beheerd exemplaar dat deelneemt aan de transactionele replicatie-installatie.

Als transactionele replicatie niet wordt gebruikt, kan de aanmelding replAgentUser worden uitgeschakeld. Deze kan later opnieuw worden ingeschakeld als u besluit om transactionele replicatie te gaan gebruiken.

Limitations

Transactionele replicatie heeft enkele beperkingen die specifiek zijn voor Azure SQL Managed Instance. Meer informatie over deze beperkingen vindt u in deze sectie.

Momentopnamebestanden worden niet verwijderd uit een Azure Storage-account

Azure SQL Managed Instance maakt gebruik van een door de gebruiker geconfigureerd Azure Storage-account voor momentopnamebestanden die worden gebruikt voor transactionele replicatie. In tegenstelling tot SQL Server in de on-premises omgeving, verwijdert Azure SQL Managed Instance geen momentopnamebestanden uit een Azure Storage-account. Zodra bestanden niet meer nodig zijn, moet u ze verwijderen. Dit kan gedaan worden via de interface van Azure Storage in de Azure Portal, Microsoft Azure Storage Explorer, of via opdrachtregelclients (Azure PowerShell of CLI) of Azure Storage Management REST API.

Hier volgt een voorbeeld van hoe u een bestand kunt verwijderen en hoe u een lege map kunt verwijderen.

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>

Aantal distributieagenten die continu draaien

Het aantal distributieagents dat is geconfigureerd om continu te worden uitgevoerd, is beperkt tot 30 op Azure SQL Managed Instance. Om meer distributieagenten te hebben, moeten zij op aanvraag of volgens een vastgesteld schema worden uitgevoerd. De planning kan worden ingesteld met een dagelijkse frequentie en een interval van elke 10 seconden (of meer), dus hoewel het niet continu is, kunt u nog steeds een distributeur hebben die latentie introduceert die maar enkele seconden oploopt. Wanneer een groot aantal distributeurs nodig is, is het raadzaam om geplande en niet continue configuratie te gebruiken.

Met failovergroepen

Het gebruik van transactionele replicatie met exemplaren in een failovergroep wordt ondersteund. Als u echter replicatie configureert voordat u uw met SQL beheerde exemplaar toevoegt aan een failovergroep, wordt de replicatie onderbroken wanneer u begint met het maken van uw failovergroep en de replicatiemonitor geeft een status van Replicated transactions are waiting for the next log backup or for mirroring partner to catch upweer. Replicatie wordt hervat zodra de failovergroep succesvol is gemaakt.

Als een uitgever of distributeur van sql managed instance zich in een failovergroep bevindt, moet de beheerder van het beheerde SQL-exemplaar alle publicaties op de oude primaire server opschonen en deze opnieuw configureren op de nieuwe primaire server nadat er een failover is opgetreden. In dit scenario zijn de volgende activiteiten nodig:

1. Stop alle replicatietaken die worden uitgevoerd op de database, indien aanwezig.

2. Verwijder de metagegevens van het abonnement van publisher door het volgende script uit te voeren op de uitgeverdatabase. Vervang de <name of publication> en <name of subscriber> waarden:

   EXEC sp_dropsubscription @publication = '<name of publication>',
       @article = 'all',
       @subscriber = '<name of subscriber>'
   

3. Verwijder de metagegevens van het abonnement van de abonnee. Voer het volgende script uit op de abonnementsdatabase op het beheerde SQL-exemplaar van de abonnee. Vervang de <full DNS of publisher> waarde. Bijvoorbeeld 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. Verwijder geforceerd alle replicatieobjecten van publisher door het volgende script uit te voeren in de gepubliceerde database:

   EXEC sp_removedbreplication;
   

5. Gedwongen een oude distributeur verwijderen uit de oorspronkelijke primaire SQL Managed Instance (als er een failover wordt uitgevoerd naar een oude primaire instantie die voorheen een distributeur had). Voer het volgende script uit op de master database in het oude beheerde SQL-exemplaar van de distributeur:

   EXEC sp_dropdistributor 1, 1;
   

Als een SQL-beheerd exemplaar van een abonnee zich in een failovergroep bevindt, moet de publicatie worden geconfigureerd om verbinding te maken met het luisteraar-eindpunt van de failovergroep voor het SQL-beheerde exemplaar van de abonnee. In het geval van een failover is de volgende actie van de beheerder van het beheerde SQL-exemplaar afhankelijk van het type failover dat is opgetreden:

• Voor een failover zonder gegevensverlies blijft de replicatie na een failover werken.
• Voor een failover met gegevensverlies werkt replicatie ook. De verloren wijzigingen worden opnieuw gerepliceerd.
• Voor een failover met gegevensverlies, maar het gegevensverlies valt buiten de bewaarperiode van de distributiedatabase, moet de beheerder van het beheerde SQL-exemplaar de abonnementsdatabase opnieuw initialiseren.

Veelvoorkomende problemen oplossen

Transactielogboek en transactionele replicatie

In normale omstandigheden wordt transactielogboek gebruikt voor het vastleggen van wijzigingen van de gegevens in een database. Wijzigingen worden vastgelegd in het transactielogboek, waardoor het opslagverbruik van logboeken toeneemt. Er is ook een automatisch proces waarmee het transactielogboek veilig kan worden afgekapt. Dit proces vermindert de gebruikte opslagruimte voor het logboek. Wanneer publiceren voor transactionele replicatie is geconfigureerd, wordt afkapping van transactielogboeken voorkomen totdat wijzigingen in het logboek worden verwerkt door de logboeklezertaak. In sommige gevallen wordt de verwerking van het transactielogboek effectief geblokkeerd en kan deze status leiden tot het invullen van de volledige opslag die is gereserveerd voor transactielogboeken. Als er geen vrije ruimte is voor transactielogboek en er geen ruimte meer is om het transactielogboek te laten groeien, hebben we een volledig transactielogboek. In deze toestand kan de database geen schrijfbewerkingen meer verwerken en wordt de database feitelijk een alleen-lezen database.

Agent voor logboeklezer uitgeschakeld

Soms is transactionele replicatiepublicatie geconfigureerd voor een database, maar de logboeklezeragent is niet geconfigureerd voor uitvoering. In dat geval worden wijzigingen in het transactielogboek opgestapeld en worden ze niet verwerkt. Dit leidt tot een constante groei van het transactionele logboek en uiteindelijk tot het volledige transactielogboek. De gebruiker moet ervoor zorgen dat de logboeklezertaak bestaat en actief is. U kunt ook transactionele replicatie uitschakelen als dit niet nodig is.

Time-outs van logboeklezer agent queries

Soms kan de logboeklezertaak geen effectieve voortgang boeken vanwege herhaalde time-outs voor query's. Een manier om time-outs voor query's op te lossen, is door de time-outinstelling voor query's voor de logboeklezer-agenttaak te verhogen.

Het verhogen van de query-time-out voor de log reader job kan worden uitgevoerd met SSMS. Zoek in de objectverkenner onder SQL Server Agent de taak die u wilt wijzigen. Stop het eerst en open vervolgens de eigenschappen. Zoek step 2 en bewerk het. Voeg de opdrachtwaarde toe met -QueryTimeout <timeout_in_seconds>. Probeer een time-outwaarde van 21600 of hoger voor de query. Ten slotte start u de taak opnieuw.

De logboekopslag heeft de maximale limiet van 2 TB bereikt.

Wanneer de opslaglimiet voor transactielogboeken is bereikt, wat 2 TB is, kan het logboek fysiek niet meer groeien. In dit geval is de enige beschikbare mitigatie het markeren van alle transacties die moeten worden gerepliceerd als verwerkt, zodat het transactielogboek kan worden verkleind. Dit betekent dat resterende transacties in het logboek niet worden gerepliceerd en dat u de replicatie opnieuw moet initialiseren.

Om de mitigatie uit te voeren, moet u eerst de loglezersagent op de distributeur stoppen. Vervolgens moet u de opgeslagen procedure uitvoeren op de uitgeverdatabase, met de vlag sp_repldone ingesteld op reset, om het afkappen van het transactielogboek mogelijk te maken. Deze opdracht moet er als volgt EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1uitzien. Hierna moet u de replicatie opnieuw initialiseren.

Volgende stappen

Zie de volgende zelfstudies voor meer informatie over het configureren van transactionele replicatie:

• Configureer replicatie tussen een uitgever en abonnee van sql Managed Instance.
• Configureer replicatie tussen een uitgever van SQL Managed Instance, de distributeur van SQL Managed Instance en een SQL Server-abonnee.
• Een publicatie maken.
• Maak een push-abonnement met behulp van de servernaam als abonnee (bijvoorbeeld N'azuresqldbdns.database.windows.net) en de database in Azure SQL Database-naam als doeldatabase (bijvoorbeeld Adventureworks).

Verwante inhoud

• Replicatie met een sql Managed Instance en een failovergroep
• Replicatie naar SQL Database
• Replicatie naar beheerd exemplaar
• een publicatie maken
• een pushabonnement maken
• Typen van replicatie
• Monitoring (Replicatie)
• een abonnement initialiseren