Dela via


Slå samman replikeringsmetod

gäller för:SQL Server

Sammanslagningsreplikering, till exempel transaktionsreplikering, börjar vanligtvis med en ögonblicksbild av publikationsdatabasobjekten och data. Efterföljande dataändringar och schemaändringar som görs i Publisher och Prenumeranter spåras med utlösare. Prenumeranten synkroniseras med utgivaren när den är ansluten till nätverket och utbyter alla rader som har ändrats mellan utgivaren och prenumeranten sedan synkroniseringen senast inträffade.

Sammanslagningsreplikering används vanligtvis i server-till-klient-miljöer. Sammanslagningsreplikering är lämplig i någon av följande situationer:

  • Flera prenumeranter kan uppdatera samma data vid olika tidpunkter och sprida ändringarna till utgivaren och till andra prenumeranter.

  • Prenumeranter måste ta emot data, göra ändringar offline och senare synkronisera ändringar med utgivaren och andra prenumeranter.

  • Varje prenumerant kräver en annan partition av data.

  • Konflikter kan uppstå och när de gör det behöver du möjlighet att identifiera och lösa dem.

  • Programmet kräver nettodataändring i stället för åtkomst till mellanliggande datatillstånd. Om en rad till exempel ändras fem gånger hos en Prenumerant innan den synkroniseras med en Utgivare ändras raden bara en gång i Publisher för att återspegla nettodataändringen (det vill säga det femte värdet).

Med sammanslagningsreplikering kan olika platser arbeta självständigt och senare slå samman uppdateringar till ett enda, enhetligt resultat. Eftersom uppdateringar görs på mer än en nod kan samma data ha uppdaterats av utgivaren och av mer än en prenumerant. Konflikter kan därför uppstå när uppdateringar slås samman och sammanslagningsreplikering ger flera sätt att hantera konflikter.

Sammanslagningsreplikering implementeras av SQL Server Snapshot Agent och Merge Agent. Om publikationen är ofiltrerad eller använder statiska filter skapar Ögonblicksbildsagenten en enda ögonblicksbild. Om publikationen använder parameteriserade filter skapar Ögonblicksbildsagenten en ögonblicksbild för varje partition av data. Sammanslagningsagenten tillämpar de första ögonblicksbilderna på prenumeranterna. Den sammanfogar även inkrementella dataändringar som inträffat i Publisher eller Prenumeranter efter att den första ögonblicksbilden skapades, och identifierar och löser eventuella konflikter enligt de regler som du konfigurerar.

Om du vill spåra ändringar måste sammanslagningsreplikering (och transaktionsreplikering med prenumerationer i kö) kunna identifiera varje rad i varje publicerad tabell unikt. För att åstadkomma den här sammanslagningsreplikeringen läggs kolumnen rowguid till i varje tabell, såvida inte tabellen redan har en kolumn av datatypen uniqueidentifier med egenskapsuppsättningen ROWGUIDCOL (i vilket fall den här kolumnen används). Om tabellen tas bort från publikationen rowguid tas kolumnen bort. Om en befintlig kolumn användes för spårning tas inte kolumnen bort. Ett filter får inte innehålla den rowguidcol som används av replikeringen för att identifiera rader. Funktionen newid() tillhandahålls som standard för rowguid kolumnen, men kunderna kan ange ett guid för varje rad om det behövs. Ange dock inte värdet 00000000-0000-0000-0000-000000000000.

Följande diagram visar de komponenter som används vid sammanslagningsreplikering.

Diagram över komponenter för merge-replikering och datans flöde.

Konfigurera TLS 1.3-kryptering

Förhandsversionen av SQL Server 2025 (17.x) introducerar TDS 8.0-stöd för sammanslagningsreplikering, 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.

I det här avsnittet