Databasespiegeling en replicatie (SQL Server)

Van toepassing op:SQL Server

Databasespiegeling kan worden gebruikt in combinatie met replicatie om de beschikbaarheid voor de publicatiedatabase te verbeteren. Databasespiegeling omvat twee kopieën van één database die zich doorgaans op verschillende computers bevinden. Op elk gewenst moment is er slechts één exemplaar van de database beschikbaar voor clients. Deze kopie wordt de principal-database genoemd. Updates van clients naar de principal-database worden toegepast op de andere kopie van de database, ook wel de gespiegelde database genoemd. Spiegeling omvat het toepassen van het transactielogboek van elke invoeging, update of verwijdering op de principal-database op de gespiegelde database.

Failover van replicatie naar een mirror wordt volledig ondersteund voor publicatiedatabases, met beperkte ondersteuning voor subscriptiedatabases. Databasespiegeling wordt niet ondersteund voor de distributiedatabase. Zie Back-up en herstel gerepliceerde databases voor informatie over het herstellen van een distributiedatabase of abonnementsdatabase zonder dat u de replicatie opnieuw hoeft te configureren.

Opmerking

Na een failover wordt de spiegel de principal. In dit onderwerp verwijzen 'principal' en 'mirror' altijd naar de oorspronkelijke principal en spiegel.

Vereisten en overwegingen voor het gebruik van replicatie met databasespiegeling

Houd rekening met de volgende vereisten en overwegingen bij het gebruik van replicatie met databasespiegeling:

De hoofd- en spiegelserver moeten een distributeur delen. We raden aan om dit een externe distributeur te laten zijn, wat een grotere fouttolerantie biedt als de uitgever een ongeplande failover heeft.
Replicatie ondersteunt het spiegelen van de publicatiedatabase voor fusiereplicatie en voor transactionele replicatie met alleen-lezen abonnees of abonnees met wachtrij-bijwerkingen. Bijwerken van Abonnees, Oracle-uitgevers, Uitgevers in een peer-to-peertopologie en opnieuw publiceren worden niet ondersteund.
Metagegevens en objecten die buiten de database bestaan, worden niet gekopieerd naar de mirror, waaronder aanmeldingen, taken, gekoppelde servers, enzovoort. Als u de metagegevens en objecten in de spiegel nodig hebt, moet u ze handmatig kopiëren. Zie Het beheer van aanmeldingen en taken na het overschakelen van functies (SQL Server) voor meer informatie.

Configureren van replicatie met databasespiegeling

Het configureren van replicatie en databasespiegeling omvat vijf stappen. Elke stap wordt uitgebreid beschreven in de volgende sectie.

Configureer de uitgever.
Databasespiegeling configureren.
Configureer de spiegel om dezelfde Distributor als de principal te gebruiken.
Configureer replicatieagents voor failover.
Voeg de principal en de mirror toe aan de Replicatiemonitor.

Stap 1 en 2 kunnen ook in omgekeerde volgorde worden uitgevoerd.

Databasespiegeling configureren voor een publicatiedatabase

De uitgever configureren:
1. We raden u aan een externe distributeur te gebruiken. Zie Distributie configureren voor meer informatie over het configureren van distributie.
2. U kunt een database inschakelen voor momentopname en transactionele publicaties en/of publicaties samenvoegen. Voor gespiegelde databases die meer dan één type publicatie bevatten, moet u de database inschakelen voor beide typen op hetzelfde knooppunt met behulp van sp_replicationdboption. U kunt bijvoorbeeld de volgende opgeslagen procedure-aanroepen uitvoeren bij de principal:
```
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true;  
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true;  
```
  Zie Gegevens en databaseobjecten publiceren voor meer informatie over het maken van publicaties.
