Operationele modi voor databasespiegeling

Van toepassing op:SQL Server

In dit onderwerp worden de synchrone en asynchrone operationele modi voor databasespiegelingsessies beschreven.

Opmerking

Zie Databasespiegeling (SQL Server) voor een inleiding tot databasespiegeling.

Termen en definities

In deze sectie worden enkele termen geïntroduceerd die centraal staan in dit onderwerp.

Modus met hoge prestaties
De databasespiegelingssessie werkt asynchroon en gebruikt alleen de principal-server en mirrorserver. De enige vorm van rolwisseling is een geforceerde service (met mogelijk gegevensverlies).

Modus voor hoge veiligheid
De databasespiegelingssessie werkt synchroon en maakt optioneel gebruik van een witness, evenals de principal-server en mirrorserver.

Transactieveiligheid
Een gespiegelde databaseeigenschap die bepaalt of een databasespiegelingssessie synchroon of asynchroon werkt. Er zijn twee veiligheidsniveaus: FULL en OFF.

Witness
Voor gebruik alleen met de modus hoge veiligheid, een optioneel exemplaar van SQL Server waarmee de mirror-server kan herkennen of een automatische failover moet worden gestart. In tegenstelling tot de twee failoverpartners, beheert de witness de database niet. Het ondersteunen van automatische failover is de enige rol van de witness.

Asynchrone databasespiegeling (High-Performance modus)

In deze sectie wordt beschreven hoe asynchrone databasespiegeling werkt, wanneer het geschikt is om de modus met hoge prestaties te gebruiken en hoe u kunt reageren als de principal-server mislukt.

Opmerking

De meeste edities van SQL Server ondersteunen alleen synchrone databasespiegeling ("Safety Full Only"). Zie 'Hoge beschikbaarheid (AlwaysOn)' in edities en ondersteunde functies van SQL Server 2022 voor informatie over edities die volledig ondersteuning bieden voor databasespiegeling.

Wanneer transactieveiligheid is ingesteld op UIT, werkt de databasespiegelingssessie asynchroon. Asynchrone bewerking ondersteunt slechts één bedrijfsmodus met hoge prestaties. Deze modus verbetert de prestaties ten koste van hoge beschikbaarheid. De modus High Performance maakt gebruik van alleen de principal-server en de mirror-server. Problemen op de mirrorserver hebben nooit invloed op de principal-server. Bij het verlies van de hoofdserver wordt de gespiegelde database gemarkeerd als VERBROKEN, maar is deze beschikbaar als een warme reserve.

Modus met hoge prestaties ondersteunt slechts één vorm van functiewisseling: geforceerde service (met mogelijk gegevensverlies), die de spiegelserver gebruikt als een warme stand-byserver. Geforceerde service is een van de mogelijke reacties bij de uitval van de hoofdserver. Omdat gegevensverlies mogelijk is, moet u alternatieven overwegen voordat u de service naar de mirror overhevelt. Zie Reageren op fouten van de principal verderop in dit onderwerp voor meer informatie.

In de volgende afbeelding ziet u de configuratie van een sessie met behulp van de modus met hoge prestaties.

In de modus met hoge prestaties, zodra de principal-server het logboek voor een transactie naar de mirror-server verzendt, stuurt de principal-server een bevestiging naar de client, zonder te wachten op een bevestiging van de mirror-server. Transacties doorvoeren zonder te wachten totdat de mirrorserver het logboek naar de schijf schrijft. Met asynchrone bewerking kan de principal-server worden uitgevoerd met minimale transactielatentie.

De mirrorserver probeert de logboekrecords bij te houden die door de principal-server worden verzonden. Maar de gespiegelde database kan enigszins achterblijven bij de hoofddatabase, hoewel de kloof tussen de databases meestal klein is. De kloof kan echter aanzienlijk worden als de principal-server onder een zware werkbelasting valt of als het systeem van de mirror-server wordt overbelast.

In deze sectie:

• Wanneer is High-Performance modus geschikt?

• De impact van een getuige op de modus met hoge prestaties

