Dela via

Replikering, ändringsspårning och ändring av datainsamling – AlwaysOn-tillgänglighetsgrupper

Gäller för:SQL Server

SQL Server Replication, change data capture (CDC) och ändringsspårning (CT) stöds i AlwaysOn-tillgänglighetsgrupper. AlwaysOn-tillgänglighetsgrupper ger hög tillgänglighet och andra funktioner för databasåterställning.

Översikt över replikering med tillgänglighetsgrupper

Omdirigering av utgivare

När en publicerad databas är medveten om AlwaysOn-tillgänglighetsgrupper konfigureras distributören som ger agentåtkomst till publiceringsdatabasen med redirected_publishers poster. Dessa poster omdirigerar det ursprungligen konfigurerade utgivar-/databasparet och använder ett lyssnarnamn för tillgänglighetsgruppen för att ansluta till utgivaren och publiceringsdatabasen. Upprättade anslutningar via tillgänglighetsgruppens lyssnarnamn misslyckas vid redundansväxling. När replikeringsagenten startas om efter redundansväxling omdirigeras anslutningen automatiskt till den nya primära.

I en tillgänglighetsgrupp (AG) kan en sekundär databas inte vara utgivare. Återpublicering stöds endast när transaktionsreplikering kombineras med AlwaysOn-tillgänglighetsgrupper.

Om en publicerad databas är medlem i en tillgänglighetsgrupp och utgivaren omdirigeras måste den omdirigeras till ett lyssnarnamn för tillgänglighetsgruppen som är associerat med tillgänglighetsgruppen. Den kanske inte omdirigeras till en explicit nod.

Anmärkning

Efter redundansväxlingen till en sekundär replik kan Replikeringsövervakaren inte justera namnet på publiceringsinstansen av SQL Server och fortsätter att visa replikeringsinformation under namnet på den ursprungliga primära instansen av SQL Server. Efter redundansväxlingen kan en spårningstoken inte anges med hjälp av Replikeringsövervakaren, men en spårningstoken som anges i den nya utgivaren med hjälp av Transact-SQL visas i Replikeringsövervakaren.

Allmänna ändringar av replikeringsagenter för att stödja tillgänglighetsgrupper

Tre replikeringsagenter ändrades för att stödja AlwaysOn-tillgänglighetsgrupper. Log Reader-, Snapshot- och Merge-agenterna ändrades för att fråga distributionsdatabasen efter den omdirigerade utgivaren och för att använda det returnerade lyssnarnamnet för tillgänglighetsgruppen, om en omdirigerad utgivare deklarerades, för att ansluta till databasutgivaren.

När agenterna som standard frågar distributören för att avgöra om den ursprungliga utgivaren har omdirigerats verifieras lämpligheten för det aktuella målet eller omdirigeringen innan den omdirigerade värden returneras till agenten. Det här beteendet rekommenderas. Men om agentstart sker ofta kan de kostnader som är associerade med den validerings lagrade proceduren anses vara för kostsamma. En ny kommandoradsväxel, BypassPublisherValidation, har lagts till i logläsaren, snapshot- och merge-agenterna. När växeln används returneras den omdirigerade utgivaren omedelbart till agenten och körningen av den lagrade valideringsproceduren kringgås.

Fel som returneras från den lagrade valideringsproceduren loggas i agenthistorikloggarna. Dessa fel med allvarlighetsgrad större än eller lika med 16 gör att agenterna avslutas. Vissa återförsöksfunktioner har byggts in i agenterna för att hantera den förväntade frånkopplingen från en publicerad databas när den redundansväxlar till en ny primär databas.

Ändringar av log reader-agenten

