Peer-to-Peer – transaktionsreplikering

Gäller för:SQL Server

Peer-to-peer-replikering ger en skalbar och hög tillgänglighetslösning genom att underhålla kopior av data över flera serverinstanser, även kallade noder. Peer-to-peer-replikering bygger på grunden för transaktionsreplikering och sprider transaktionskonsekventa ändringar nästan i realtid. På så sätt kan program som kräver utskalning av läsåtgärder distribuera läsningarna från klienter över flera noder. Eftersom data underhålls över noderna nästan i realtid ger peer-to-peer-replikering dataredundans, vilket ökar tillgängligheten för data.

Överväg ett webbprogram. Detta kan dra nytta av peer-to-peer-replikering på följande sätt:

• Katalogfrågor och andra läsningar sprids över flera noder. Detta gör att prestanda kan förbli konsekventa när läsningarna ökar.

• Om en av noderna i systemet misslyckas kan ett programlager omdirigera skrivningarna för noden till en annan nod. Detta upprätthåller tillgängligheten.

• Om en nod kräver underhåll eller om hela systemet kräver en uppgradering kan varje nod tas offline och läggas tillbaka till systemet utan att programmets tillgänglighet påverkas.

Även om peer-to-peer-replikering möjliggör utskalning av läsåtgärder, är skrivprestanda för topologin så för en enskild nod. Det beror på att i slutändan sprids alla infogningar, uppdateringar och borttagningar till alla noder. Replikering identifierar när en ändring har tillämpats på en viss nod och förhindrar ändringar från att cykla genom noderna mer än en gång. Vi rekommenderar starkt att skrivåtgärder för varje rad endast utförs på en nod av följande skäl:

• Om en rad ändras på mer än en nod kan det orsaka en konflikt eller till och med en förlorad uppdatering när raden sprids till andra noder.

• Det finns alltid en viss fördröjning när ändringar replikeras. För program som kräver att den senaste ändringen visas omedelbart kan det vara problematiskt att dynamiskt belastningsutjämning av programmet över flera noder.

Peer-to-peer-replikering innehåller alternativet för att aktivera konfliktidentifiering i en peer-to-peer-topologi. Det här alternativet hjälper till att förhindra problem som orsakas av oupptäckta konflikter, inklusive inkonsekvent programbeteende och förlorade uppdateringar. Genom att aktivera det här alternativet behandlas som standard en ändring i konflikt som ett kritiskt fel som orsakar distributionsagentens fel. I händelse av en konflikt förblir topologin i ett inkonsekvent tillstånd tills konflikten löses manuellt och data görs konsekventa i topologin. Mer information finns i Konfliktidentifiering i Peer-to-Peer-replikering.

Peer-to-Peer-topologier

Följande scenarier illustrerar typiska användningsområden för peer-to-peer-replikering.

Topologi som har två deltagande databaser

Båda föregående illustrationer visar två deltagande databaser, där användartrafik dirigeras till databaserna via en programserver. Den här konfigurationen kan användas för ett antal program, från webbplatser till arbetsgruppsprogram, och ger följande fördelar:

• Förbättrad läsprestanda eftersom läsningar är utspridda över två servrar.

• Högre tillgänglighet om underhåll krävs eller om det uppstår fel på en nod.

I båda illustrationerna lastbalanseras läsaktiviteten mellan de deltagande databaserna, men uppdateringar hanteras på olika sätt:

• Till vänster partitioneras uppdateringar mellan de två servrarna. Om databasen innehåller en produktkatalog kan du till exempel ha en anpassad programdirigeringsuppdatering till noden A för produktnamn som börjar med A till M och direktuppdateringar till noden B för produktnamn som börjar med N till och med Z. Uppdateringar replikeras sedan till den andra noden.

• Till höger dirigeras alla uppdateringar till noden B. Därifrån replikeras uppdateringar till nod A. Om B är offline (till exempel för underhåll) kan programservern dirigera all aktivitet till A. När B är online igen kan uppdateringar flöda till den och programservern kan flytta alla uppdateringar tillbaka till B eller fortsätta dirigera dem till A.

Peer-to-peer-replikering kan stödja båda metoder, men det centrala uppdateringsexemplet till höger används också ofta med standardtransaktionsreplikering.

