Peer-to-Peer - Transactionele replicatie

Van toepassing op:SQL Server

Peer-to-peer-replicatie biedt een oplossing voor uitschalen en hoge beschikbaarheid door kopieën van gegevens over meerdere serverexemplaren te onderhouden, ook wel knooppunten genoemd. Peer-to-peer-replicatie is gebaseerd op de basis van transactionele replicatie en brengt transactioneel consistente wijzigingen in bijna realtime door. Hierdoor kunnen toepassingen die uitschalen van leesbewerkingen vereisen, de leesbewerkingen van clients over meerdere knooppunten distribueren. Omdat gegevens in bijna realtime worden onderhouden op de knooppunten, biedt peer-to-peer-replicatie gegevensredundantie, waardoor de beschikbaarheid van gegevens wordt verhoogd.

Overweeg een webtoepassing. Dit kan op de volgende manieren profiteren van peer-to-peer-replicatie:

• Catalogusquery's en andere leesbewerkingen worden verspreid over meerdere knooppunten. Hierdoor blijven de prestaties consistent naarmate leesbewerkingen toenemen.

• Als een van de knooppunten in het systeem mislukt, kan een toepassingslaag de schrijfbewerkingen voor dat knooppunt omleiden naar een ander knooppunt. Hierdoor blijft de beschikbaarheid behouden.

• Als een knooppunt onderhoud vereist of als voor het hele systeem een upgrade is vereist, kan elk knooppunt offline worden gehaald en weer aan het systeem worden toegevoegd zonder dat dit van invloed is op de beschikbaarheid van de toepassing.

Hoewel peer-to-peer-replicatie het uitschalen van leesbewerkingen mogelijk maakt, zijn schrijfprestaties voor de topologie vergelijkbaar met die voor één knooppunt. Dit komt doordat uiteindelijk alle invoegingen, updates en verwijderingen worden doorgegeven aan alle knooppunten. Replicatie herkent wanneer een wijziging is toegepast op een bepaald knooppunt en voorkomt dat wijzigingen meer dan één keer door de knooppunten worden gefietst. We raden u ten zeerste aan om schrijfbewerkingen voor elke rij uit te voeren op slechts één knooppunt, om de volgende redenen:

• Als een rij op meer dan één knooppunt wordt gewijzigd, kan dit een conflict veroorzaken of zelfs een verloren update veroorzaken wanneer de rij wordt doorgegeven aan andere knooppunten.

• Er is altijd enige latentie betrokken bij het repliceren van wijzigingen. Voor toepassingen waarvoor de meest recente wijziging onmiddellijk moet worden weergegeven, kan het dynamisch verdelen van de toepassing op meerdere knooppunten problematisch zijn.

Peer-to-peer-replicatie bevat de optie om conflictdetectie in te schakelen voor een peer-to-peer-topologie. Deze optie helpt voorkomen dat de problemen die worden veroorzaakt door niet-gedetecteerde conflicten, waaronder inconsistent toepassingsgedrag en verloren updates voorkomen. Als u deze optie inschakelt, wordt standaard een conflicterende wijziging behandeld als een kritieke fout die de fout van de distributieagent veroorzaakt. In het geval van een conflict blijft de topologie inconsistent totdat het conflict handmatig wordt opgelost en de gegevens consistent worden gemaakt in de topologie. Zie Conflictdetectie in Peer-to-Peer-replicatie voor meer informatie.

Peer-to-Peer-topologieën

De volgende scenario's illustreren typische toepassingen voor peer-to-peer-replicatie.

Topologie met twee deelnemende databases

In beide voorgaande illustraties ziet u twee deelnemende databases, waarbij gebruikersverkeer via een toepassingsserver naar de databases wordt geleid. Deze configuratie kan worden gebruikt voor een aantal toepassingen, van websites tot werkgroeptoepassingen en biedt de volgende voordelen:

• Verbeterde leesprestaties, omdat leesbewerkingen zijn verdeeld over twee servers.

• Hogere beschikbaarheid als onderhoud is vereist of mislukt op één knooppunt.

In beide illustraties is leesactiviteit taakverdeling tussen de deelnemende databases, maar updates worden anders verwerkt:

• Aan de linkerkant worden updates gepartitioneerd tussen de twee servers. Als de database een productcatalogus bevat, kunt u bijvoorbeeld een aangepaste toepassing direct bijwerken naar knooppunt A voor productnamen die beginnen met A tot en met M en directe updates naar knooppunt B voor productnamen die beginnen met N tot en met Z. Updates worden vervolgens gerepliceerd naar het andere knooppunt.

• Aan de rechterkant worden alle updates doorgestuurd naar knooppunt B. Van daaruit worden updates gerepliceerd naar knooppunt A. Als B offline is (bijvoorbeeld voor onderhoud), kan de toepassingsserver alle activiteiten naar A leiden. Wanneer B weer online is, kunnen er updates naartoe stromen en kan de toepassingsserver alle updates terug naar B verplaatsen of deze naar A sturen.

