Delen via

Replicatie, wijzigingen bijhouden en vastleggen van wijzigingen - AlwaysOn-beschikbaarheidsgroepen

Van toepassing op:SQL Server

SQL Server-replicatie, cdc (change data capture) en wijzigingen bijhouden (CT) worden ondersteund in AlwaysOn-beschikbaarheidsgroepen. AlwaysOn-beschikbaarheidsgroepen bieden hoge beschikbaarheid en andere mogelijkheden voor databaseherstel.

Overzicht van replicatie met beschikbaarheidsgroepen

Publisher-omleiding

Wanneer een gepubliceerde database op de hoogte is van AlwaysOn-beschikbaarheidsgroepen, wordt de distributeur die agenttoegang tot de publicatiedatabase biedt geconfigureerd met redirected_publishers vermeldingen. Met deze vermeldingen wordt het oorspronkelijk geconfigureerde uitgever-/databasepaar omgeleid, waardoor de naam van een listener voor een beschikbaarheidsgroep wordt gebruikt om verbinding te maken met de uitgever en de publicatiedatabase. Tot stand gebrachte verbindingen via de naam van de listener van de beschikbaarheidsgroep mislukken bij failover. Wanneer de replicatieagent na een failover opnieuw wordt opgestart, wordt de verbinding automatisch omgeleid naar de nieuwe primaire.

In een beschikbaarheidsgroep (AG) kan een secundaire database geen uitgever zijn. Opnieuw publiceren wordt alleen ondersteund wanneer transactionele replicatie wordt gecombineerd met AlwaysOn-beschikbaarheidsgroepen.

Als een gepubliceerde database lid is van een beschikbaarheidsgroep en de uitgever wordt omgeleid, moet deze worden omgeleid naar een listenernaam voor een beschikbaarheidsgroep die is gekoppeld aan de beschikbaarheidsgroep. Het wordt mogelijk niet omgeleid naar een expliciet knooppunt.

Opmerking

Na een failover naar een secundaire replica kan Replicatiecontrole de naam van het publicatie-exemplaar van SQL Server niet aanpassen en blijft replicatiegegevens weergeven onder de naam van het oorspronkelijke primaire exemplaar van SQL Server. Na een failover kan een tracertoken niet worden ingevoerd met behulp van de replicatiemonitor, maar een tracertoken dat is ingevoerd op de nieuwe uitgever met behulp van Transact-SQL, is zichtbaar in Replication Monitor.

Algemene wijzigingen in replicatieagents ter ondersteuning van beschikbaarheidsgroepen

Er zijn drie replicatieagents gewijzigd ter ondersteuning van AlwaysOn-beschikbaarheidsgroepen. De agents logboeklezer, momentopname en samenvoeging zijn gewijzigd om een query uit te voeren op de distributiedatabase voor de omgeleide uitgever en om de naam van de geretourneerde listener voor beschikbaarheidsgroepen te gebruiken, als een omgeleide uitgever is gedeclareerd, om verbinding te maken met de uitgever van de database.

Wanneer de agents de distributeur opvragen om te bepalen of de oorspronkelijke uitgever is omgeleid, wordt de geschiktheid van het huidige doel of de omleiding gecontroleerd voordat de omgeleide host naar de agent wordt geretourneerd. Dit gedrag wordt aanbevolen. Als het opstarten van de agent echter vaak voorkomt, kan de overhead die is gekoppeld aan de opgeslagen validatieprocedure, te kostbaar worden geacht. Er is een nieuwe opdrachtregelswitch, BypassPublisherValidation, toegevoegd aan de logboeklezer, momentopname en samenvoegingsagenten. Wanneer de switch wordt gebruikt, wordt de omgeleide uitgever onmiddellijk geretourneerd naar de agent en wordt de uitvoering van de opgeslagen validatieprocedure overgeslagen.

Fouten die worden geretourneerd door de opgeslagen validatieprocedure, worden vastgelegd in de geschiedenislogboeken van de agent. Deze fouten met ernst groter dan of gelijk aan 16 zorgen ervoor dat de agents worden beëindigd. Sommige mogelijkheden voor opnieuw proberen zijn ingebouwd in de agents om de verwachte verbinding met een gepubliceerde database af te handelen wanneer er een failover naar een nieuwe primaire database wordt uitgevoerd.

Wijzigingen in de logboeklezeragent

