Failover und Wiederherstellen von gespiegelten Datenbanken in einer einzelnen Farm

In diesem Artikel werden das Failover und die Wiederherstellung einer Microsoft Office SharePoint Server 2007-Farm beschrieben, die entsprechend den Verfahren im Artikel Konfigurieren der Verfügbarkeit in einer einzelnen Farm mithilfe von SQL Server-Datenbankspiegelung für die Verwendung der Datenbankspiegelung mit hoher Verfügbarkeit konfiguriert wurde.

Dieser Artikel enthält die folgenden Abschnitte:

• Automatischer Failoverprozess für eine gespiegelte Datenbank

• Manueller Failoverprozess für eine gespiegelte Datenbank

• Überwachung und Warnung beim Spiegelungsfailover

• Auftrag: Failover aller verbleibenden Datenbanken

• Auftrag: Aktualisieren der Verbindungsaliase

• Failback

• Zusammenfassung

Beim Failover einer Microsoft Office SharePoint Server 2007-Umgebung, in der gespiegelte Datenbanken ausgeführt werden, muss der folgende Prozess ablaufen:

• Von mindestens einer Datenbank auf dem Prinzipalserver erfolgt ein Failover zur gespiegelten Datenbank, entweder automatisch oder manuell.

• Für alle anderen Datenbanken auf dem Prinzipalserver wird ein Failover erzwungen.

  Es wird empfohlen, Microsoft SQL Server 2005-Warnungen und -Aufträge zu verwenden, um die Spiegelung zu überwachen und ein Failover aller Datenbanken zu erzwingen.

• Verbindungsaliase auf allen Front-End-Webservern und Computern, die auf Datenbanken verweisen, werden zurückgesetzt, damit sie auf den Spiegelserver verweisen.

Automatischer Failoverprozess für eine gespiegelte Datenbank

Ein automatisches Failover erfolgt, wenn der Prinzipalserver die Verbindung mit dem Rest der Datenbankspiegelungskonfiguration verloren hat, die Kommunikation zwischen Spiegel- und Zeugenserver aber aufrechterhalten bleibt.

Wenn ein automatisches Failover ausgelöst wird, läuft der folgende Prozess ab:

1. Wenn der Prinzipalserver noch ausgeführt wird, wird der Status der Prinzipaldatenbank in Getrennt geändert und werden alle Clients von der Prinzipaldatenbank getrennt.

2. Der Zeugen- und der Spiegelserver registrieren, dass der Prinzipalserver nicht verfügbar ist.

3. Wenn in der Wiederholungswarteschlange Protokolle anstehen, wird vom Spiegelserver ein Rollforward für die Spiegeldatenbank ausgeführt. Der Zeitaufwand für das Anwenden des Protokolls hängt von der Geschwindigkeit des Systems, der aktuellen Arbeitsauslastung sowie der Größe der Protokolle in der Wiederholungswarteschlange ab.

4. Wenn der bisherige Prinzipalserver der Sitzung wieder beitritt, erkennt er, dass der Failoverpartner jetzt die Prinzipalrolle übernommen hat. Der bisherige Prinzipalserver übernimmt die Rolle des Spiegelservers, und die bisherige Prinzipaldatenbank wird zur Spiegeldatenbank. Der neue Spiegelserver synchronisiert die neue Spiegeldatenbank so schnell wie möglich mit der Prinzipaldatenbank. Sobald die Datenbanken vom neuen Spiegelserver erneut synchronisiert wurden, ist wieder ein Failover möglich, allerdings in umgekehrter Richtung.