Topologier som har tre eller fler deltagande databaser

Föregående bild visar tre deltagande databaser som tillhandahåller data för en världsomspännande programvarusupportorganisation, med kontor i Los Angeles, London och Taipei. Supporttekniker på varje kontor tar emot kundsamtal och anger och uppdaterar information om varje kundsamtal. Tidszonerna för de tre kontoren är åtta timmars mellanrum, så det finns ingen överlappning i arbetsdagen. När Taipei-kontoret stänger öppnar Londonkontoret för dagen. Om ett samtal fortfarande pågår när ett kontor stängs överförs samtalet till en representant på nästa kontor för att öppna.

Varje plats har en databas och en programserver som används av supporttekniker när de anger och uppdaterar information om kundsamtal. Topologin partitioneras efter tid. Därför sker uppdateringar endast på den nod som för närvarande är öppen för företag, och sedan flödar uppdateringarna till de andra deltagande databaserna. Den här topologin ger följande fördelar:

• Oberoende utan isolering: Varje kontor kan infoga, uppdatera eller ta bort data oberoende av varandra, men de kan också dela data eftersom de replikeras till alla andra deltagande databaser.

• Högre tillgänglighet vid fel eller för att tillåta underhåll i en eller flera av de deltagande databaserna.

  

  Föregående bild visar tillägget av en nod i topologin med tre noder. En nod kan läggas till i det här scenariot av följande skäl:

• Eftersom ett annat kontor öppnas.

• För att ge högre tillgänglighet för underhåll eller öka feltoleransen om ett diskfel eller något annat större fel inträffar.

Observera att i topologierna med både tre och fyra noder publicerar och prenumererar alla databaser på alla andra databaser. Detta ger maximal tillgänglighet om det finns underhållsbehov eller fel på en eller flera noder. När noder läggs till måste du balansera tillgänglighets- och skalbarhetsbehov mot prestanda och komplexiteten i distribution och administration.

Konfigurera peer-to-peer-replikering

Att konfigurera en peer-to-peer-replikeringstopologi liknar att konfigurera en serie vanliga transaktionspublikationer och prenumerationer. Stegen som beskrivs i följande artiklar visar konfigurationen av ett system med tre noder, ungefär som den konfiguration som visas till vänster i föregående bild som visar peer-to-peer-topologi.

Konfigurera TLS 1.3-kryptering

Förhandsversionen av SQL Server 2025 (17.x) introducerar TDS 8.0-stöd för peer-to-peer-replikering, vilket omfattar:

• Konfigurera replikeringsagenter att använda TLS 1.3-kryptering mellan instanser av SQL Server 2025 (17.x) Preview och även mellan SQL Server 2025 (17.x) Preview och Azure SQL Managed Instance.
• Standardkryptering för länkad serverkommunikation mellan instanser mellan SQL Server 2025 (17.x) Förhandsversionsinstanser i en replikeringstopologi. Länkade servrar i SQL Server 2025 (17.x) Preview använder OLE DB v19-drivrutinen, som standard är Encrypt=Mandatory kryptering.

Överväganden för att använda peer-to-peer-replikering

Det här avsnittet innehåller information och riktlinjer att tänka på när du använder peer-to-peer-replikering.

Allmänna överväganden

• Peer-to-peer-replikering är endast tillgängligt i företagsutgåvan av SQL Server.

• Alla databaser som deltar i peer-to-peer-replikering bör innehålla identiska scheman och data:

  • Objektnamn, objektschema och publikationsnamn ska vara identiska.

  • Publikationer måste tillåta att schemaändringar replikeras. (Det här är inställningen 1 för publikationsegenskapen replicate_ddl, vilket är standardinställningen.) Mer information finns i Göra schemaändringar i publikationsdatabaser.

  • Rad- och kolumnfiltrering stöds inte.

• Varje nod bör använda sin egen distributionsdatabas. Detta eliminerar risken för att ha en enda felpunkt.

• Tabeller och andra objekt kan inte ingå i flera peer-to-peer-publikationer i en enda publikationsdatabas.

• En publikation måste vara aktiverad för peer-to-peer-replikering innan några prenumerationer skapas.