Databasespiegeling configureren. Zie Een databasespiegelingssessie tot stand brengen met behulp van Windows-verificatie (SQL Server Management Studio) en het instellen van databasespiegeling (SQL Server) voor meer informatie.
Configureer de distributie voor de spiegel. Geef de mirrornaam op als de Publisher en specificeer dezelfde Distributor en momentopnamemap die door de principal wordt gebruikt. Als u bijvoorbeeld replicatie configureert met opgeslagen procedures, voert u sp_adddistpublisher uit bij de distributeur; en voer sp_adddistributor vervolgens uit in de spiegel. Voor sp_adddistpublisher:
- Stel de waarde van de parameter @publisher in op de netwerknaam van de spiegel.
- Stel de waarde van de parameter @working_directory in op de momentopnamemap die door de principal wordt gebruikt.
Geef de mirrornaam op voor de parameter -PublisherFailoverPartner-agent . Agent Deze parameter is vereist voor de volgende agents om de mirror te identificeren na een failover:
- Snapshot Agent (voor alle publicaties)
- Logboeklezeragent (voor alle transactionele publicaties)
- Queue Reader Agent (voor transactionele publicaties die ondersteuning bieden voor het bijwerken van abonnementen in de wachtrij)
- Samenvoegagent (voor samenvoegabonnementen)
- SQL Server-replicatielistener (replisapi.dll: voor het samenvoegen van abonnementen die zijn gesynchroniseerd met behulp van websynchronisatie)
- SQL Merge ActiveX-besturingselement (voor samenvoegingsabonnementen die zijn gesynchroniseerd met het besturingselement)
Het distributieagent en Distributie ActiveX-besturingselement hebben deze parameter niet omdat ze niet verbonden zijn met de Publisher.

Wijzigingen in de agentparameter worden van kracht wanneer de agent de volgende keer wordt gestart. Als de agent continu wordt uitgevoerd, moet u de agent stoppen en opnieuw starten. Parameters kunnen worden opgegeven in agentprofielen en vanaf de opdrachtprompt. Voor meer informatie, zie:
- Opdrachtpromptparameters voor replicatieagent weergeven en wijzigen (SQL Server Management Studio)
- Concepten voor uitvoerbare replicatieagents
Wij raden aan om -PublisherFailoverPartner toe te voegen aan een agentprofiel en vervolgens de naam van de mirror in het profiel op te geven. Als u bijvoorbeeld replicatie configureert met opgeslagen procedures:
```
-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.  
-- Select the profile id of the profile that needs to be updated from the result set.  
-- In the agent_type column returned by sp_help_agent_profile:   
-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.  

exec sp_help_agent_profile;  

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).  
-- Execute sp_add_agent_parameter in the context of the distribution database.  
exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).  
-- Execute sp_add_agent_parameter in the context of the distribution database.  
exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  
```
Voeg de principal en mirror toe aan de replicatiemonitor. Zie Publishers toevoegen en verwijderen uit Replicatiemonitor voor meer informatie.

Een gespiegelde publicatiedatabase onderhouden

Het onderhouden van een gespiegelde publicatiedatabase is in wezen hetzelfde als het onderhouden van een niet-gespiegelde database, met de volgende overwegingen:

Beheer en bewaking moeten plaatsvinden op de actieve server. In SQL Server Management Studio worden publicaties alleen weergegeven in de map Lokale publicaties voor de actieve server. Als u bijvoorbeeld een failover naar de mirror uitvoert, worden de publicaties weergegeven op de mirror en niet meer op de principal. Als de database een failover naar de mirror uitvoert, moet u mogelijk Management Studio en Replication Monitor handmatig vernieuwen zodat de wijziging zichtbaar wordt.
Replicatiemonitor geeft Publisher-knooppunten weer in de objectstructuur voor zowel de principal als de spiegel. Als de principal de actieve server is, wordt publicatie-informatie alleen weergegeven onder het principal-knooppunt in Replication Monitor.

Als de mirror de actieve server is:
- Als een agent een fout heeft, wordt de fout alleen op het principal-knooppunt aangegeven, niet op het mirror-knooppunt.
- Als de principal niet beschikbaar is, vertonen de principal- en spiegelknooppunten identieke lijsten met publicaties. Bewaking moet worden uitgevoerd op de publicaties onder het spiegelknooppunt.
Wanneer u opgeslagen procedures of RMO-objecten (Replication Management Objects) gebruikt om replicatie in de spiegel te beheren, moet u voor gevallen waarin u de naam van de uitgever opgeeft, de naam opgeven van het exemplaar waarop de database is ingeschakeld voor replicatie. Gebruik de functie publishingservername om de juiste naam te bepalen.

