Delen via

Transactionele replicatie met Azure SQL Managed Instance

  • Artikel

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.

Overzicht

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 exemplaardatabase in Azure SQL Managed Instance

Notitie

Als u alle functies van Azure SQL Managed Instance wilt gebruiken, moet u de nieuwste versies van SQL Server Management Studio (SSMS) en SQL Server Data Tools (SSDT) gebruiken.

Onderdelen

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

Diagram of replication with Azure SQL.

Rol Azure SQL Database Azure SQL Managed Instance
Uitgever Nee Ja
Distributeur Nee Ja
Pull-abonnee Nee Ja
Push-abonnee Ja Ja

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:

Notitie

Voor andere versies van SQL Server die geen ondersteuning bieden voor publiceren naar objecten in Azure, kunt u de gegevensmethode voor opnieuw publiceren gebruiken om gegevens te verplaatsen naar nieuwere versies van SQL Server.

Het configureren van replicatie met een oudere versie kan leiden tot een fout MSSQL_REPL20084 (het proces kan geen verbinding maken met Abonnee) en MSSQL_REPL40532 (Kan de servernaam <> die is aangevraagd door de aanmelding niet openen. De aanmelding is mislukt).

Typen replicatie

Er zijn verschillende typen replicatie:

Replicatie Azure SQL Database Azure SQL Managed Instance
Standard Transactional (Standaard transactioneel) Ja (alleen als abonnee) Yes
Momentopname Ja (alleen als abonnee) Yes
Replicatie samenvoegen Nee Nee
Peer-to-peer Nee Nee
Bidirectional (Bidirectioneel) Nee Ja
Bijwerkbare abonnementen Nee Nr.

Ondersteuningsmatrix

De ondersteuningsmatrix voor transactionele replicatie voor Azure SQL Managed Instance is hetzelfde als die voor SQL Server.

Uitgever Distributeur Abonnee
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

Wanneer 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

Categorie Gegevens synchroniseren Transactionele replicatie
Voordelen - Actief-actief ondersteuning
- Bidirectioneel tussen on-premises en Azure SQL Database		 - Lagere latentie
- Transactionele consistentie
- Bestaande topologie na migratie opnieuw gebruiken
Nadelen - Geen transactionele consistentie
- Hogere impact op prestaties		 - Kan niet publiceren vanuit Azure SQL Database
- Hoge onderhoudskosten

Algemene configuraties

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

Publisher met lokale distributeur in SQL Managed Instance

Single instance as Publisher and Distributor.

Publisher en distributeur worden geconfigureerd binnen één met SQL beheerd exemplaar en distribueren van wijzigingen naar een ander beheerd SQL-exemplaar, SQL Database of SQL Server-exemplaar.

Publisher met externe distributeur in SQL Managed Instance

In deze configuratie publiceert één met SQL beheerd exemplaar wijzigingen in een distributeur die is geplaatst op een ander beheerd SQL-exemplaar dat veel beheerde SQL-exemplaren kan leveren en wijzigingen kan distribueren naar een of meer doelen op Azure SQL Database, Azure SQL Managed Instance of SQL Server.

Separate instances for Publisher and Distributor.

Publisher en distributeur zijn geconfigureerd op twee beheerde exemplaren. 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

Azure SQL Database as subscriber.

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.

Vereisten

  • 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 uitgever/distributeur is en de abonnee niet. Mogelijk moet u ook de uitgaande beveiligingsregel voor de NSG van sql managed instance wijzigen voor allow_linkedserver_outbound de doelservicetag virtualnetwork van poort 1433 naar internet.
  • 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.

Notitie

Er kan fout 53 optreden wanneer u verbinding maakt met een Azure Storage-bestand als de uitgaande netwerkbeveiligingsgroep (NSG) poort 445 wordt geblokkeerd wanneer de distributeur een Azure SQL Managed Instance-database is en de abonnee zich on-premises bevindt. Werk de VNet-NSG bij om dit probleem op te lossen.

Beperkingen

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 worden gedaan via de Azure Storage-interface in 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 dat continu wordt uitgevoerd

Het aantal distributieagents dat is geconfigureerd om continu te worden uitgevoerd, is beperkt tot 30 op Azure SQL Managed Instance. Als u meer distributieagents wilt hebben, moeten ze op aanvraag of met een gedefinieerd schema worden uitgevoerd. Planning kan worden gedefinieerd met de dagelijkse frequentie en het optreden op elke 10 seconden (of meer), dus hoewel het niet continu is, kunt u nog steeds een distributeur hebben die latentie introduceert die slechts enkele seconden duurt. 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 wordt in de replicatiemonitor de status weergegeven Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replicatie wordt hervat zodra de failovergroep 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. Geforceerd een oude distributeur verwijderen uit het oorspronkelijke primaire SQL Managed Instance (als er een failover-overschakeling 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 door SQL beheerd exemplaar van een abonnee zich in een failovergroep bevindt, moet de publicatie worden geconfigureerd om verbinding te maken met het listenereindpunt van de failovergroep voor het beheerde exemplaar van de abonnee van SQL. 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.

Algemene problemen

Transactielogboek en transactionele replicatie

In normale omstandigheden wordt het transcatielogboek 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 status kan de database geen schrijfworkload meer verwerken en wordt de database effectief alleen-lezendatabase.

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 transcation-logboek. 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 logboeklezeragentquery's

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 agenttaak van de logboeklezer te verhogen.

Het verhogen van de time-out van query's voor de logboeklezertaak 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 het voor 21600 de time-outwaarde van de query of hoger. Ten slotte start u de taak opnieuw.

Maximale opslaglimiet voor logboekopslag bereikt van 2 TB

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 beperking het markeren van alle transacties die moeten worden gerepliceerd als verwerkt, zodat transactielogboek kan worden afgekapt. Dit betekent dat resterende transacties in het logboek niet worden gerepliceerd en dat u de replicatie opnieuw moet initialiseren.

Notitie

Nadat u een beperking hebt uitgevoerd, moet u de replicatie opnieuw initialiseren, wat betekent dat de hele gegevensset opnieuw wordt gerepliceerd. Dit is de grootte van de gegevensbewerking en kan lang duren, afhankelijk van de hoeveelheid gegevens die moet worden gerepliceerd.

Als u de beperking wilt uitvoeren, moet u eerst de logboeklezeragent op de distributeur stoppen. Vervolgens moet u de opgeslagen procedure uitvoeren met reset een sp_repldone vlag die is ingesteld 1 op de uitgeverdatabase, om afkapping van transactielogboeken toe te staan. 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:

Zie ook