Loggläsaragenten har följande ändringar.

  • Replikerad databaskonsekvens

    När en publicerad databas är medlem i en tillgänglighetsgrupp bearbetar loggläsaren som standard inte loggposter som inte redan har hårdnat på alla sekundära repliker i tillgänglighetsgruppen. Detta säkerställer att alla rader som replikeras till en prenumerant vid redundansväxling också finns på den nya primära platsen.

    När utgivaren bara har två tillgänglighetsrepliker (en primär och en sekundär) och en redundansväxling sker förblir den ursprungliga primära repliken nere eftersom loggläsaren inte går framåt förrän alla sekundära databaser är online igen eller tills de sekundära replikerna som misslyckas tas bort från tillgänglighetsgruppen. Loggläsaren, som nu körs mot den sekundära databasen, fortsätter inte framåt eftersom tillgänglighetsgruppen inte kan härda några ändringar i någon sekundär databas. Om du vill att loggläsaren ska kunna fortsätta och fortfarande har haveriberedskapskapacitet tar du bort den ursprungliga primära repliken från tillgänglighetsgruppen med hjälp av ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA. Lägg sedan till en ny sekundär replik i tillgänglighetsgruppen.

  • Spårningsflagga 1448

    Spårningsflagga 1448 gör det möjligt för loggläsaren för replikering att gå vidare även om de asynkrona sekundära replikerna inte har bekräftat att en ändring mottagits. Även med den här spårningsflaggan aktiverad väntar loggläsaren alltid på de synkrona sekundära replikerna (de kan bli asynkrona incheckningsläge enligt beskrivningen här, så loggläsaren kan gå vidare). Loggläsaren går inte längre än de synkrona sekundära replikernas minsta ack. Den här spårningsflaggan gäller för instansen av SQL Server, inte bara för en tillgänglighetsgrupp, en tillgänglighetsdatabas eller en loggläsarinstans. Den här spårningsflaggan måste vara aktiverad på utgivarinstansen. Den börjar gälla omedelbart utan omstart. Den kan aktiveras i förväg eller när en asynkron sekundär replik misslyckas.

Lagrade procedurer som stöder tillgänglighetsgrupper

  • sp_redirect_publisher

    Den lagrade proceduren sp_redirect_publisher används för att ange en omdirigerad utgivare för ett befintligt utgivar-/databaspar. Om utgivardatabasen tillhör en tillgänglighetsgrupp är den omdirigerade utgivaren lyssnarnamnet för tillgänglighetsgruppen.

  • sp_get_redirected_publisher

    Den lagrade proceduren sp_get_redirected_publisher används av replikeringsagenter för att fråga en distributör för att avgöra om ett utgivare/databaspar har en definierad omdirigerad utgivare. Den här lagrade proceduren har två syften. Först kan agenten avgöra om den ursprungliga utgivaren har omdirigerats. För det andra kan den också initiera en validerings lagrad procedur som körs på distributören (sp_validate_redirected_publisher) som verifierar lämpligheten hos målnoden för omdirigeringen för att fungera som utgivare för den namngivna databasen.

    Om du vill köra den här lagrade proceduren måste anroparen antingen vara medlem i sysadmin-serverrollen , db_owner databasrollen för distributionsdatabasen eller medlem i en publikationsåtkomstlista för en definierad publikation som är associerad med utgivardatabasen.

  • sp_validate_redirected_publisher

    Den här lagrade proceduren försöker verifiera att den aktuella utgivaren kan vara värd för den publicerade databasen. Det kan anropas när som helst för att kontrollera att den aktuella värden för den publicerade databasen kan stödja replikering.

  • sp_validate_replicate_hosts_as_publishers

    Det är användbart för agenterna att se till att den aktuella primära filen kan fungera som replikeringsutgivare för en utgivardatabas, men det krävs en mer allmän valideringsfunktion för att fastställa giltigheten för en hel replikeringstopologi i en tillgänglighetsgruppdatabas. Den lagrade proceduren sp_validate_replica_hosts_as_publishers är utformad för att fylla detta behov.

    Den här lagrade proceduren körs alltid manuellt. Anroparen måste antingen vara sysadmin hos distributören, dbowner för distributionsdatabasen eller en medlem i publikationens åtkomstlista för en publikation av utgivardatabasen. Dessutom måste inloggningen för anroparen vara en giltig inloggning för alla tillgänglighetsreplikvärdar och ha väljbehörighet för tillgänglighetsdatabasen som är associerad med utgivarens databas.

