Database Mirroring ist eine wichtige neue Technologie zum Erreichen von Hochverfügbarkeit in SQL Server 2008. Die Datenbankspiegelung arbeitet auf Datenbankebene und wird auf Datenbankbasis konfiguriert. Das primäre Ziel der Datenbankspiegelung ist es, die Datenverfügbarkeit zu erhöhen und ein Failover zu ermöglichen, falls ein Server, der die Datenbank hostet, nicht mehr verfügbar ist. Mit der Datenbankspiegelung haben wir jetzt also 4 Hochverfügbarkeitsfunktionen in SQL Server 2005:

(1) Clustering
(2) Log-Versand
(3) Replikation (transaktional) und
(4) Mirroring.

Ich kann sagen, dass Database Mirroring Log Shipping mit automatischem Failover pro Datenbank & Clustering auf Datenbankebene ohne einen Single Point of Failure ohne Shared Disk ist.

Für eine erfolgreiche Implementierung der Datenbankspiegelung müssen Sie drei Instanzen von SQL Server 2005 installiert haben, entweder Standard oder Enterprise Edition für alle Instanzen. Sie müssen das Modell “Vollständige Wiederherstellung” für jede Datenbank angeben, die an der Datenbankspiegelung teilnehmen soll. Viele Anwendungen nutzen mehrere Datenbanken auf einem einzigen Server. Eine Anwendung kann auf mehrere Datenbanken verweisen, oder vielleicht nutzen viele Anwendungen alle mehrere Datenbanken. Die Datenbankspiegelung arbeitet jedoch jeweils mit einer einzigen Datenbank. Sie müssen dies berücksichtigen, wenn Sie die Spiegelung in Ihre Datenbankarchitektur integrieren.

Database Mirroring besteht aus zwei obligatorischen Rollen und einer dritten, optionalen Rolle
– Principal Role
– Mirror Role
– Witness Server – dritte und optionale Rolle, um automatische Fehlererkennung und Failover zu implementieren. SQL Server 2005

Die Express und Workgroup Edition ist ein guter Kandidat, da sie nur die Rolle des Zeugen unterstützt.
Jeder der beteiligten Server speichert einige Metadaten über die Sitzung und den aktuellen Zustand der Datenbanken. Sie können die Sitzung auf dem Haupt- oder Spiegelserver überprüfen, indem Sie die Katalogansicht sys.database_mirroring abfragen.

Bevor Sie die Spiegelungssitzung starten, müssen Sie jede Mirror-Datenbank initialisieren, um sicherzustellen, dass sie mit der Hauptdatenbank synchronisiert ist. Das bedeutet, dass Sie die letzte bekannte Vollsicherung der Principal-Datenbank durchführen müssen (einschließlich, falls vorhanden, Sicherungen der Transaktionsprotokolle, die nach dieser Sicherung durchgeführt wurden) und diese auf dem Mirror-Server mit der Option NO RECOVERY wiederherstellen. Dadurch wird die Mirror-Datenbank in einen Wiederherstellungszustand versetzt und es werden keine Verbindungen zugelassen.

Sie müssen Logins einschließlich SQL Agent-Aufträgen und -Warnungen, SQL Server Integration Services-Packages, Support-Datenbanken, verknüpfte Serverdefinitionen, Sicherungsgeräte, Wartungspläne, SQL Mail- oder Datenbank-Mail-Einstellungen und möglicherweise Einstellungen für den Distributed Transaction Coordinator separat übertragen, um nur einige zu nennen. SQL Server Integration Services verfügt über eine Aufgabe “Logins übertragen”, mit der Sie Logins und Passwörter von einem Server auf einen anderen kopieren können, aber möglicherweise müssen Sie noch Datenbankberechtigungen für diese Logins festlegen. Wenn Sie Anmeldungen auf einen Server in einer anderen Domäne übertragen, stimmen die SIDs möglicherweise nicht überein und Sie müssen sie abgleichen.
Das Datenbank-Mirroring wird in SQL Server Management Studio (SSMS) auf der Seite Datenbankeigenschaften, Mirroring konfiguriert. Die Konnektivität zwischen Principal-, Mirror- und Witness-Servern verwendet Endpunkte, eine neue Funktion, die in SQL Server 2005 eingeführt wurde. Database Mirroring verwendet TCP-Endpunkte (mit einem TCP-Standardport von 5022) für die Kommunikation mit voll qualifizierten Computernamen und wird mit einer Nutzlast von DATABASE_MIRRORING erstellt. Für jede SQL Server-Instanz wird nur ein Endpunkt erstellt.
Sie können die Standard-TCP-Ports aus Sicherheitsgründen auch ändern. Wenn sich Ihr Haupt-, Spiegel- und Zeugenserver in der gleichen Domäne befinden, verwenden Sie die fensterbasierte Authentifizierung. Wenn sie sich nicht in vertrauenswürdigen Domänen befinden, dann verwenden Sie die zertifikatsbasierte Authentifizierung. Sie können die Kommunikation zwischen den Endpunkten auch verschlüsseln, um die Sicherheit zu erhöhen.
Der einfachste Weg, Endpunkte einzurichten, ist die Verwendung des Sicherheitsassistenten für die Datenbankspiegelung, den Sie aufrufen können, indem Sie auf der Seite “Spiegelung” des Dialogfelds “Datenbankeigenschaften” auf die Schaltfläche “Sicherheit konfigurieren” klicken (wie Sie einen TCP-Endpunkt erstellen, erfahren Sie in Books Online).