Eine ausführliche Beschreibung des automatischen Failovers finden Sie unter Automatisches Failover (https://go.microsoft.com/fwlink/?linkid=83690&clcid=0x407).

Manueller Failoverprozess für eine gespiegelte Datenbank

Ein manuelles Failover erfolgt normalerweise dann, wenn sowohl der Prinzipal- als auch der Spiegelserver weiterhin ausgeführt werden. Der Administrator trifft bewusst die Entscheidung, die aktive Datenbank vom Prinzipal auf den Spiegel umzustellen.

Während eines manuellen Failovers läuft der folgende Prozess ab:

1. Der Administrator stellt eine Verbindung mit dem Prinzipalserver her und gibt für jede Datenbank die folgenden Transact-SQL-Befehle aus:

   USE master;
   ALTER DATABASE <database_name> SET PARTNER FAILOVER; -- where database_name is the mirrored database. 
   

   Mit dieser Anweisung wird ein sofortiger Übergang des Spiegelserver in die Prinzipalrolle initiiert.

2. Auf dem bisherigen Prinzipalserver werden Clients von der Datenbank getrennt und nicht abgeschlossene Transaktionen rückgängig gemacht.

Wenn Sie ein manuelles Failover in einer Installation für automatisches Failover mit einem Zeugenserver ausführen, tauschen der Prinzipalserver und der Spiegelserver automatisch die Rollen.

Überwachung und Warnung beim Spiegelungsfailover

Verwenden Sie SQL Server-Warnungen zum Überwachen der Spiegelung, und führen Sie Aufträge aus, um ein Failover zu erzwingen. Die Aufträge und Warnungen sollten auf den Prinzipal- und Spiegelinstanzen von SQL Server gleichermaßen verwendet werden.

Warnung: Erkennen eines einzelnen Datenbankwechsels vom Prinzipal zum Spiegel

In der Warnung wird ein Transact-SQL-Befehl verwendet, um zu erkennen, ob Datenbanken zur entsprechenden Spiegeldatenbank gewechselt haben.

SELECT * FROM Database_MIRRORING_STATE_CHANGE 
WHERE State=8 AND (databasename='Central Administration' OR databasename='Configuration' 
ORdatabasename='SSP' 
OR databasename=’SSP Content' 
OR databasename='SSP Search' 
OR databasename='WSS Search' 
OR databasename='Content_<port>' )

Auftrag: Failover aller verbleibenden Datenbanken

Führen Sie nach der Erkennungswarnung einen Auftrag aus, um ein Failover aller Datenbanken zu den entsprechenden Spiegeldatenbanken vorzunehmen.

Das folgende Beispiel zeigt ein Transact-SQL-Skript, das Sie in einem Auftrag verwenden können, um ein Failover aller gespiegelten Datenbanken auszuführen:

USE master;
DECLARE i CURSOR
READ_ONLY
FOR 
SELECT name FROM sys.databases WHERE database_id IN
(SELECT database_id FROM sys.database_mirroring WHERE mirroring_state=4)

DECLARE @name varchar(255)
DECLARE @cmd varchar(1000)
OPEN i

FETCH NEXT FROM i INTO @name
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
set @cmd = 'ALTER Database [' + @name + '] SET PARTNER FAILOVER;'
exec (@cmd)

DECLARE @message varchar(100)
SELECT @message = 'Failover for : ' + @name
PRINT @message
END
FETCH NEXT FROM i INTO @name
END

CLOSE i
DEALLOCATE i
GO

Auftrag: Aktualisieren der Verbindungsaliase

Nach dem Failover muss der Datenbankservername, der dem SQL Server-Verbindungsalias zugeordnet ist, auf allen Computern mit Microsoft Office SharePoint Server 2007 vom Prinzipalserver in den Spiegelserver geändert werden.

Erstellen Sie einen SQL Server-Auftrag, der nach Abschluss des Failovers ausgeführt wird. Führen Sie in dem Auftrag einen Befehl aus, um die Registrierungseinstellung für den Aliaswert in den Spiegel zu ändern:

\Registry\Machine\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
<alias> = REG_SZ DBMSSOCN,DBMirror

Ein Beispiel dafür, wie Sie diesen Auftrag erstellen, finden Sie unter Fallstudie zu hoher Verfügbarkeit für SharePoint mithilfe von Datenbankspiegelung (Whitepaper).

Failback

Ein Failback der Datenbanken zum Prinzipalserver ist nur manuell möglich. Sie können die gleichen SQL Server-Aufträge verwenden, um das Failback und das Zurücksetzen der SQL Server-Clientverbindungsaliase zu automatisieren. Sie müssen die Werte in den Aufträgen ändern, bevor Sie diese ausführen.

Zusammenfassung

Nachdem Sie die Spiegelung in einer Umgebung mit einer einzelnen Farm konfiguriert haben, sollten Sie den Prozess, die Warnungen, Aufträge und Skripts für Failover und Failback testen. Beim Failover einer einzelnen Datenbank sollten Sie Skripts schreiben, die zuerst versuchen, ein Failback zum Prinzipalserver auszuführen, bevor für alle anderen Datenbanken ein Failover zum Spiegelserver erzwungen wird.

Herunterladen dieses Buchs

Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:

• Planen und Konfigurieren der Verfügbarkeit in einer Office SharePoint Server 2007-Farm (in englischer Sprache)

  Die vollständige Liste der verfügbaren Bücher finden Sie unter Bücher zum Herunterladen für Office SharePoint Server 2007.