• Reageren op fout van de principal

Wanneer is High-Performance modus geschikt?

De modus met hoge prestaties kan nuttig zijn in een scenario voor herstel na noodgevallen waarin de hoofd- en mirrorservers gescheiden zijn door een aanzienlijke afstand en waarbij u niet wilt dat kleine fouten de hoofdserver beïnvloeden.

Opmerking

Logboekverzending kan een aanvulling zijn op databasespiegeling en is een gunstig alternatief voor asynchrone databasespiegeling. Zie Oplossingen voor hoge beschikbaarheid (SQL Server) voor informatie over de voordelen van logboekverzending. Zie Databasespiegeling en Logboekverzending (SQL Server) voor meer informatie over het gebruik van logboekverzending met databasespiegeling.

De impact van een getuige op de hoogwaardige prestatiemodus

Als u Transact-SQL gebruikt om de modus met hoge prestaties te configureren, raden we u ten zeerste aan om de WITNESS-eigenschap ook in te stellen op UIT. Een getuige kan naast de modus met hoge prestaties bestaan, maar de getuige biedt geen voordeel en introduceert risico.

Als de witness wordt losgekoppeld van de sessie als een van de partners uitvalt, wordt de database onbeschikbaar. Dit komt doordat, zelfs als de modus voor hoge prestaties geen witness vereist, als er een is ingesteld, de sessie een quorum vereist dat bestaat uit twee of meer serverexemplaren. Als de sessie het quorum verliest, kan de database niet worden bediend.

Wanneer een witness is ingesteld in een sessie met hoge prestaties, betekent het afdwingen van quorum dat:

• Als de mirrorserver verloren gaat, moet de principal-server zijn verbonden met de witness. Anders haalt de principal-server de database offline totdat de witness- of mirrorserver opnieuw aan de sessie wordt toegevoegd.

• Als de principal-server verloren gaat, is het noodzakelijk dat de mirrorserver in verbinding staat met de witness om de service naar de mirrorserver over te zetten.

Opmerking

Zie Quorum: Hoe een witness van invloed is op de beschikbaarheid van databases (databasespiegeling) voor informatie over de typen quorums.

Reageren op fout van de principal

Wanneer de principal fout gaat, heeft de dbeigenaar verschillende keuzes:

• Laat de database niet beschikbaar totdat de principal weer beschikbaar is.

  Als de principal-database en het transactielogboek intact zijn, behoudt deze keuze alle vastgelegde transacties ten koste van de beschikbaarheid.

• Stop de databasespiegelingssessie, werk de database handmatig bij en begin vervolgens met een nieuwe sessie voor databasespiegeling.

  Als de hoofd-database verloren gaat, maar de hoofd-server nog steeds actief is, probeert u onmiddellijk de laatste logboekgegevens te back-uppen op de hoofd-database. Als de back-up van het tail-log-logboek slaagt, is het verwijderen van spiegeling mogelijk uw beste alternatief. Nadat u spiegeling hebt verwijderd, kunt u het logboek herstellen naar de voormalige gespiegelde database, waardoor alle gegevens behouden blijven.

  Opmerking

  Als de back-up van het tail-logboek is mislukt en u niet kunt wachten totdat de principal-server is hersteld, kunt u overwegen om de service af te dwingen. Dit heeft het voordeel dat de sessiestatus behouden blijft.

• Forceer de service (met mogelijk gegevensverlies) op de mirrorserver.

  Geforceerde service is strikt een methode voor herstel na noodgevallen en moet spaarzaam worden gebruikt. Het afdwingen van de service is alleen mogelijk als de principal-server niet beschikbaar is, de sessie asynchroon is (transactieveiligheid is ingesteld op UIT) en de sessie heeft geen witness (de eigenschap WITNESS is ingesteld op UIT) of de witness is verbonden met de mirrorserver (dat wil gezegd, ze hebben quorum).

  Het forceren van de service zorgt ervoor dat de mirror-server de rol van principal op zich neemt en zijn kopie van de database beschikbaar stelt aan gebruikers. Wanneer de service wordt gedwongen, gaan alle transactielogboeken die de principal nog niet naar de mirrorserver heeft verzonden, verloren. Daarom moet u geforceerde service beperken tot situaties waarin mogelijk gegevensverlies acceptabel is en de onmiddellijke beschikbaarheid van databases essentieel is. Zie Rolwisseling tijdens een databasespiegelingssessie (SQL Server) voor informatie over hoe geforceerde service werkt en over aanbevolen procedures voor het gebruik ervan.

