Databasespiegeling en logboekverzending (SQL Server)

Van toepassing op:SQL Server

Een gegeven database kan worden gespiegeld of gelogschipt; het kan ook gelijktijdig worden gespiegeld en gelogschipt. Als u wilt kiezen welke methode u wilt gebruiken, moet u rekening houden met het volgende:

• Hoeveel doelservers hebt u nodig?

  Als u slechts één doeldatabase nodig hebt, is databasespiegeling de aanbevolen oplossing.

  Als u meer dan één doeldatabase nodig hebt, moet u gebruikmaken van log shipping, hetzij alleen of in combinatie met databasespiegeling. Als u deze benaderingen combineert, krijgt u de voordelen van databasespiegeling, samen met de ondersteuning voor meerdere bestemmingen die worden geboden door het verzenden van logboeken.

• Als u het herstellen van logboeken op de doeldatabase moet vertragen (meestal om te beschermen tegen logische fouten), gebruikt u logboekverzending, alleen of met databasespiegeling.

In dit onderwerp worden overwegingen besproken voor het combineren van logboekverzending en databasespiegeling.

Logboekverzending en databasespiegeling combineren

De hoofd-database in een spiegelingsessie kan ook fungeren als de primaire database in een configuratie voor logboekverzending, of andersom, omdat de back-up-share voor logboekverzending intact is. De databasespiegelingssessie wordt uitgevoerd in elke bedrijfsmodus, ongeacht of deze synchroon is (met transactieveiligheid ingesteld op FULL) of asynchroon (waarbij de transactieveiligheid is ingesteld op UIT).

Normaal gesproken wordt bij het combineren van logboekverzending en databasespiegeling de mirroringsessie tot stand gebracht voordat logboekverzending wordt verzonden, hoewel dit niet vereist is. Vervolgens wordt de huidige principal-database geconfigureerd als de primaire logboekverzending (de principal/primaire database), samen met een of meer externe secundaire databases. De gespiegelde database moet ook worden geconfigureerd als de primaire database voor logboekverzending (de mirror/primaire database). De secundaire databases voor logboekverzending moeten zich op verschillende serverexemplaren bevinden dan de principal/primaire server of de mirror/primaire server.

Tijdens een logboekverzendingssessie maken back-uptaken op de primaire database logboekback-ups in een back-upmap. Van daaruit worden de back-ups gekopieerd door de kopieertaken van de secundaire servers. Opdat de back-uptaken en kopieertaken succesvol zijn, moeten ze toegang hebben tot de map voor logverzending. Als u de beschikbaarheid van de primaire server wilt maximaliseren, raden we u aan om de back-upmap op een gedeelde back-uplocatie op een afzonderlijke hostcomputer in te stellen. Zorg ervoor dat alle logboekverzendingsservers, inclusief de mirror/primaire server, toegang hebben tot de gedeelde back-uplocatie (ook wel een back-upshare genoemd).

Als u wilt toestaan dat logboekverzending wordt voortgezet nadat een failover van databasespiegeling is uitgevoerd, moet u ook de mirrorserver configureren als een primaire server, met dezelfde configuratie die u gebruikt voor de primaire database in de principal-database. De gespiegelde database bevindt zich in de herstelmodus, waardoor het niet mogelijk is om het logboek in de gespiegelde database te back-uppen met behulp van de back-uptaken. Dit zorgt ervoor dat de mirror/primaire database geen invloed heeft op de principal/primaire database waarvan de logboekback-ups momenteel worden gekopieerd door secundaire servers. Om ongewenste waarschuwingen te voorkomen, logt de back-uptaak na uitvoering op de gespiegelde/primaire database een bericht in de log_shipping_monitor_history_detail tabel, en retourneert de agenttaak de status geslaagd.

De mirror/primaire database is inactief in de sessie voor het verzenden van logboeken. Als er echter een failover van spiegeling wordt uitgevoerd, komt de voormalige mirrordatabase online als principal-database. Op dat moment wordt die database ook actief als de primaire database voor logboekverzending. De back-uptaken voor de logverzending die eerder geen logboek op die database konden verzenden, beginnen met het verzenden van het logboek. Omgekeerd zorgt een failover ervoor dat de voormalige principal/primaire database de nieuwe mirror/primaire database wordt en in de herstelfase komt, waarna backuptaken op die database stoppen met het maken van logboeken.

Om in de modus voor hoge veiligheid met automatische failover te draaien, wordt de spiegelingssessie geconfigureerd met een extra serverexemplaar dat bekend staat als de witness. Als de principal-database om welke reden dan ook verloren gaat nadat de database is gesynchroniseerd en als de mirror-server en witness nog steeds met elkaar kunnen communiceren, treedt automatische failover op. Een automatische failover zorgt ervoor dat de mirrorserver de hoofdrol op zich neemt en de database online brengt als de belangrijkste database. Als de back-uplocatie voor logboekverzending toegankelijk is voor de nieuwe principal/primaire server, beginnen de back-uptaken logboekback-ups naar die locatie te verzenden. De synchrone modus voor databasespiegeling garandeert dat de logboekketen niet wordt beïnvloed door een failover voor spiegelen en dat alleen geldig logboek wordt hersteld. De secundaire servers blijven logboekback-ups kopiëren zonder te weten dat een ander serverexemplaar de primaire server is geworden.