Peer-to-peer-replicatie kan beide benaderingen ondersteunen, maar het centrale updatevoorbeeld aan de rechterkant wordt ook vaak gebruikt met standaard transactionele replicatie.

Topologieën met drie of meer deelnemende databases

In de voorgaande afbeelding ziet u drie deelnemende databases die gegevens leveren voor een wereldwijde softwareondersteuningsorganisatie, met kantoren in Los Angeles, Londen en Taipei. De ondersteuningstechnici op elk kantoor nemen klantgesprekken en voeren informatie over elk klantgesprek in en werken deze bij. De tijdzones voor de drie kantoren liggen acht uur uit elkaar, dus er is geen overlap in de werkdag. Naarmate het kantoor van Taipei wordt gesloten, wordt het kantoor in Londen geopend voor de dag. Als er nog steeds een gesprek wordt uitgevoerd terwijl één kantoor wordt gesloten, wordt de oproep doorgeschakeld naar een vertegenwoordiger op het volgende kantoor om te openen.

Elke locatie heeft een database en een toepassingsserver, die door de ondersteuningstechnici worden gebruikt tijdens het invoeren en bijwerken van informatie over klantoproepen. De topologie wordt gepartitioneerd op tijd. Daarom vinden updates alleen plaats op het knooppunt dat momenteel voor bedrijven is geopend en worden de updates vervolgens naar de andere deelnemende databases doorgevoerd. Deze topologie biedt de volgende voordelen:

• Onafhankelijkheid zonder isolatie: elk kantoor kan gegevens afzonderlijk invoegen, bijwerken of verwijderen, maar kan de gegevens ook delen omdat deze worden gerepliceerd naar alle andere deelnemende databases.

• Hogere beschikbaarheid in geval van storing of onderhoud toestaan op een of meer van de deelnemende databases.

  

  In de voorgaande afbeelding ziet u de toevoeging van een knooppunt aan de topologie met drie knooppunten. Een knooppunt kan om de volgende redenen worden toegevoegd in dit scenario:

• Omdat er nog een kantoor geopend is.

• Om een hogere beschikbaarheid te bieden ter ondersteuning van onderhoud of het verhogen van fouttolerantie als er een schijffout optreedt of als er een andere grote fout optreedt.

U ziet dat in de topologieën met drie en vier knooppunten alle databases alle databases publiceren en abonneren op alle andere databases. Dit biedt maximale beschikbaarheid als er onderhoudsbehoeften of storingen zijn van een of meer knooppunten. Naarmate er knooppunten worden toegevoegd, moet u de beschikbaarheid en schaalbaarheid in balans houden met de prestaties en de complexiteit van de implementatie en het beheer.

Peer-to-peer-replicatie configureren

Het configureren van een peer-to-peer-replicatietopologie is vergelijkbaar met het configureren van een reeks standaard transactionele publicaties en abonnementen. In de stappen die in de volgende artikelen worden beschreven, ziet u de configuratie van een systeem met drie knooppunten, vergelijkbaar met de configuratie die links in de vorige afbeelding wordt weergegeven met peer-to-peertopologie.

TLS 1.3-versleuteling configureren

SQL Server 2025 (17.x) Preview introduceert TDS 8.0-ondersteuning voor peer-to-peer-replicatie, waaronder:

• Replicatieagents configureren voor gebruik van TLS 1.3-versleuteling tussen exemplaren van SQL Server 2025 (17.x) Preview en ook tussen SQL Server 2025 (17.x) Preview en Azure SQL Managed Instance.
• Standaardversleuteling voor communicatie tussen gekoppelde servers tussen exemplaren tussen SQL Server 2025 (17.x) Preview-exemplaren in een replicatietopologie. Gekoppelde servers in SQL Server 2025 (17.x) Preview gebruiken het OLE DB v19-stuurprogramma, dat standaard Encrypt=Mandatory wordt versleuteld.

Overwegingen voor het gebruik van peer-to-peer-replicatie

In deze sectie vindt u informatie en richtlijnen die u kunt overwegen wanneer u peer-to-peer-replicatie gebruikt.

Algemene overwegingen

• Peer-to-peer-replicatie is alleen beschikbaar in enterprise-editie van SQL Server.

• Alle databases die deelnemen aan peer-to-peer-replicatie, moeten identiek schema en gegevens bevatten:

  • Objectnamen, objectschema's en publicatienamen moeten identiek zijn.

  • Publicaties moeten toestaan dat schemawijzigingen worden gerepliceerd. (Dit is een instelling van 1 voor de publicatie-eigenschap replicate_ddl. Dit is de standaardinstelling.) Zie Schemawijzigingen aanbrengen in publicatiedatabases voor meer informatie.

  • Het filteren van rijen en kolommen wordt niet ondersteund.

• Elk knooppunt moet een eigen distributiedatabase gebruiken. Dit elimineert het potentieel van een single point of failure.

• Tabellen en andere objecten kunnen niet worden opgenomen in meerdere peer-to-peerpublicaties in één publicatiedatabase.