Ändra datainsamling

Databaser som är aktiverade för ändringsdatainsamling (CDC) kan använda AlwaysOn-tillgänglighetsgrupper för att säkerställa inte bara att databasen förblir tillgänglig i händelse av fel, utan att ändringar i databastabellerna fortsätter att övervakas och deponeras i CDC-ändringstabellerna. Det är inte viktigt i vilken ordning CDC- och AlwaysOn-tillgänglighetsgrupper konfigureras. CDC-aktiverade databaser kan läggas till i AlwaysOn-tillgänglighetsgrupper och databaser som är medlemmar i en tillgänglighetsgrupp kan aktiveras för CDC. I båda fallen utförs dock CDC-konfigurationen alltid på den aktuella eller avsedda primära repliken. CDC använder loggläsaragenten och har samma begränsningar som beskrivs i avsnittet om ändringar av loggläsarens agent tidigare i den här artikeln.

  • Samla in ändringar för insamling av ändringsdata utan replikering

    Om CDC är aktiverat för en databas, men replikeringen inte är det, körs insamlingsprocessen som används för att samla in ändringar från loggen och sätta in dem i CDC-ändringstabeller på CDC-värden som ett eget SQL Agent-jobb.

    För att återuppta insamlingen av ändringar efter redundans måste den lagrade proceduren sp_cdc_add_job köras på den nya primära för att skapa det lokala avbildningsjobbet.

    I följande exempel skapas avbildningsjobbet.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Samla in ändringar för insamling av ändringsdata med replikering

    Om både CDC och replikering är aktiverade för en databas hanterar loggläsaren populationen av CDC-ändringstabellerna. I det här fallet säkerställer de tekniker som används av replikering för att använda AlwaysOn-tillgänglighetsgrupper att ändringar fortsätter att skördas från loggen och deponeras i CDC-ändringstabeller efter redundansväxling. Inget mer behöver göras för CDC i den här konfigurationen för att säkerställa att ändringstabellerna fylls i.

  • Ändra rensning av datainsamling

    För att säkerställa att lämplig rensning sker i den nya primära databasen bör ett lokalt rensningsjobb alltid skapas. I följande exempel skapas rensningsjobbet.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Anmärkning

    Du bör skapa jobben på den nya primära repliken efter redundansväxlingen. CDC-jobben som körs på den gamla primära databasen bör inaktiveras när den lokala databasen blir en sekundär databas. Om den ursprungliga repliken blir primär igen måste du återaktivera CDC-jobben på replikens replik. Om du vill inaktivera och aktivera jobb använder du alternativet @enabledsp_update_job. Mer information om hur du skapar CDC-jobb finns i sys.sp_cdc_add_job.

  • Lägga till CDC-roller i en primär databasreplik

    När en tabell är aktiverad för CDC är det möjligt att associera en databasroll med insamlingsinstansen. Om en roll anges måste användaren som vill använda CDC-tabellvärdesfunktionerna för att komma åt ändringar för tabellen inte bara ha valt åtkomst till de spårade tabellkolumnerna, utan måste också vara medlem i den namngivna rollen. Om den angivna rollen inte redan finns skapas rollen. När databasroller läggs till automatiskt i en primär databas i en tillgänglighetsgrupp sprids rollerna också till de sekundära databaserna i tillgänglighetsgruppen.

  • Klientprogram som har åtkomst till CDC ändrar data och tillgänglighetsgrupper

    Klientprogram som använder tabellvärdesfunktioner (TVF:er) eller länkade servrar för att komma åt ändringstabelldata behöver också möjlighet att hitta en lämplig CDC-värd efter redundansväxlingen. Tillgänglighetsgruppens lyssnarnamn är den mekanism som tillhandahålls av AlwaysOn-tillgänglighetsgrupper för att transparent tillåta att en anslutning omdirigeras till en annan värd. När ett lyssnarnamn för tillgänglighetsgruppen är associerat med en tillgänglighetsgrupp är det tillgängligt att användas i TCP-anslutningssträngar. Två olika anslutningsscenarier stöds via lyssnarnamnet för tillgänglighetsgruppen.

    • En säkerställer att anslutningsbegäranden alltid dirigeras till den aktuella primära repliken.
    • En ser till att anslutningsbegäranden dirigeras till en skrivskyddad sekundär replik.

    Om den används för att hitta en skrivskyddad sekundär replik måste en skrivskyddad routningslista också definieras för tillgänglighetsgruppen. Mer information om hur du dirigerar åtkomst till läsbara sekundärfiler finns i Konfigurera skrivskyddad routning för en AlwaysOn-tillgänglighetsgrupp.

    Anmärkning

    Det finns en viss spridningsfördröjning som är associerad med skapandet av ett lyssnarnamn för tillgänglighetsgruppen och dess användning av klientprogram för att få åtkomst till en tillgänglighetsgruppdatabasreplik.

    Använd följande fråga för att avgöra om ett lyssnarnamn för tillgänglighetsgruppen har definierats för tillgänglighetsgruppen som är värd för en CDC-databas. Frågan returnerar tillgänglighetsgruppens lyssnarnamn om en har skapats.

    SELECT dns_name