Wanneer een publicatiedatabase wordt gespiegeld, zijn de replicatiemetagegevens die zijn opgeslagen in de gespiegelde database identiek aan de metagegevens die zijn opgeslagen in de principal-database. Voor publicatiedatabases die zijn ingeschakeld voor replicatie op het principal, is de naam van het Publisher-exemplaar dat is opgeslagen in systeemtabellen bij de spiegel, de naam van het principal, niet de spiegel. Dit is van invloed op de replicatieconfiguratie en het onderhoud als de publicatiedatabase een failover naar de mirror uitvoert. Als u bijvoorbeeld replicatie configureert met opgeslagen procedures op de mirror na een failover en u een pull-abonnement wilt toevoegen aan een publicatiedatabase die is ingeschakeld bij de principal, moet u de principal-naam opgeven in plaats van de mirrornaam voor de parameter @publisher van sp_addpullsubscription of sp_addmergepullsubscription.

Als u na een failover naar de spiegel een publicatiedatabase inschakelt in de spiegel, is de naam van de Publisher-instantie die is opgeslagen in systeemtabellen de naam van de spiegel; in dit geval gebruikt u de naam van de spiegel voor de parameter @publisher.

Opmerking

In sommige gevallen, zoals sp_addpublication, wordt de parameter @publisher alleen ondersteund voor niet-SQL Server Publishers; in deze gevallen is het niet relevant voor sql Server-databasespiegeling.
Een abonnement synchroniseren in Management Studio na een failover: pull-abonnementen synchroniseren van de abonnee; en pushabonnementen vanuit de actieve uitgever synchroniseren.

Replicatiegedrag als spiegeling wordt verwijderd

Houd rekening met de volgende problemen als databasespiegeling wordt verwijderd uit een gepubliceerde database:

Als de publicatiedatabase in de principal niet meer wordt gespiegeld, blijft de replicatie ongewijzigd ten opzichte van de oorspronkelijke principal.
Als de publicatiedatabase een failover van de principal naar de mirror uitvoert en de spiegelingsrelatie vervolgens wordt uitgeschakeld of verwijderd, werken replicatieagents niet voor de mirror. Als de principal permanent verloren gaat, schakelt u replicatie uit en configureert u deze opnieuw met de mirror die is opgegeven als uitgever.
Als databasespiegeling volledig wordt verwijderd, heeft de gespiegelde database een herstelstatus en moet deze worden hersteld om functioneel te worden. Het gedrag van de herstelde database met betrekking tot replicatie is afhankelijk van of de optie KEEP_REPLICATION is opgegeven. Met deze optie wordt de herstelbewerking gedwongen om replicatie-instellingen te behouden bij het herstellen van een gepubliceerde database naar een andere server dan die waarop de back-up is gemaakt. Gebruik de optie KEEP_REPLICATION alleen als de andere publicatiedatabase niet beschikbaar is. De optie wordt niet ondersteund als de andere publicatiedatabase nog steeds intact is en repliceert. Zie RESTORE (Transact-SQL) voor meer informatie over KEEP_REPLICATION.

Gedrag van logboeklezeragent

In de volgende tabel wordt het gedrag van de logboeklezeragent beschreven voor de verschillende besturingsmodi van databasespiegeling.

Bedrijfsmodus	Gedrag van logboeklezeragent als de spiegel niet beschikbaar is
Modus voor hoge veiligheid met automatische failover	Als de spiegel niet beschikbaar is, worden opdrachten door de logboeklezeragent doorgegeven aan de distributiedatabase. De primaire server kan niet overschakelen naar de mirrorserver totdat het mirrorsysteem weer online is en alle transacties van de primaire server heeft.
Modus met hoge prestaties	Als de spiegel niet beschikbaar is, draait de principal-database zonder bescherming (dat wil zeggen, zonder spiegeling). De logboeklezeragent repliceert echter alleen de transacties die zijn doorgeschreven naar de mirror. Als de service wordt gedwongen en de mirrorserver de rol van de principal aanneemt, werkt de logboeklezeragent tegen de spiegel en begint de nieuwe transacties op te halen. Houd er rekening mee dat de replicatielatentie toeneemt als de spiegel achter de principal valt.
Modus voor hoge veiligheid zonder automatische failover	Alle vastgelegde transacties worden gegarandeerd naar schijf opgeslagen op de spiegel. De Log Reader Agent repliceert alleen die transacties die zijn vastgelegd op de mirror. Als de spiegel niet beschikbaar is, verbiedt de principal verdere activiteit in de database; daarom heeft de Log Reader Agent geen transacties om in de database te repliceren.

Zie ook

SQL Server-replicatie
Logboekverzending en replicatie (SQL Server)

Feedback

Is deze pagina nuttig?

Last updated on 2026-01-17