Wanneer u een lokale logboekverzendingsmonitor gebruikt, zijn er geen speciale overwegingen nodig om dit scenario aan te passen. Zie 'The Impact of Database Mirroring on a Remote Monitoring Instance' verderop in dit onderwerp voor meer informatie over het gebruik van een exemplaar voor externe bewaking met dit scenario.

Overschakelen van de hoofddatabase naar de mirror-database

In de volgende afbeelding ziet u hoe logboekverzending en databasespiegeling samenwerken wanneer spiegeling wordt uitgevoerd in de modus voor hoge veiligheid met automatische failover. In eerste instantie is Server_A zowel de principal-server voor spiegeling als de primaire server voor het verzenden van logboeken. Server_B is de mirrorserver en is ook geconfigureerd als een primaire server, die momenteel inactief is. Server_C en Server_D zijn secundaire servers voor logboekverzending. Om de beschikbaarheid van de sessie voor logboekverzending te maximaliseren, bevindt de back-uplocatie zich op een gedeelde map op een afzonderlijke hostcomputer.

Na een failover van de spiegeling blijft de naam van de primaire server, zoals gedefinieerd op de secundaire server, ongewijzigd. .

De impact van spiegeling van databases op een extern bewakingsexemplaar

Wanneer logboekverzending wordt gebruikt bij een extern bewakingsexemplaar, heeft het combineren van de sessie voor logboekverzending en databasespiegeling invloed op de informatie in de monitortabellen. De informatie over de primaire node is een combinatie van de gegevens die zijn geconfigureerd op de hoofdserver/primaire node en de monitor die op elke secundaire server is geconfigureerd.

Als u een externe monitor zo naadloos mogelijk wilt bewaken, raden we u aan de oorspronkelijke primaire naam op te geven bij het configureren van de primaire op de secundaire locatie. Deze aanpak vereenvoudigt ook het wijzigen van de configuratie voor logboekverzending vanuit Microsoft SQL Server Agent. Zie Logboekverzending bewaken (Transact-SQL)voor meer informatie over bewaking.

Spiegeling en logboekverzending samen instellen

Als u databasespiegeling en logboekverzending samen wilt instellen, zijn de volgende stappen vereist:

1. Herstel back-ups van de hoofd/primaire database met NORECOVERY op een ander serverexemplaar om later te worden gebruikt als een spiegelingsdatabase voor de hoofd/primaire database. Zie Een mirrordatabase voorbereiden voor spiegeling (SQL Server)voor meer informatie.

2. Databasespiegeling instellen. Zie Een databasespiegelingssessie tot stand brengen met behulp van Windows-verificatie (SQL Server Management Studio) of het instellen van databasespiegeling (SQL Server) voor meer informatie.

3. Herstel de back-ups van de hoofd/primaire database naar andere serverinstantiaties, zodat ze later kunnen worden gebruikt als secundaire databases voor logshipping voor de primaire database.

4. Stel logboekverzending in voor de principal-database als de primaire database voor een of meer secundaire databases.

   U moet een enkele gedeelde map instellen als de back-upmap (een back-upgedeelde map). Dit zorgt ervoor dat na het schakelen tussen de rol tussen de principal- en mirrorservers, blijven backup-taken naar dezelfde map schrijven als voorheen. Een best practice is ervoor te zorgen dat deze share zich op een andere fysieke server bevindt dan de servers waarop de databases worden gehost die betrokken zijn bij spiegeling en logboekverzending.

   Zie Logboekverzending configureren (SQL Server) voor meer informatie.

5. Handmatig de hoofdserver overdragen naar de spiegelserver.

   Een handmatige failover uitvoeren:

   • Handmatig een failover uitvoeren voor een databasespiegelingssessie (SQL Server Management Studio)

   • Handmatig een failover uitvoeren voor een databasespiegelingssessie (Transact-SQL)

6. Stel logboekverzending in op de nieuwe principal (voorheen mirror) als de primaire database.

   Belangrijk

   Voer geen installatie uit vanaf een secundaire server.

   U moet dezelfde back-upshare gebruiken die u in stap 4 hebt gebruikt.

   De transactielogboekverzendingsinterface in SQL Server Management Studio ondersteunt slechts één primaire database per logboekverzendingsconfiguratie. Daarom moet u opgeslagen procedures gebruiken om de nieuwe principal in te stellen als primair.

7. Voer een andere handmatige failover uit om een failback uit te voeren naar de oorspronkelijke principal.