FROM sys.availability_group_listeners AS l
     INNER JOIN sys.availability_databases_cluster AS d
         ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

  • Omdirigera frågebelastningen till en läsbar sekundär replik

    I många fall vill ett klientprogram alltid ansluta till den aktuella primära repliken, men det är inte det enda sättet att använda AlwaysOn-tillgänglighetsgrupper. Om en tillgänglighetsgrupp har konfigurerats för att stödja läsbara sekundära repliker kan ändringsdata också samlas in från sekundära noder.

    När en tillgänglighetsgrupp har konfigurerats används ALLOW_CONNECTIONS-attributet som är associerat med SECONDARY_ROLE för att ange vilken typ av sekundär åtkomst som stöds. Om de konfigureras som ALLA tillåts alla anslutningar till den sekundära, men endast de som kräver skrivskyddad åtkomst lyckas. Om det konfigureras som READ_ONLY är det nödvändigt att ange skrivskyddad avsikt när anslutningen till den sekundära databasen upprättas för att anslutningen ska lyckas. Mer information finns i Konfigurera skrivskyddad åtkomst till en sekundär replik av en AlwaysOn-tillgänglighetsgrupp.

    Följande fråga kan användas för att avgöra om skrivskyddad avsikt krävs för att ansluta till en läsbar sekundär replik.

    SELECT g.name AS AG,
          replica_server_name,
          secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
     INNER JOIN sys.availability_groups AS g
          ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME';

    Antingen kan lyssnarnamnet för tillgänglighetsgruppen eller det explicita nodnamnet användas för att hitta den sekundära repliken. Om tillgänglighetsgruppens lyssnarnamn används dirigeras åtkomsten till alla lämpliga sekundära repliker.

    När sp_addlinkedserver används för att skapa en länkad server för att komma åt den sekundära används parametern @datasrc för tillgänglighetsgruppens lyssnarnamn eller det explicita servernamnet, och parametern @provstr används för att ange skrivskyddad avsikt.

    EXECUTE sp_addlinkedserver
    @server = N'linked_svr',
    @srvproduct = N'SqlServer',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'AG_Listener_Name',
    @provstr = N'ApplicationIntent=ReadOnly',
    @catalog = N'MY_DB_NAME';

  • Klientåtkomst till CDC-ändringsdata och domäninloggningar

    I allmänhet bör du använda domäninloggningar för klientåtkomst för att ändra data som finns i databaser som är medlemmar i tillgänglighetsgrupper. För att säkerställa fortsatt åtkomst till att ändra data efter redundans behöver domänanvändaren åtkomstbehörighet på alla värdar som stöder tillgänglighetsgrupprepliker. Om en databasanvändare läggs till i en databas i en primär replik och användaren är associerad med en domäninloggning sprids databasanvändaren till sekundära databaser och fortsätter att associeras med den angivna domäninloggningen. Om den nya databasanvändaren är associerad med en SQL Server-autentiseringsinloggning sprids användaren i de sekundära databaserna utan inloggning. Den associerade SQL Server-autentiseringsinloggningen kan användas för att komma åt ändringsdata på den primära platsen där databasanvändaren ursprungligen definierades, men den noden är den enda där åtkomst skulle vara möjlig. Sql Server-autentiseringsinloggningen skulle inte kunna komma åt data från någon sekundär databas eller från andra nya primära databaser än den ursprungliga databasen där databasanvändaren definierades.

  • Inaktivera insamling av ändringsdata

    Om du behöver inaktivera CDC (Change Data Capture) på en databas som ingår i en tillgänglighetsgrupp och du använder SQL Server 2016 SP2 eller senare behöver du inte utföra några extra steg för automatisk loggtjälkning. Om du har en tidigare version än SQL Server 2016 SP2 och inaktiverar CDC på en databas som ingår i en tillgänglighetsgrupp, måste du implementera något av följande steg för att förhindra blockering av loggtrunkering när CDC har inaktiverats:

    • Starta om SQL Server-tjänsten på varje sekundär replikinstans.

    • Ta bort databasen från alla sekundära replikinstanser i tillgänglighetsgruppen och lägg sedan till den i varje tillgänglighetsgruppreplikinstans med hjälp av automatisk eller manuell seeding.