• Prenumerationer måste initieras med hjälp av en säkerhetskopia eller med alternativet replication support only . Mer information finns i Initiera en transaktionsprenumeration utan en ögonblicksbild.

• Använd inte identitetskolumner. När du använder identiteter måste du manuellt hantera de intervall som tilldelats tabellerna i varje deltagande databas. Mer information finns i Tilldela intervall för manuell hantering av identitetsintervall.

Funktionsbegränsningar

Peer-to-peer-replikering stöder kärnfunktionerna i transaktionsreplikering, men stöder inte följande alternativ:

• Initiering och återinitiering med en ögonblicksbild.

• Rad- och kolumnfilter.

• Tidsstämpelkolumner.

• Icke-SQL Server-utgivare och prenumeranter.

• Omedelbar uppdatering och köad uppdatering av prenumerationer.

• Anonyma prenumerationer.

• Partiella prenumerationer.

• Kopplingsbara prenumerationer och transformerbara prenumerationer. (Båda dessa alternativ var inaktuella i SQL Server 2005 (9.x).)

• Delade distributionsagenter.

• Distributionsagentparametern -SubscriptionStreams och log reader agent-parametern -MaxCmdsInTran.

• Artikelns egenskaper @destination_owner och @destination_table.

• Peer-to-Peer-transaktionsreplikering stöder inte att skapa en enkelriktad transaktionsprenumeration till en Peer-to-Peer-publikation

• Peer-to-Peer-transaktionsreplikering stöder inte publiceringstabeller med beräknade kolumner som en del av deras primära nyckel.

Följande egenskaper har särskilda överväganden:

• Publikationsegenskapen @allow_initialize_from_backup kräver värdet true.

• Artikelegenskapen @replicate_ddl kräver värdet true, @identityrangemanagementoption kräver värdet manuell och @status kräver att alternativ 24 anges.

• Värdet för artikelegenskaperna @ins_cmd, @del_cmdoch @upd_cmd kan inte anges till SQL.

• Prenumerationsegenskapen @sync_type kräver värdet ingen eller automatisk.

• SQL Server 2019 (15.x) CU 13 introducerar publikationsegenskapen . @p2p_confictdetection_policy Standardparametervärdet är originatorid och det löser konflikten baserat på ursprungs-ID. Parametervärdet lastwriter löser konflikten på grundval av den senaste skrivaren.

Underhållsöverväganden

Vissa åtgärder kräver att systemet är quiescent. Det innebär att aktivitet stoppas i publicerade tabeller på alla noder och att varje nod har tagit emot alla ändringar från alla andra noder.

Topologischemaändringar (lägga till eller ta bort en artikel) kräver quiescing. Mer information finns i Administrera en peer-to-peer-topologi (replikering Transact-SQL programmering).

Att ta bort en nod från topologin kräver aldrig quiescing.

Att ändra artikelegenskaperna med hjälp av sp_changearticle kräver aldrig quiescing. Tillåtna ändringar (för P2P) är descriptionegenskaperna , ins_cmd, upd_cmdoch del_cmd .

Ändringar i artikelschema (lägga till/släppa kolumn) kräver aldrig quiescing.

• Lägger till artikel: Om du vill lägga till en artikel i en befintlig konfiguration måste vi skicka meddelanden till systemet, köra CREATE TABLE-instruktionen och läsa in initiala data vid varje nod i topologin och lägga till den nya artikeln på varje nod i topologin.

• Ta bort artikel: Om vi vill ha ett konsekvent tillstånd på alla noder måste vi quiesce topologin

Mer information finns i Quiesce a Replication Topology (Replication Transact-SQL Programming) och Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).

• Om du lägger till en ny nod i en peer-to-peer-topologi bör du bara återställa från säkerhetskopior som skapades efter att den nya noden lades till.

• Du kan inte initiera om prenumerationer i en peer-to-peer-topologi. Om du måste se till att en nod har en ny kopia av data återställer du en säkerhetskopia på noden.

Relaterat innehåll

• Administrera en peer-to-peer-topologi (replikering Transact-SQL programmering)
• Strategier för säkerhetskopiering och återställning av ögonblicksbilder och transaktionsreplikering
• Transaktionsreplikering