De logboeklezeragent heeft de volgende wijzigingen.

  • Gerepliceerde databaseconsistentie

    Wanneer een gepubliceerde database lid is van een beschikbaarheidsgroep, verwerkt de logboeklezer standaard geen logboekrecords die nog niet zijn beveiligd op alle secundaire replica's van de beschikbaarheidsgroep. Dit zorgt ervoor dat bij failover alle rijen die worden gerepliceerd naar een abonnee ook aanwezig zijn op de nieuwe primaire locatie.

    Wanneer de uitgever slechts twee beschikbaarheidsreplica's (één primaire en een secundaire replica) heeft en er een failover plaatsvindt, blijft de oorspronkelijke primaire replica offline omdat de logboeklezer niet verder gaat totdat alle secundaire databases weer online zijn gebracht of totdat de mislukte secundaire replica's uit de beschikbaarheidsgroep worden verwijderd. De logboeklezer, die nu wordt uitgevoerd op de secundaire database, gaat niet verder omdat de beschikbaarheidsgroep geen wijzigingen in een secundaire database kan beperken. Als u wilt dat de logboeklezer verdergaat en nog steeds capaciteit voor herstel na noodgevallen heeft, verwijdert u de oorspronkelijke primaire replica uit de beschikbaarheidsgroep met behulp van ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA. Voeg vervolgens een nieuwe secundaire replica toe aan de beschikbaarheidsgroep.

  • Traceringsvlag 1448

    Met traceringsvlag 1448 kan de replicatielogboeklezer vooruitgaan, zelfs als de asynchrone secundaire replica's de ontvangst van een wijziging niet hebben bevestigd. Zelfs als deze traceringsvlag is ingeschakeld, wacht de logboeklezer altijd op de synchrone secundaire replica's (ze kunnen asynchrone doorvoermodus worden, zoals hier wordt beschreven, zodat de logboeklezer verder kan gaan). De logboeklezer gaat niet verder dan de min-ack van de synchrone secundaire replica's. Deze traceringsvlag is van toepassing op het exemplaar van SQL Server, niet alleen op een beschikbaarheidsgroep, een beschikbaarheidsdatabase of een exemplaar van een logboeklezer. Deze traceringsvlag moet zijn ingeschakeld op het uitgeverexemplaren. Het wordt onmiddellijk van kracht zonder opnieuw opstarten. Deze kan van tevoren worden geactiveerd of wanneer een asynchrone secundaire replica mislukt.

Opgeslagen procedures die beschikbaarheidsgroepen ondersteunen

  • sp_redirect_publisher

    De opgeslagen procedure sp_redirect_publisher wordt gebruikt om een omgeleide uitgever op te geven voor een bestaand uitgevers-/databasepaar. Als de uitgeverdatabase deel uitmaakt van een beschikbaarheidsgroep, is de omgeleide uitgever de naam van de listener voor de beschikbaarheidsgroep.

  • sp_get_redirected_publisher

    De opgeslagen procedure sp_get_redirected_publisher wordt door replicatieagenten gebruikt om een query uit te voeren op een distributeur om te bepalen of een uitgever/databasepaar een gedefinieerde omleidingsuitgever heeft. Deze opgeslagen procedure dient twee doeleinden. Eerst kan de agent bepalen of de oorspronkelijke uitgever is omgeleid. Ten tweede kan er ook een opgeslagen validatieprocedure worden gestart bij de distributeur (sp_validate_redirected_publisher) die de geschiktheid van het doelknooppunt van de omleiding verifieert om als uitgever voor de benoemde database te fungeren.

    Als u deze opgeslagen procedure wilt uitvoeren, moet de aanroeper lid zijn van de serverfunctie sysadmin , de db_owner-databaserol voor de distributiedatabase of een lid van een publicatietoegangslijst voor een gedefinieerde publicatie die is gekoppeld aan de uitgeverdatabase.

  • sp_validate_redirected_publisher

    Deze opgeslagen procedure probeert te valideren dat de huidige uitgever de gepubliceerde database kan hosten. Deze kan op elk gewenst moment worden aangeroepen om te controleren of de huidige host voor de gepubliceerde database ondersteuning biedt voor replicatie.

  • sp_validate_replicate_hosts_as_publishers

    Hoewel het handig is voor de agents om ervoor te zorgen dat de huidige primaire functie kan fungeren als de replicatie-uitgever voor een uitgeverdatabase, is een meer algemene validatiefunctie nodig om de geldigheid van een volledige replicatietopologie in een beschikbaarheidsgroepdatabase vast te stellen. De opgeslagen procedure sp_validate_replica_hosts_as_publishers is ontworpen om deze behoefte te vullen.

    Deze opgeslagen procedure wordt altijd handmatig uitgevoerd. De beller moet sysadmin zijn bij de distributeur, dbowner van de distributiedatabase of lid van de publicatietoegangslijst van een publicatie van de uitgeverdatabase. Bovendien moet de aanmelding van de aanroeper een geldige aanmelding zijn voor alle beschikbaarheidsreplicahosts en machtigingen hebben voor de beschikbaarheidsdatabase die is gekoppeld aan de uitgeverdatabase.