Synchrone databasespiegeling (Hoge-veiligheidsmodus)

In deze sectie wordt beschreven hoe synchrone databasespiegeling werkt, waaronder de alternatieve modus voor hoge veiligheid (met automatische failover en zonder automatische failover) en bevat informatie over de rol van de witness bij automatische failover.

Wanneer transactieveiligheid is ingesteld op VOLLEDIG, wordt de databasespiegelingssessie uitgevoerd in de modus voor hoge veiligheid en werkt deze synchroon na een initiële synchronisatiefase. In deze sectie worden de details beschreven van databasespiegelingsessies die zijn geconfigureerd voor synchrone bewerking.

Voor een synchrone bewerking voor een sessie moet de mirrorserver de gespiegelde database synchroniseren met de principal-database. Wanneer de sessie begint, begint de principal-server met het verzenden van het actieve logboek naar de mirror-server. De mirror-server schrijft zo snel mogelijk alle binnenkomende logboekrecords naar de schijf. Zodra alle ontvangen logboekrecords naar de schijf zijn geschreven, worden de databases gesynchroniseerd. Zolang de partners in communicatie blijven, blijven de databases gesynchroniseerd.

Opmerking

Als u statuswijzigingen in een databasespiegelingssessie wilt bewaken, gebruikt u de gebeurtenisklasse Databasespiegelingstatuswijziging . Zie Gebeurtenisklasse voor statuswijzigingen bij databasespiegeling voor meer informatie.

Nadat de synchronisatie is voltooid, wordt elke transactie die is doorgevoerd op de principal-database ook doorgevoerd op de mirrorserver, waardoor de gegevens worden beveiligd. Dit wordt bereikt door te wachten op het doorvoeren van een transactie op de principal-database, totdat de principal-server een bericht ontvangt van de mirror-server waarin wordt aangegeven dat het logboek van de transactie naar de schijf is beperkt. Let op: de wachttijd voor dit bericht verhoogt de latentie van de transactie.

De tijd die nodig is voor synchronisatie is in wezen afhankelijk van hoe ver de gespiegelde database zich achter de principal-database bevond aan het begin van de sessie (gemeten door het aantal logboekrecords dat oorspronkelijk is ontvangen van de principal-server), de werkbelasting van de principal-database en de snelheid van het spiegelsysteem. Nadat een sessie is gesynchroniseerd, blijft het geharde logboek dat nog moet worden hersteld op de gespiegelde database in de herstelwachtrij.

Zodra de gespiegelde database wordt gesynchroniseerd, verandert de status van beide kopieën van de database in GESYNCHRONISEERD.

Synchrone bewerking wordt op de volgende manier onderhouden:

1. Bij ontvangst van een transactie van een client schrijft de principal-server het logboek voor de transactie naar het transactielogboek.

2. De principal-server schrijft de transactie naar de database en verzendt de logboekrecord gelijktijdig naar de mirror-server. De principal-server wacht op een bevestiging van de mirror-server voordat een van de volgende aan de client wordt bevestigd: een transactiedoorvoering of een terugdraaiactie.

3. De mirror-server verhardt het logboek op de schijf en retourneert een bevestiging aan de hoofdserver.

4. Bij ontvangst van de bevestiging van de mirrorserver stuurt de principal-server een bevestigingsbericht naar de client.

De modus Hoge veiligheid beschermt uw gegevens door te vereisen dat de gegevens tussen twee plaatsen worden gesynchroniseerd. Alle vastgelegde transacties worden gegarandeerd naar de schijf op de mirrorserver geschreven.