Datenbank-Spiegelung: SQL Server 2008
Datenbank-Spiegelung: SQL Server 2008

Database Mirroring kann für drei verschiedene Betriebsarten konfiguriert werden:

1. Hochverfügbarkeits-Betriebsmodus – Dieser Modus bietet eine dauerhafte, synchrone Übertragung von Daten zwischen Principal und Mirror, einschließlich automatischer Fehlererkennung und Failover. Bei diesem Modus gibt es einen Leistungs-Overhead, da eine Transaktion erst dann als festgeschrieben gilt, wenn SQL Server sie erfolgreich in das Transaktionsprotokoll sowohl auf der Haupt- als auch auf der Spiegeldatenbank übertragen hat. Und je größer der Abstand zwischen dem Principal und dem Mirror ist, desto größer ist auch die Leistungsauswirkung. Es gibt einen kontinuierlichen Ping-Prozess zwischen allen drei, um einen Failover zu erkennen. Wenn der Witness-Server vom Mirror aus nicht sichtbar ist, müssen Sie entweder den Betriebsmodus für die Datenbank-Spiegelungssitzung neu konfigurieren oder den Witness abschalten. Alternativ können Sie eine Datenbankspiegelungssitzung am Mirror im Hochverfügbarkeitsmodus manuell ausfallen lassen, indem Sie den folgenden Befehl am Principal eingeben. Sie können denselben Befehl auch ausführen, wenn Sie den Principal zur Wartung herunterfahren müssen.
ALTER DATABASE SET PARTNER FAILOVER

2. High Performance Operating Mode – In dieser Konfiguration benötigen Sie keinen WITNESS-Server und der Mirror-Server fungiert als WARM-Standby und unterstützt keine automatische Fehlererkennung oder Failover. Es findet eine asynchrone Datenübertragung zwischen Principal und Mirror statt. Dieser Modus bietet eine bessere Leistung und Sie können eine geografische Streuung zwischen dem Principal und dem Mirror haben. Dieser Modus erhöht die Latenz und kann bei einem Ausfall der primären Datenbank zu einem größeren Datenverlust führen.

3. High Protection Operating Mode – Dieser Modus entspricht dem Hochverfügbarkeitsmodus, außer dass das Failover manuell erfolgt und Sie den Mirror manuell zum Principal ernennen müssen. Die Datenübertragung erfolgt synchron. Dies ist nicht der empfohlene Modus und kann nur in dem Fall verwendet werden, wenn Sie einen vorhandenen Witness-Server ersetzen müssen. Nach dem Ersetzen oder Wiederherstellen des Witness-Servers sollten Sie den Betriebsmodus wieder auf Hochverfügbarkeit ändern.

Datenbank-Spiegelung Betriebsmodi:

Betriebsart Transaktionssicherheit Übertragungsmechanismus Quorum erforderlich Witness Server Failover-Typ
Hochverfügbarkeit Vollsynchron Ja Ja Automatisch oder manuell
Hochsicherheit Vollsynchron Ja Nein Nur manuell
Hochleistung Aus Asynchron Nein -NA- Nur erzwungen

Client-Verbindungen bei der Datenbankspiegelung :

Wenn Sie in SQL Server 2005 eine Verbindung zu einer Datenbank herstellen, die mit ADO.NET oder dem SQL Native Client gespiegelt wird, kann Ihre Anwendung die Fähigkeit der Treiber nutzen, Verbindungen automatisch umzuleiten, wenn ein Datenbankspiegelungs-Failover auftritt. Sie müssen den anfänglichen Hauptserver und die Datenbank in der Verbindungszeichenfolge angeben, und optional den Failover-Partner-Server.