Spårning av ändringar

En databas som är aktiverad för ändringsspårning (CT) kan ingå i en tillgänglighetsgrupp. Ingen mer konfiguration krävs. Ändringsspårning av klientprogram som använder CDC-tabellvärdesfunktioner (TVF:er) för att komma åt ändringsdata behöver kunna hitta den primära repliken efter redundansväxlingen. Om klientprogrammet ansluter via lyssnarnamnet för tillgänglighetsgruppen dirigeras anslutningsbegäranden alltid korrekt till den aktuella primära repliken.

Ändringsspårningsdata måste alltid hämtas från den primära repliken. Ett försök att komma åt ändringsdata från en sekundär replik resulterar i följande fel:

Msg 22117, Level 16, State 1, Line 1

För databaser som är medlemmar i en sekundär replik (dvs. för sekundära databaser) stöds inte ändringsspårning. Som ett alternativ till att köra frågor om ändringsspårning på den primära repliken kan du skapa en databasögonblicksbild av en tillgänglighetsgruppsdatabas från den sekundära repliken och sedan använda den för att köra frågor mot ändringsdata. En ögonblicksbild av databasen är en skrivskyddad, statisk vy av en SQL Server-databas (källdatabasen), så ändringsspårningsdata i databasögonblicksbilden är den tidpunkt då ögonblicksbilden togs på tillgänglighetsgruppens databas från den sekundära repliken.

Anmärkning

När en redundansväxling sker i en databas med ändringsspårning aktiverat kan återställningstiden för den nya primära repliken ta längre tid än vanligt eftersom ändringsspårning kräver en fullständig databasomstart.

Krav, begränsningar och överväganden för att använda replikering

I det här avsnittet beskrivs överväganden för att distribuera replikering med AlwaysOn-tillgänglighetsgrupper, inklusive krav, begränsningar och rekommendationer.