In deze sectie:

• High-Safety Modus zonder automatische failover

• Hoogveiligheidsmodus met automatische failover

High-safety modus zonder automatische failover

In de volgende afbeelding ziet u de configuratie van de modus voor hoge veiligheid zonder automatische failover. De configuratie bestaat alleen uit de twee partners.

Wanneer de partners zijn verbonden en de database al is gesynchroniseerd, wordt handmatige failover ondersteund. Als het exemplaar van de mirrorserver uitvalt, wordt het principal server-exemplaar niet beïnvloed en draait het zonder dat er gegevens worden gespiegeld. Als de principal-server uitvalt, wordt de spiegel onderbroken, maar kan de service worden overgezet naar de spiegelserver (met mogelijk gegevensverlies). Zie Rolwisseling tijdens een databasespiegelingssessie (SQL Server) voor meer informatie.

High-Safety-modus met automatische failover

Automatische failover biedt hoge beschikbaarheid door ervoor te zorgen dat de database nog steeds wordt geleverd na het verlies van één server. Automatische failover vereist dat de sessie een derde serverexemplaar bevat, de witness, die zich idealiter op een derde computer bevindt. In de volgende afbeelding ziet u de configuratie van een sessie met hoge veiligheid die automatische failover ondersteunt.

In tegenstelling tot de twee partners bedient de getuige de database niet. De witness ondersteunt op eenvoudige wijze automatische "failover" door te controleren of de principal-server operationeel is. De mirrorserver initieert alleen automatische failover als de spiegel en de witness met elkaar verbonden blijven nadat beide zijn losgekoppeld van de principal-server.

Wanneer een witness is ingesteld, vereist de sessie quorum - een relatie tussen ten minste twee serverexemplaren, zodat de database beschikbaar is. Voor meer informatie, zie Databasespiegeling Witness en Quorum: Hoe een Witness van invloed is op de beschikbaarheid van databases (Databasespiegeling).

Voor automatische failover zijn de volgende voorwaarden vereist:

• De database is al gesynchroniseerd.

• De fout treedt op terwijl alle drie de serverinstanties zijn verbonden, en de witness- en mirrorserver verbonden blijven.

Het verlies van een partner heeft het volgende effect:

• Als de principal-server niet meer beschikbaar is onder de bovenstaande omstandigheden, vindt automatische failover plaats. De mirrorserver schakelt over naar de rol van hoofd en biedt zijn database aan als hoofd-database.

• Als de principal-server niet meer beschikbaar is wanneer niet aan deze voorwaarden wordt voldaan, kan het afdwingen van de service (met mogelijk gegevensverlies) mogelijk zijn. Zie Rolwisseling tijdens een databasespiegelingssessie (SQL Server) voor meer informatie.

• Als de enige mirrorserver niet meer beschikbaar is, gaan de principal en witness door.

Als de sessie zijn witness verliest, is een quorum alleen mogelijk als beide partners aanwezig zijn. Als een van beide partners quorum verliest, verliezen beide partners quorum en is de database niet meer beschikbaar totdat het quorum opnieuw tot stand is gebracht. Deze quorumvereiste zorgt ervoor dat bij afwezigheid van een witness de database nooit blootgesteld is, dat wil zeggen zonder gespiegeld te zijn.

Opmerking

Als u verwacht dat de witness gedurende een aanzienlijke tijd niet meer verbonden blijft, raden we u aan de witness uit de sessie te verwijderen totdat deze beschikbaar is.

Transact-SQL instellingen en databasespiegelingsmodi

In deze sectie wordt een databasespiegelingssessie beschreven met betrekking tot de ALTER DATABASE-instellingen en de status van de gespiegelde database en getuige, indien van toepassing. De sectie is gericht op gebruikers die databasespiegeling voornamelijk of exclusief beheren met Transact-SQL, in plaats van SQL Server Management Studio te gebruiken.

Aanbeveling