Gegevensregistratie wijzigen

Databases die zijn ingeschakeld voor het vastleggen van wijzigingengegevens (CDC), kunnen AlwaysOn-beschikbaarheidsgroepen gebruiken om ervoor te zorgen dat de database niet alleen beschikbaar blijft in geval van storing, maar dat wijzigingen in de databasetabellen nog steeds worden bewaakt en in de CDC-wijzigingstabellen worden opgeslagen. De volgorde waarin CDC- en AlwaysOn-beschikbaarheidsgroepen zijn geconfigureerd, is niet belangrijk. Databases met CDC kunnen worden toegevoegd aan AlwaysOn-beschikbaarheidsgroepen en databases die lid zijn van een beschikbaarheidsgroep kunnen worden ingeschakeld voor CDC. In beide gevallen wordt de CDC-configuratie echter altijd uitgevoerd op de huidige of beoogde primaire replica. CDC maakt gebruik van de logboeklezeragent en heeft dezelfde beperkingen als beschreven in de sectie Wijzigingen van de logboeklezeragent eerder in dit artikel.

  • Wijzigingen verzamelen voor het vastleggen van wijzigingen zonder replicatie

    Als CDC is ingeschakeld voor een database, maar replicatie niet is, wordt het opnameproces gebruikt om wijzigingen uit het logboek te verzamelen en deze in CDC-wijzigingstabellen op te slaan, uitgevoerd op de CDC-host als een eigen SQL Agent-taak.

    Als u de oogst van wijzigingen na een failover wilt hervatten, moet de opgeslagen procedure sp_cdc_add_job worden uitgevoerd op de nieuwe primaire server om de lokale capture-taak te maken.

    In het volgende voorbeeld wordt de capture-taak gemaakt.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Wijzigingen verzamelen voor wijzigingsgegevensopname met replicatie

    Als zowel CDC als replicatie zijn ingeschakeld voor een database, verwerkt de logboeklezer de populatie van de CDC-wijzigingstabellen. In dit geval zorgen de technieken die door replicatie worden gebruikt voor het gebruik van AlwaysOn-beschikbaarheidsgroepen ervoor dat wijzigingen blijven worden opgehaald uit het logboek en worden opgeslagen in CDC-wijzigingstabellen na een failover. Er hoeft niets meer te gebeuren voor CDC in deze configuratie om ervoor te zorgen dat de wijzigingstabellen worden ingevuld.

  • Opschoning van gegevensopname wijzigen

    Om ervoor te zorgen dat de juiste opschoning plaatsvindt in de nieuwe primaire database, moet er altijd een lokale opschoontaak worden gemaakt. In het volgende voorbeeld wordt de opschoontaak gemaakt.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Opmerking

    Maak de taken op de nieuwe primaire replica na een failover. De CDC-taken die worden uitgevoerd op de oude primaire database, moeten worden uitgeschakeld wanneer de lokale database een secundaire database wordt. Als de oorspronkelijke replica weer primair wordt, moet u de CDC-taken opnieuw inschakelen op de replica van die replica. Als u taken wilt uitschakelen en inschakelen, gebruikt u de @enabled optie van sp_update_job. Zie sys.sp_cdc_add_job voor meer informatie over het maken van CDC-taken.

  • CDC-rollen toevoegen aan een primaire databasereplica

    Wanneer een tabel is ingeschakeld voor CDC, is het mogelijk om een databaserol te koppelen aan het capture-exemplaar. Als er een rol is opgegeven, moet de gebruiker die de functies met cdc-tabelwaarden wil gebruiken om toegang te krijgen tot wijzigingen voor de tabel, niet alleen toegang hebben tot de bijgehouden tabelkolommen, maar moet ook lid zijn van de benoemde rol. Als de opgegeven rol nog niet bestaat, wordt de rol gemaakt. Wanneer databaserollen automatisch worden toegevoegd aan een primaire database in een beschikbaarheidsgroep, worden de rollen ook doorgegeven aan de secundaire databases van de beschikbaarheidsgroep.

  • Clienttoepassingen die toegang hebben tot CDC-wijzigingsgegevens en beschikbaarheidsgroepen

    Clienttoepassingen die gebruikmaken van de tabelwaardefuncties (TVF's) of gekoppelde servers voor toegang tot tabelgegevens, hebben ook de mogelijkheid nodig om een geschikte CDC-host te vinden na een failover. De naam van de listener van de beschikbaarheidsgroep is het mechanisme dat wordt geboden door AlwaysOn-beschikbaarheidsgroepen om een verbinding transparant te kunnen retargeteren naar een andere host. Zodra een listenernaam voor een beschikbaarheidsgroep is gekoppeld aan een beschikbaarheidsgroep, is deze beschikbaar voor gebruik in TCP-verbindingsreeksen. Twee verschillende verbindingsscenario's worden ondersteund via de naam van de listener van de beschikbaarheidsgroep.

    • Eén zorgt ervoor dat verbindingsaanvragen altijd worden omgeleid naar de huidige primaire replica.
    • Eén zorgt ervoor dat verbindingsaanvragen worden omgeleid naar een alleen-lezen secundaire replica.

    Als u een alleen-lezen secundaire replica zoekt, moet er ook een alleen-lezenrouteringslijst worden gedefinieerd voor de beschikbaarheidsgroep. Zie Alleen-lezenroutering configureren voor een AlwaysOn-beschikbaarheidsgroep voor meer informatie over routeringstoegang tot leesbare secundaire secundaire bestanden.

    Opmerking

    Er is enige doorgiftevertraging gekoppeld aan het maken van een listenernaam voor een beschikbaarheidsgroep en het gebruik ervan door clienttoepassingen voor toegang tot een databasereplica van een beschikbaarheidsgroep.

    Gebruik de volgende query om te bepalen of de naam van een listener voor een beschikbaarheidsgroep is gedefinieerd voor de beschikbaarheidsgroep die als host fungeert voor een CDC-database. De query retourneert de naam van de listener voor de beschikbaarheidsgroep als deze is gemaakt.

    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';

  • De querybelasting omleiden naar een leesbare secundaire replica

    Hoewel een clienttoepassing in veel gevallen altijd verbinding wil maken met de huidige primaire replica, is dit niet de enige manier om AlwaysOn-beschikbaarheidsgroepen te gebruiken. Als een beschikbaarheidsgroep is geconfigureerd ter ondersteuning van leesbare secundaire replica's, kunnen wijzigingsgegevens ook worden verzameld van secundaire knooppunten.

    Wanneer een beschikbaarheidsgroep is geconfigureerd, wordt het ALLOW_CONNECTIONS kenmerk dat is gekoppeld aan de SECONDARY_ROLE gebruikt om het type secundaire toegang op te geven dat wordt ondersteund. Als deze is geconfigureerd als ALL, zijn alle verbindingen met de secundaire toegang toegestaan, maar alleen verbindingen waarvoor alleen-lezentoegang is vereist, slaagt. Als deze is geconfigureerd als READ_ONLY, moet u de intentie alleen-lezen opgeven bij het maken van de verbinding met de secundaire database om de verbinding tot stand te brengen. Zie Alleen-lezentoegang configureren voor een secundaire replica van een AlwaysOn-beschikbaarheidsgroep voor meer informatie.

    De volgende query kan worden gebruikt om te bepalen of de intentie alleen-lezen nodig is om verbinding te maken met een leesbare secundaire replica.

    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';

    De naam van de listener van de beschikbaarheidsgroep of de expliciete knooppuntnaam kan worden gebruikt om de secundaire replica te vinden. Als de naam van de listener van de beschikbaarheidsgroep wordt gebruikt, wordt de toegang omgeleid naar een geschikte secundaire replica.

    Wanneer sp_addlinkedserver wordt gebruikt om een gekoppelde server te maken voor toegang tot de secundaire server, wordt de parameter @datasrc gebruikt voor de naam van de listener van de beschikbaarheidsgroep of de expliciete servernaam en wordt de parameter @provstr gebruikt om de intentie alleen-lezen op te geven.

    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';

  • Clienttoegang tot CDC-wijzigingsgegevens en domeinaanmelding

    Over het algemeen moet u domeinaanmelding gebruiken voor clienttoegang om gegevens te wijzigen die zich in databases bevinden die lid zijn van beschikbaarheidsgroepen. De domeingebruiker heeft toegangsbevoegdheden nodig op alle hosts die replica's van beschikbaarheidsgroepen ondersteunen om na een failover toegangsrechten te krijgen om ervoor te zorgen dat de gegevens na een failover blijven wijzigen. Als een databasegebruiker wordt toegevoegd aan een database in een primaire replica en de gebruiker is gekoppeld aan een domeinaanmelding, wordt de databasegebruiker doorgegeven aan secundaire databases en blijft deze gekoppeld aan de opgegeven domeinaanmelding. Als de nieuwe databasegebruiker is gekoppeld aan een SQL Server-verificatieaanmelding, wordt de gebruiker in de secundaire databases doorgegeven zonder aanmelding. Hoewel de gekoppelde SQL Server-verificatieaanmelding kan worden gebruikt om toegang te krijgen tot wijzigingsgegevens op de primaire locatie waar de databasegebruiker oorspronkelijk is gedefinieerd, is dat knooppunt het enige waar toegang mogelijk zou zijn. De aanmelding bij SQL Server-verificatie zou geen toegang hebben tot gegevens uit een secundaire database, noch tot nieuwe primaire databases dan de oorspronkelijke database waarop de databasegebruiker is gedefinieerd.

  • Wijzigingsgegevens vastleggen uitschakelen

    Als u Change Data Capture (CDC) wilt uitschakelen voor een database die deel uitmaakt van een beschikbaarheidsgroep en u zich in SQL Server 2016 SP2 of hoger bevindt, hoeft u geen extra stappen uit te voeren voor het automatisch afkappen van logboeken. Als u een eerdere versie hebt dan SQL Server 2016 SP2 en CDC uitschakelt op een database die deel uitmaakt van een beschikbaarheidsgroep, moet u een van de volgende stappen implementeren om te voorkomen dat logboeken worden afgekapt nadat CDC is uitgeschakeld:

    • Start de SQL Server-service opnieuw op elk secundair replica-exemplaar.

    • Verwijder de database uit alle secundaire replica-exemplaren van de beschikbaarheidsgroep en voeg deze vervolgens weer toe aan elk replica-exemplaar van de beschikbaarheidsgroep met behulp van automatische of handmatige seeding.

Wijzigingen bijhouden

Een database die is ingeschakeld voor het bijhouden van wijzigingen (CT) kan deel uitmaken van een beschikbaarheidsgroep. Er is geen configuratie meer nodig. Clienttoepassingen voor wijzigingen bijhouden die gebruikmaken van de CDC-functies (TVF's) voor toegang tot wijzigingsgegevens, hebben de mogelijkheid nodig om de primaire replica te vinden na een failover. Als de clienttoepassing verbinding maakt via de naam van de listener voor de beschikbaarheidsgroep, worden verbindingsaanvragen altijd op de juiste manier omgeleid naar de huidige primaire replica.

Wijzigingen bijhouden moet altijd worden verkregen van de primaire replica. Een poging om toegang te krijgen tot wijzigingsgegevens van een secundaire replica resulteert in de volgende fout:

Msg 22117, Level 16, State 1, Line 1

Voor databases die lid zijn van een secundaire replica (dat wil gezegd, voor secundaire databases), wordt het bijhouden van wijzigingen niet ondersteund. Als alternatief voor het uitvoeren van query's voor het bijhouden van wijzigingen op de primaire replica, kunt u een momentopname van een database van een AG-database maken op basis van de secundaire replica en deze vervolgens gebruiken om query's uit te voeren op wijzigingsgegevens. Een momentopname van een database is een alleen-lezen statische weergave van een SQL Server-database (de brondatabase), dus het bijhouden van wijzigingen in de momentopname van de database is het tijdstip waarop de momentopname is gemaakt op de AG-database vanaf de secundaire replica.

Opmerking

Wanneer een failover optreedt in een database waarvoor wijzigingen bijhouden is ingeschakeld, kan de hersteltijd op de nieuwe primaire replica langer duren dan gebruikelijk, omdat voor het bijhouden van wijzigingen een volledige database opnieuw moet worden opgestart.

Vereisten, beperkingen en overwegingen voor het gebruik van replicatie

In deze sectie worden overwegingen beschreven voor het implementeren van replicatie met AlwaysOn-beschikbaarheidsgroepen, waaronder vereisten, beperkingen en aanbevelingen.

Vereiste voorwaarden

  • Wanneer u transactionele replicatie gebruikt en de publicatiedatabase zich in een beschikbaarheidsgroep bevindt, moeten zowel de uitgever als de distributeur ten minste SQL Server 2012 (11.x) uitvoeren. De abonnee kan een lager niveau van SQL Server gebruiken.

  • Wanneer u samenvoegreplicatie gebruikt en de publicatiedatabase zich in een beschikbaarheidsgroep bevindt:

    • Push-abonnement: zowel de uitgever als de distributeur moet ten minste SQL Server 2012 (11.x) uitvoeren.

    • Pull-abonnement: de databases uitgever, distributeur en abonnee moeten zich ten minste op SQL Server 2012 (11.x) bevinden. Dit komt doordat de samenvoegagent op de abonnee moet begrijpen hoe een beschikbaarheidsgroep een failover naar de secundaire kan uitvoeren.

  • De Publisher-exemplaren voldoen aan alle vereisten die nodig zijn om deel te nemen aan een beschikbaarheidsgroep. Zie Vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen voor meer informatie.

Beperkingen

Ondersteunde combinaties van replicatie in AlwaysOn-beschikbaarheidsgroepen:

Replication Publisher Distributeur 1 Subscriber
Transactionele Yes

Opmerking: biedt geen ondersteuning voor bidirectionele en wederzijdse transactionele replicatie.		 Yes Yes
Peer-to-peer2 Yes Ja 3 Yes
Fuseren Yes Nee. Nee.
Momentopname Yes Nee. Yes
Abonnementen die kunnen worden bijgewerkt - voor transactionele replicatie Nee. Nee. Nee.

1 De distributeurdatabase wordt niet ondersteund voor gebruik met databasespiegeling.

2 Vereist SQL Server 2019 CU 13 of hoger.

3 Vereist SQL Server 2019 CU 17 of hoger.

Overwegingen

  • De distributiedatabase wordt niet ondersteund voor gebruik met databasespiegeling, maar wordt ondersteund met AlwaysOn-beschikbaarheidsgroepen waarvoor bepaalde beperkingen gelden. Zie Distributie beschikbaarheidsgroep configureren voor meer informatie. De replicatieconfiguratie is gekoppeld aan het SQL Server-exemplaar waar de distributeur is geconfigureerd; Daarom kan de distributiedatabase niet worden gespiegeld of gerepliceerd. Het is ook mogelijk om hoge beschikbaarheid te bieden voor de distributeur met behulp van een SQL Server-failovercluster. Zie AlwaysOn-failoverclusterexemplaren (SQL Server)voor meer informatie.

  • Abonneefailover naar een secundaire database, terwijl dit wordt ondersteund, is een handmatige procedure voor het samenvoegen van replicatieabonnees. De procedure is in wezen identiek aan de methode die wordt gebruikt om een failover uit te voeren voor een gespiegelde abonneedatabase. Transactionele replicatieabonnees hebben geen speciale verwerking nodig terwijl ze deelnemen aan AlwaysOn-beschikbaarheidsgroepen. Abonnees moeten SQL Server 2012 (11.x) of hoger uitvoeren om deel te nemen aan een beschikbaarheidsgroep. Zie Replicatieabonnees en AlwaysOn-beschikbaarheidsgroepen (SQL Server) voor meer informatie

  • Metagegevens en objecten die buiten de database bestaan, worden niet doorgegeven aan de secundaire replica's, waaronder aanmeldingen, taken, gekoppelde servers. Als u na een failover de metagegevens en objecten in de nieuwe primaire database nodig hebt, moet u deze handmatig kopiëren. Zie Aanmeldingen beheren voor taken met behulp van databases in een AlwaysOn-beschikbaarheidsgroep voor meer informatie.

Gedistribueerde beschikbaarheidsgroepen

De uitgever of distributiedatabase in een beschikbaarheidsgroep kan niet worden geconfigureerd als onderdeel van een gedistribueerde beschikbaarheidsgroep. De uitgeversdatabase in een beschikbaarheidsgroep en de distributiedatabase in een beschikbaarheidsgroep vereisen beide een listener-eindpunt voor de juiste configuratie en het juiste gebruik. Het is echter niet mogelijk om een listener-eindpunt te configureren voor een gedistribueerde beschikbaarheidsgroep.

Replication

Gegevensregistratie wijzigen

Wijzigingen bijhouden

Verwante inhoud