Förutsättningar

  • När du använder transaktionsreplikering och publiceringsdatabasen finns i en tillgänglighetsgrupp måste både utgivaren och distributören köra minst SQL Server 2012 (11.x). Prenumeranten kan använda en lägre nivå av SQL Server.

  • När du använder sammanslagningsreplikering och publiceringsdatabasen finns i en tillgänglighetsgrupp:

    • Push-prenumeration: Både utgivaren och distributören måste köra minst SQL Server 2012 (11.x).

    • Pull-prenumeration: Databaserna utgivare, distributör och prenumeranter måste finnas på minst SQL Server 2012 (11.x). Det beror på att sammanslagningsagenten på prenumeranten måste förstå hur en tillgänglighetsgrupp kan redundansväxla till sin sekundära.

  • Publisher-instanserna uppfyller alla krav som krävs för att delta i en tillgänglighetsgrupp. Mer information finns i Krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper.

Restrictions

Kombinationer av replikering i AlwaysOn-tillgänglighetsgrupper som stöds:

Replication Utgivare Distributör 1 Subscriber
Transaktionella Yes

Obs! Innehåller inte stöd för dubbelriktad och ömsesidig transaktionsreplikering.		 Yes Yes
Peer-to-peer2 Yes Ja 3 Yes
Slå ihop Yes Nej Nej
Ögonblicksbild Yes Nej Yes
Uppdateringsbara prenumerationer – för transaktionsreplikering Nej Nej Nej

1 Distributörsdatabasen stöds inte för användning med databasspegling.

2 Kräver SQL Server 2019 CU 13 eller senare.

3 Kräver SQL Server 2019 CU 17 eller senare.

Överväganden

  • Distributionsdatabasen stöds inte för användning med databasspegling, men stöds med AlwaysOn-tillgänglighetsgrupper som omfattas av vissa begränsningar. Mer information finns i Konfigurera distributionstillgänglighetsgrupp. Replikeringskonfigurationen är kopplad till SQL Server-instansen där distributören är konfigurerad. Därför kan distributionsdatabasen inte speglas eller replikeras. Det är också möjligt att tillhandahålla hög tillgänglighet för distributören med hjälp av ett SQL Server-redundanskluster. Mer information finns i AlwaysOn-redundansklusterinstanser (SQL Server).

  • Prenumerant redundansväxling till en sekundär databas, även om den stöds, är en manuell procedur för sammanslagning av replikeringsprenumeranter. Proceduren är i stort sett identisk med den metod som används för att redundansväxla en speglad prenumerantdatabas. Transaktionsreplikeringsprenumeranter behöver inte särskild hantering när de deltar i AlwaysOn-tillgänglighetsgrupper. Prenumeranter måste köra SQL Server 2012 (11.x) eller senare för att kunna delta i en tillgänglighetsgrupp. Mer information finns i Replikeringsprenumeranter och AlwaysOn-tillgänglighetsgrupper (SQL Server)

  • Metadata och objekt som finns utanför databasen sprids inte till de sekundära replikerna, inklusive inloggningar, jobb, länkade servrar. Om du behöver metadata och objekt i den nya primära databasen efter redundansväxlingen måste du kopiera dem manuellt. Mer information finns i Hantera inloggningar för jobb med hjälp av databaser i en AlwaysOn-tillgänglighetsgrupp.

Distribuerade tillgänglighetsgrupper

Utgivaren eller distributionsdatabasen i en tillgänglighetsgrupp kan inte konfigureras som en del av en distribuerad tillgänglighetsgrupp. Utgivarens databas i en tillgänglighetsgrupp och distributionsdatabasen i en tillgänglighetsgrupp kräver båda en lyssnarslutpunkt för korrekt konfiguration och användning. Det går dock inte att konfigurera en lyssnarslutpunkt för en grupp för distribuerad tillgänglighet.

Replication

Ändra datainsamling

Spårning av ändringar

Relaterat innehåll