Als alternatief voor het gebruik van Transact-SQL kunt u de bedrijfsmodus van een sessie in Objectverkenner beheren met behulp van de pagina Spiegeling van het dialoogvenster Database-eigenschappen . Zie Een databasespiegelingssessie tot stand brengen met behulp van Windows-verificatie (SQL Server Management Studio) voor meer informatie.

In deze sectie:

• Hoe de veiligheid van de transactie en de getuigenstatus van invloed zijn op de bedrijfsmodus

• De veiligheidsinstelling en de status van de getuige bekijken

• Factoren die van invloed zijn op gedrag bij verlies van de principal-server

Hoe transactieveiligheid en getuigestatus van invloed zijn op de bedrijfsmodus

De werkingmodus van een sessie wordt bepaald door de combinatie van de instelling voor de veiligheid van transacties en de status van de witness. De eigenaar van de database kan op elk gewenst moment het niveau van de transactieveiligheid wijzigen en de witness toevoegen of verwijderen.

In deze sectie:

• Transactieveiligheid

• Witnessstatus

Transactieveiligheid

Transactieveiligheid is een gespiegelde databaseeigenschap die bepaalt of een databasespiegelingssessie synchroon of asynchroon werkt. Er zijn twee veiligheidsniveaus: FULL en OFF.

• VOLLEDIGE VEILIGHEID

  Volledige transactieveiligheid zorgt ervoor dat de sessie synchroon werkt in de modus voor hoge veiligheid. Een sessie ondersteunt automatische failover, als er een 'witness' aanwezig is.

  Wanneer u een sessie tot stand brengt met behulp van ALTER DATABASE-instructies, begint de sessie met de eigenschap SAFETY ingesteld op VOLLEDIG; Dat wil gezegd, de sessie begint in de modus voor hoge veiligheid. Nadat de sessie is gestart, kunt u een witness toevoegen.

  Voor meer informatie, zie eerder in dit onderwerp Synchrone databasespiegeling (modus hoge veiligheid).

• VEILIGHEID UIT

  Door transactieveiligheid uit te schakelen, wordt de sessie asynchroon uitgevoerd in de modus met hoge prestaties. Als de eigenschap SAFETY is ingesteld op UIT, moet de eigenschap WITNESS ook worden ingesteld op UIT (de standaardinstelling). Zie The State of the Witness verderop in dit onderwerp voor meer informatie over de impact van de witness in de modus met hoge prestaties. Zie eerder in dit onderwerp Asynchrone databasespiegeling (High-Performance Mode) voor meer informatie over het uitvoeren met uitgeschakelde transactieveiligheid.

De instelling voor transactieveiligheid van de database wordt voor iedere partner vastgelegd in de catalogusweergave sys.database_mirroring in de kolommen mirroring_safety_level en mirroring_safety_level_desc. Zie sys.database_mirroring (Transact-SQL) voor meer informatie.

De eigenaar van de database kan het niveau van de transactieveiligheid op elk gewenst moment wijzigen.

De staat van de getuige

Als er een witness is ingesteld, is een quorum vereist, waardoor de status van de witness altijd van belang is.

Als deze bestaat, heeft de getuige een van de volgende twee statussen:

• Wanneer de getuige is verbonden met een partner, bevindt de getuige zich in de status VERBONDEN ten opzichte van die partner en bereikt de quorum met die partner. In dit geval kan de database beschikbaar worden gesteld, zelfs als een van de partners niet beschikbaar is.

• Wanneer de witness bestaat maar niet is verbonden met een partner, bevindt de witness zich in de status ONBEKEND of VERBROKEN ten opzichte van die partner. In dit geval ontbreekt de getuige aan quorum met die partner en als de partners niet met elkaar zijn verbonden, is de database niet meer beschikbaar.

Zie Quorum: Hoe een witness van invloed is op de beschikbaarheid van de database (databasespiegeling) voor meer informatie over quorum.

De status van elke witness op een serverexemplaar wordt in de sys.database_mirroring catalogusweergave vastgelegd in de kolommen mirroring_witness_state en mirroring_witness_state_desc. Zie sys.database_mirroring (Transact-SQL) voor meer informatie.