• Een publicatie moet zijn ingeschakeld voor peer-to-peer-replicatie voordat er abonnementen worden gemaakt.

• Abonnementen moeten worden geïnitialiseerd met behulp van een back-up of met de replication support only optie. Zie Een transactioneel abonnement initialiseren zonder momentopname voor meer informatie.

• Gebruik geen identiteitskolommen. Wanneer u identiteiten gebruikt, moet u de bereiken die aan de tabellen zijn toegewezen, handmatig beheren in elke deelnemende database. Zie Bereiken toewijzen voor handmatig identiteitsbereikbeheer voor meer informatie.

Functiebeperkingen

Peer-to-peer-replicatie ondersteunt de kernfuncties van transactionele replicatie, maar biedt geen ondersteuning voor de volgende opties:

• Initialisatie en herinitialisatie met een momentopname.

• Rij- en kolomfilters.

• Tijdstempelkolommen.

• Niet-SQL Server-uitgevers en -abonnees.

• Abonnementen direct bijwerken en in de wachtrij plaatsen.

• Anonieme abonnementen.

• Gedeeltelijke abonnementen.

• Koppelbare abonnementen en transformeerbare abonnementen. (Beide opties zijn afgeschaft in SQL Server 2005 (9.x).)

• Gedeelde distributieagents.

• De parameter Distribution Agent -SubscriptionStreams en de parameter Log Reader Agent -MaxCmdsInTran.

• De eigenschappen @destination_owner van het artikel en @destination_table.

• Transactionele replicatie van peer-to-peer biedt geen ondersteuning voor het maken van een transactioneel abonnement in één richting naar een peer-to-peer-publicatie

• Transactionele replicatie van peer-to-peer biedt geen ondersteuning voor het publiceren van tabellen met berekende kolommen als onderdeel van hun primaire sleutel.

De volgende eigenschappen hebben speciale overwegingen:

• Voor de publicatie-eigenschap @allow_initialize_from_backup is een waarde van true vereist.

• Voor de eigenschap @replicate_ddl van het artikel is een waarde waar vereist. @identityrangemanagementoption Hiervoor is een handmatige waarde vereist. @status Hiervoor is optie 24 ingesteld.

• De waarde voor artikeleigenschappen @ins_cmden @del_cmd@upd_cmd kan niet worden ingesteld op SQL.

• Voor de abonnementseigenschap @sync_type is een waarde van geen of automatisch vereist.

• SQL Server 2019 (15.x) CU 13 introduceert de publicatie-eigenschap. @p2p_confictdetection_policy De standaardparameterwaarde is originatorid en lost het conflict op basis van de originator-id op. De lastwriter parameterwaarde lost het conflict op basis van de laatste schrijver op.

Onderhoudsoverwegingen

Voor sommige acties moet het systeem stil zijn. Dit betekent dat de activiteit op alle gepubliceerde tabellen op alle knooppunten wordt gestopt en ervoor zorgt dat elk knooppunt alle wijzigingen van alle andere knooppunten heeft ontvangen.

Voor wijzigingen in het topologieschema (een artikel toevoegen of verwijderen) moet u stilvallen. Zie Een peer-to-peertopologie beheren (replicatie Transact-SQL programmeren) voor meer informatie.

Voor het verwijderen van een knooppunt uit de topologie is geen stilgeving vereist.

Als u de eigenschappen van het artikel wijzigt met behulp van sp_changearticle hoeft u nooit stil te zetten. Toegestane wijzigingen (voor P2P) zijn de descriptioneigenschappen , ins_cmden upd_cmddel_cmd eigenschappen.

Wijzigingen in artikelschema's (kolom toevoegen/verwijderen) vereisen nooit quiescing.

• Artikel toevoegen: Als u een artikel wilt toevoegen aan een bestaande configuratie, moet u het systeem stilmaken door de instructie CREATE TABLE uit te voeren en de initiële gegevens op elk knooppunt in de topologie te laden en het nieuwe artikel toe te voegen aan elk knooppunt in de topologie.

• Artikel verwijderen: Als we een consistente status op alle knooppunten willen, moeten we de topologie stilzetten

Zie Een replicatietopologie (replicatie Transact-SQL programmeren) en beheer een peer-to-peer-topologie (replicatie Transact-SQL programmeren) voor meer informatie.

• Als u een nieuw knooppunt toevoegt aan een peer-to-peer-topologie, moet u alleen herstellen vanuit back-ups die zijn gemaakt nadat het nieuwe knooppunt is toegevoegd.

• U kunt abonnementen niet opnieuw initialiseren in een peer-to-peer-topologie. Als u ervoor moet zorgen dat een knooppunt een nieuwe kopie van de gegevens heeft, herstelt u een back-up op het knooppunt.

Verwante inhoud

• Een peer-to-peertopologie beheren (replicatie Transact-SQL programmeren)
• Strategieën voor het maken van back-ups en het herstellen van momentopnamen en transactionele replicatie
• Transactionele replicatie