Es gibt viele Möglichkeiten, die Verbindungszeichenfolge zu schreiben, aber hier ist ein Beispiel, das Server A als Hauptserver, Server B als Spiegelserver und AdventureWorks als Datenbankname angibt:
“Data Source=A;Failover Partner=B;Initial Catalog=;Integrated
Security=True;”
Der Failover-Partner in der Verbindungszeichenfolge wird als alternativer Servername verwendet, wenn die Verbindung zum anfänglichen Hauptserver fehlschlägt. Wenn die Verbindung zum anfänglichen Hauptserver erfolgreich ist, wird der Failover-Partnername nicht verwendet, aber der Treiber speichert den Failover-Partnernamen, den er vom Hauptserver abruft, im clientseitigen Cache.
Der große Vorteil der Verwendung der in ADO.NET und dem SQL Native Client-Treiber integrierten Datenbankspiegelungsunterstützung besteht darin, dass Sie die Anwendung nicht neu codieren oder speziellen Code in die Anwendung einfügen müssen, um eine Datenbankspiegelungsausfallsicherung zu handhaben.

Wenn Sie die automatische Umleitung des ADO.NET- oder SQL Native-Clients nicht verwenden, können Sie andere Techniken einsetzen, die Ihrer Anwendung einen Failover ermöglichen. Sie könnten z. B. Network Load Balancing verwenden, um Verbindungen manuell von einem Server zu einem anderen umzuleiten, während sich der Client nur mit einem virtuellen Servernamen verbindet. Sie könnten auch Ihren eigenen Umleitungscode und Ihre eigene Wiederholungslogik schreiben.

Wenn die Sicherheit FULL ist, benötigt eine Datenbankspiegelungssitzung ein Quorum, um eine Datenbank in Betrieb zu halten. Ein Quorum ist die minimale Beziehung zwischen allen verbundenen Servern, die für eine synchrone Datenbankspiegelungssitzung erforderlich ist. Da mindestens zwei Server für ein Quorum erforderlich sind, muss der Hauptserver bei FULL ein Quorum mit mindestens einem anderen Server bilden, um die Datenbank in Betrieb zu halten (weitere Informationen finden Sie unter dem Thema “Quorum in Datenbankspiegelungssitzungen” in SQL Server-Online).

Einige Tipps auf Hardware-Ebene zur Konfiguration des Servers für Principal & Mirror :
Auf der Ebene des physischen Servers sollten Sie sicherstellen, dass der Standby-Server die gleiche oder eine möglichst ähnliche physische CPU- und Speicherkonfiguration hat, da sonst der Standby-Server nach einem Failover zu wenig Leistung bringt. Möglicherweise haben Sie auch unterstützende Anwendungen, Monitore oder andere ausführbare Dateien, die die Datenbankanwendungen unterstützen und auf dem Spiegelserver konfiguriert werden müssen.
Auf der SQL Server-Ebene sollten Sie auch sicherstellen, dass der Standby-Server über die gleichen SQL Server-Konfigurationen verfügt (z. B. AWE, maximaler Grad der Parallelität). Am grundlegendsten werden jedoch die Logins und deren Berechtigungen sein.
Sie können ein manuelles Failover am Mirror nur initiieren, wenn der Principal nicht erreichbar ist und der Witness entweder ausgeschaltet oder mit dem Mirror verbunden ist. Geben Sie diesen Befehl an der Spiegeldatenbank aus.

ALTER DATABASE SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Das schlimmste Szenario ist, wenn der Hauptserver abstürzt oder beschädigt wird. Dann müssen Sie die Datenbankspiegelung entfernen und die gesamte Umgebung neu initialisieren. Sie können die Spiegelung entfernen, indem Sie mit der rechten Maustaste auf den Hauptserver klicken, Eigenschaften wählen, auf der Spiegelungsseite auf Spiegelung stoppen klicken oder diesen Befehl entweder auf dem Hauptserver oder dem Spiegel ausführen.
ALTER DATABASE SET PARTNER OFF

Fazit:

Die Datenbankspiegelung ist eine neue SQL Server 2005-Technologie, die Hochverfügbarkeits- und Hochleistungslösungen für die Datenbankredundanz bieten kann. Bei der Datenbankspiegelung werden Transaktionsprotokollsätze direkt von einem Principal an eine Spiegeldatenbank gesendet, wenn der Transaktionsprotokollpuffer des Principals auf die Festplatte geschrieben wird. Mit dieser Technik kann die Spiegeldatenbank nahezu auf dem gleichen Stand gehalten werden wie der Principal, und zwar ohne Verlust von festgeschriebenen Daten. Im Betriebsmodus “Hochverfügbarkeit” wird bei einem Ausfall des Principals der Mirror-Server automatisch zum neuen Principal und stellt seine Datenbank wieder her. Die Datenbankspiegelung wird zu einer wichtigen neuen Option in der Reihe der von SQL Server 2005 unterstützten Hochverfügbarkeitstechnologien.
Funktionen der Datenbankspiegelung in den verschiedenen SQL Server 2005-Editionen