De volgende tabel geeft een overzicht van hoe de bedrijfsmodus van een sessie afhankelijk is van de instelling voor transactieveiligheid en de status van de witness.

Bedrijfsmodus	Transactieveiligheid	Witness-toestand
Modus met hoge prestaties	OFF	NULL (geen getuige)**
Modus voor hoge veiligheid zonder automatische failover	VOLLEDIG	NULL (geen getuige)
Modus voor hoge veiligheid met automatische failover*	VOLLEDIG	AANGESLOTEN

*Als de verbinding met de witness raakt verbroken, raden we u aan WITNESS UIT te zetten totdat de witness-serverinstance beschikbaar is.

**Als een witness aanwezig is in de modus met hoge prestaties, neemt de witness niet deel aan de sessie. Als u de database echter beschikbaar wilt maken, moeten ten minste twee serverexemplaren verbonden blijven. Daarom raden we u aan om de WITNESS-eigenschap op UIT te houden in sessies met hoge prestaties. Zie Quorum: Invloed van een witness op database beschikbaarheid (databasespiegeling) voor meer informatie.

De veiligheidsinstelling en de status van de getuige bekijken

Als u de veiligheidsinstelling en de status van de witness voor een database wilt bekijken, gebruik de sys.database_mirroring catalogusweergave. De relevante kolommen zijn als volgt:

Kenmerk	Columns	Description
Transactieveiligheid	mirroring_safety_level of mirroring_safety_level_desc	Instelling voor transactieveiligheid voor updates in de gespiegelde database, een van: UNKNOWN OFF VOLLEDIG NULL= database is niet online.
Bestaat er een getuige?	mirroring_witness_name	Servernaam van de database mirroring getuige of NULL, wat aangeeft dat er geen getuige bestaat.
Waarnemerstoestand	mirroring_witness_state of mirroring_witness_state_desc	Status van de getuige in de database bij een opgegeven partner: UNKNOWN AANGESLOTEN DISCONNECTED NULL = er bestaat geen witness of de database is niet online.

Voer bijvoorbeeld op de principal- of mirrorserver het volgende in:

SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring  

Zie sys.database_mirroring (Transact-SQL) voor meer informatie over deze catalogusweergave.

Factoren die van invloed zijn op gedrag bij verlies van de principal-server

De volgende tabel bevat een overzicht van het gecombineerde effect van de transactie-veiligheidsinstelling, de status van de database en de status van de witness op het gedrag van een spiegelingssessie bij verlies van de principal server.

Transactieveiligheid	Spiegelingsstatus van gespiegelde database	Witness-toestand	Gedrag wanneer principal verloren gaat
VOLLEDIG	GESYNCHRONISEERD	AANGESLOTEN	Automatische failover vindt plaats.
VOLLEDIG	GESYNCHRONISEERD	DISCONNECTED	Mirror-server stopt; failover is niet mogelijk en de database kan niet beschikbaar worden gesteld.
OFF	ONDERBROKEN OF VERBROKEN	NULL (geen getuige)	De service kan worden geforceerd naar de mirror server (met mogelijk gegevensverlies).
VOLLEDIG	SYNCHRONISEREN OF GESCHORST	NULL (geen getuige)	De service kan afgedwongen worden naar de mirror-server (met mogelijk gegevensverlies).

Gerelateerde taken

• Een databasespiegelingswitness toevoegen of vervangen (SQL Server Management Studio)

• Een databasespiegelingssessie tot stand brengen met behulp van Windows-verificatie (SQL Server Management Studio)

• Een databasespiegelingswitness toevoegen met Windows-verificatie (Transact-SQL)

• De witness verwijderen uit een databasespiegelingssessie (SQL Server)

• Transactieveiligheid wijzigen in een databasespiegelingssessie (Transact-SQL)

Zie ook

Databasespiegeling monitoren (SQL Server)
Databasespiegelingsgetuige