Microsoft SQL Server - Database Mirroring (Funktion und Konfiguration)
Database Mirroring (Datenbankspiegelung) ist eine Technologie, die von Microsoft eingeführt wurde, um bei dem Ausfall einer SQL Server Instanz oder einer SQL Server Datenbank in sehr kurzer Zeit und möglichst ohne Datenverlust eine Ersatz-Datenbank bereit zu stellen.
Wir möchten die Technik, die hinter Database Mirroring steckt und wie Sie diese Datenbank-Technologie in Ihrer SQL Server Instanz einrichten können, etwas genauer beschreiben.
Was steckt hinter dem Begriff Database-Mirroring ?
In allen SQL Server-Datenbanken werden Änderungen in Transaktionsprotokollen festgehalten, bevor diese tatsächlich an den Daten vorgenommen werden. Die Transaktionsprotokolleinträge werden im Protokollpuffer der Datenbank im Speicher festgehalten und dann so schnell wie möglich auf die Festplatte geschrieben.
Beim Database Mirroring sendet eine SQL Server Instanz fortlaufend Transaktionseinträge an eine zweite SQL Server Instanz. Die sendende SQL Server Instanz ist der Principal-Server und die empfangende SQL Server Instanz der Mirror-Server.
Wenn der Mirror-Server die Transaktionseinträge erhält, speichert er diese zuerst im Datenbankprotokollpuffer und schreibt sie dann so schnell wie möglich auf die Festplatte. So werden die Datenbankänderungen in der Principal-Datenbank in der Mirror-Datenbank dupliziert. Principal-Server und Mirror-Server müssen eigenständige SQL Server - Instanzen sein und betrachten sich gegenseitig als Partner beim Database Mirroring. Ein Partnerserver kann für eine Database Mirroring-Session als Principal-Server und als Mirror-Server für eine andere Database Mirroring-Session arbeiten. Bei dem Ausfall des Prinizipal-Server kann ein automatischer Failover auf den Mirror-Server durchgeführt werden. Eine Clientanwendung, die den SQL Server Native Client für die Datenbank-Verbindung benutzt, kann so konfiguriert werden, dass diese bei einem Failover automatisch mit dem Mirror-Server weiter arbeitet.
Welche Rolle spielt der Witness-Server ?
Zusätzlich zu dem Principal und Mirror Server kann es einen optionalen dritten Server geben: den Witness-Server (Zeugen-Server). Seine Aufgabe ist es, einen automatischen Failover zu ermöglichen.Ein automatisches Failover bedeutet, dass bei einem Ausfall des Principal-Servers der Principal- und Mirror Server automatisch die Rollen tauschen. Dies kann nur mit dem Einsatz eines Witness-Servers erfolgen und beinhaltet folgende Schritte:
Der Principal Server fällt aus und/oder kann von dem Mirror Server nicht mehr erreicht werden. Der Mirror-Server fragt beim Witness Server an, ob dieser den Principal Server auch nicht mehr erreichen kann. Wenn der Witness-Server dem Mirror-Server bestätigt, dass dieser den Principal Server auch nicht erreichen kann übernimmt der Mirror Server automatisch die Rolle vom Principal-Server. Für den Witness-Server müssen Sie keine zusätzliche SQL Server Lizenz erwerben da für diese Rolle auch eine SQL Server Express - Instanz verwendet werden kann.
Folgende Punkte sollten beim Einsatz von Database Mirroring berücksichtigt werden:
- Es werden 2 SQL Server Instanzen mit derselben SQL Server Version benötigt.
- Die Principal-Datenbank muss sich im Wiederherstellungsmodus FULL befinden.
- Die Mirror-Datenbank muss über die Wiederherstellung eines Backups der Principal-Datenbank mit NORECOVERY erzeugt werden. Anschliessend erfolgt die Wiederherstellung in der Reihenfolge der Sicherungen des Transaktionsprotokolls des Principal-Servers.
- Die Mirror-Datenbank muss den gleichen Namen haben wie die Principal-Datenbank
- Da sich eine Mirror-Datenbank in einem wiederhergestellten Zustand befindet, kann nicht direkt auf sie zugegriffen werden. Sie können Datenbanksnapshots auf dem Mirror erstellen, um die Datenbank indirekt zu lesen.
Welche Ausfallsicherheit bietet Database Mirrorring ?
Es gibt drei mögliche Betriebsmodi beim Database Mirroring, die die Ausfallsicherheit und den möglichen Datenverluste mit beeinflussen:
- Mit Transaktionssicherheit (Synchron) und automatischen Failover - High Protection mode
- Mit Transaktionssicherheit (Synchron) ohne automatischen Failover - High Security mode
- Ohne Transaktionssicherheit (Asynchron)
Mit Transaktionssicherheit (Synchron) und automatischen Failover - High Protection mode
Wenn Transaktionssicherheit gewährleistet werden soll, heißt dies, dass der Mirror-Server Transaktionen vom Principal erhält und der Principal-Server wartet bis der Mirror-Server eine Bestätigung zur Übernahme der Transaktionen zurückgesendet hat, bevor die nächsten Transaktionen erzeugt werden. In diesem Fall sind die Mirror-Datenbank und die Principal-Datenbank zu jedem Zeitpunkt synchron.
Der Betriebsmodus high-protection-mode bietet die bestmögliche Datenbankverfügbarkeit und eine hohe Ausfall-Sicherheit mit einem automatischen Failover auf die Mirror-Datenbank. Er erfordert, dass Database-Mirroring mit Transaktionssicherheit konfiguriert und ein Witness-Server eingerichtet wird.
Dieser Modus wird am besten dann genutzt, wenn Sie über schnelle und zuverlässige Kommunikationspfade zwischen den Servern verfügen und einen automatischen Failover für eine einzelne Datenbank benötigen. Mit der Einstellung für synchrone Transaktionen muss der Principal auf die Antworten des Mirrors warten. Daher ist die Leistung des Principal-Servers von der des Mirror-Servers abhängig.
Der Modus high-protection-mode überwacht sich selbst. Wenn die Principal-Datenbank plötzlich nicht mehr zur Verfügung steht oder der Server ausfällt, dann bilden Mirror und Witness ein Quorum und der Mirror-Server führt ein automatisches Failover durch. An diesem Punkt ändert der Mirror-Server seine Rolle und wird zum neuen Principal. Der Mirror-Server ist schnell verfügbar, da er alle Transaktionen des Principals bereits wiederholt hat.
Wenn der Mirror Server ausfällt, bleiben der Principal und Witness Server weiter aktiv. Voraussetzung dafür ist eine Verbindung zwischen dem Principal Server und dem Witness Server. Ist dies nicht der Fall versetzt der Principal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann oder das Database Mirroring deaktiviert wird.
Mit Transaktionssicherheit (synchron) ohne automatischen Failover - High Security mode
Der High Security Mode wird wie der High Protection Mode, aber ohne eine Witness-Instanz ausgeführt und ermöglicht somit kein automatisches Failover.
Wenn die Partner verbunden sind, wird das manuelle Failover unterstützt. Wenn die Mirror-Instanz ausfällt, bleibt die Principal-Instanz in Betrieb und wird ungeschützt ausgeführt (d. h. ohne die Spiegelung der Daten). Wenn der Principal-Server ausfällt, kann der Dienst auf dem Mirror-Server nur dann erzwungen werden, wenn keine Verbindung mehr zum Principal Server besteht.
Ohne Transaktionssicherheit (Asynchron)
Wenn Transaktionssicherheit nicht gewährleistet werden muss, heißt dies, dass der Mirror-Server zwar laufend Transaktionen vom Principal erhält, aber der Principal nicht wartet bis der Mirror eine Bestätigung zur Übernahme der Transaktionen zurückgesendet hat bevor die nächsten Transaktionen erzeugt werden. In diesem Fall sind die Mirror-Datenbank und die Principal-Datenbank nicht zu jedem Zeitpunkt synchron.
In diesem Betriebs-Modus ist kein automatischer Failover möglich und kann auch kein manueller Failover aktiviert werden. Der einzige zugelassene Failover-Typ ist der erzwungene Failover.
Der erzwungene Failover ist nur möglich, wenn keine Verbindung mehr zum Principal Server besteht und sorgt für eine sofortige Wiederherstellung der gespiegelten Datenbank. Dies kann zu einem potenziellen Datenverlust führen (wenn Transaktionen vom Principal-Server noch nicht vom Mirror-Server empfangen wurden). Dieser Modus ist am besten für Transaktionen über lange Distanzen (zum Beispiel bei Remotestandorten) oder zur Überwachung sehr aktiver Datenbanken geeignet.
Dieses Szenario wird auch high-Performance-Scenario genannt, da es schnelle Schreib-Operationen auf dem Principal-Server bei geringerer Ausfall-Sicherheit bedeutet.
Es sollte in diesem Szenario kein Witness Server eingerichtet werden, da dieser aus den folgenden Gründen mehr Probleme als Nutzen bringt
Wenn der Mirror Server ausfällt, muss der Principal Server noch mit dem Witness Server verbunden sein. Ist dies nicht der Fall versetzt der Principal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann.
Wenn der Principal Server ausfällt, kann ein erzwungener Failover nur ausgeführt werden, wenn der Mirror Server eine Verbindung zum Witness Server besitzt.
Hinweis
Der asynchrone Modus steht nur in der Enterprise und Developer Edition zur Verfügung und kann über das SQL Server Management Studio oder mit dem Alter Database-Befehl „Alter Database Set SAFETY OFF;“ auf der SQL Server Instanz der Principal-Datenbank gesetzt werden.
Was passiert beim "Rollentausch" auf dem Principal- und Mirror-Server ?
Die Rollen-Übernahme des Mirror-Servers zum Principal-Server kann auf verschiedenen Wegen erfolgen:
- Automatisches Failover
- Manuelles Failover
- Erzwungendes Failover
Automatisches Failover
Die Möglichkeit der automatischen Rollen-Übernahme im Falle eines Ausfalls des Principal-Servers besteht nur, wenn für die Spiegelung ein Witness-Server („Zeuge“) eingesetzt wird und die Datenbank Spiegelung mit Transaktionssicherheit ausgeführt wird.
Der Mirror- und der Witness-Server kontaktieren parallel den Principal-Server um festzustellen, ob der physikalische Server, die Server-Instanz und die Datenbank des Principals erreichbar sind. Wenn der Principal-Server vom Mirror-Server nicht mehr kontaktiert werden kann, vergewissert sich dieser beim Witness-Server, dass auch dieser den Principal-Server nicht mehr erreichen kann.
Wenn dies der Fall ist, wird der Mirror-Server zum Principal-Server und informiert den Witness-Server über den Rollen-Tausch.
Sobald der „alte“ Principal-Server wieder online ist, wird dieser vom Witness-Server über den Rollentausch informiert, übernimmt die Rolle des Mirror-Servers und erhält vom neuen Principal-Server die noch fehlenden Transaktions-Logs.
Manuelles Failover
Ein manuelles Failover wird eingesetzt, wenn der Principal-Server und der Mirror-Server (z. Bsp. aus Performancegründen oder zur Durchführung eines SQL Server Updates) ihre Rollen tauschen sollen ohne dass ein physikalisches Problem die Ursache ist.
Unter der Voraussetzung, daß die Datenbank-Spiegelung mit Transaktionssicherheit ausgeführt wird, kann dieser Prozeß ohne Datenverlust durchgeführt werden.
Erzwungendes Failover
Diese Art des Rollen-Tausches wird nur eingesetzt, wenn der Principal-Server ausfällt und nicht mehr vom Mirror Server erreicht werden kann und der asynchrone Betriebsmodi ohne den Einsatz eines Witness-Servers gewählt wurde.
In diesem Fall kann kein automatischer Failover oder manuelles Failover erfolgen und können durch Verlust von Transaktions-Logs auch Daten verloren gehen.
Wie schnell können Principal- und Mirror Datenbank die Rollen tauschen ?
Der Rollentausch zwischen Principal- und Mirror Datenbank kann beim Database Mirroring in sehr kurzer Zeit und beim automatischen Failover ohne den Verlust von Daten erfolgen und benötigt keine properitäre Hardware.
Was passiert, wenn der Witness Server nicht mehr erreichbar ist ?
Der Witness- Server wird primär für die Möglichkeit eines automatischen Failover benötigt, wenn der Principal-Server ausfällt. Wenn der Witness-Server ausfällt, können folgende Szenarien entstehen:
- Wenn nur der Witness Server ausfällt und der Principal- und Mirror Server noch miteinander verbunden sind, wird die Datenbank-Spiegelung ohne automatisches Failover weiter ausgeführt.
- Wenn der Mirror Server ausfällt, muss der Principal Server noch mit dem Witness Server verbunden sein. Fällt auch der Witness Server aus versetzt der Principal Server seine Datenbank so lange in den Offline Modus bis er entweder mit dem Mirror Server oder dem Witness Server eine Verbindung herstellen kann oder die Datenbank-Spiegelung deaktiviert wird.
- Wenn der Principal Server ausfällt, kann ein erzwungener Failover nur ausgeführt werden, wenn der Mirror Server eine Verbindung zum Witness Server besitzt. Fallen Principal- und Witness Server gleichzeitig aus kann ebenfalls kein automatisches Failover erfolgen und ist keine der Datenbanken mehr erreichbar bis mindestens zwei Server-Instanzen wieder aktiv sind.
Wie können Client-Applikation auf den "Rollen"-Tausch reagieren ?
Auf den Ausfall eines Principal-Servers und Rollen-Tausch mit dem Mirror Server können Client-Applikationen, die auf eine Datenbank des Principal-Servers zugreifen, unterschiedlich reagieren. Die möglichen Reaktionen hängen von dem Datenbank-Provider ab, der für die Verbindung zur SQL Server Datenbank verwendet wird.
Client Applikation verwendet SQL Server Native Client oder ADO.Net als Datenbank-Provider für den Zugriff auf die Principal-Datenbank.
Mit dem Einsatz des SQL Server Native Client oder ADO.Net als Datenbank-Provider können Client-Applikationen so eingerichtet werden, dass diese im Failover-Fall ihre Verbindungs-Informationen zum neuen Principal-Server automatisch umlenken. Dazu wird in dem Connectionstring zur SQL Server Datenbank der Principal- und Mirror-Server angegeben.Client Applikation verbindet sich via ODBC Datenquelle mit der Principal Datenbank
Beim Einsatz einer ODBC-Datenquelle für die Verbindung zur Principal-Datenbank muß im Failover-Fall der Verbindungspfad zum neuen Principal-Server manuell in der ODBC-Datenquelle angepasst werden.Client Applikation verwendet einen Connectionstring mit Angabe des Server- und Datenbanknamen für den Zugriff auf die Principal-Datenbank
In diesem Fall muß bei einem Failover innerhalb der Applikation der Name des neuen Principal-Servers in dem Connectionstring eingetragen werden.
Können Client-Applikationen auf die Mirror-Datenbank zugreifen ?
Die Mirror-Datenbank ist schreib- und lese-geschützt. Das bedeutet, daß von Client-Applikationen nicht auf die Mirror-Datenbank zugegriffen werden kann. Die Möglichkeit, dass Client-Applikationen auf die Daten der Mirror-Datenbank zugreifen, besteht nur durch den Einsatz eines Datenbank-Snapshots oder der Replikation auf die Mirror-Datenbank. Dieses Szenario erfordert mindestens eine Lizenz der SQL Server Enterprise-Edition auf dem Mirror-Server.
Was sind die Unterschiede zum Logfile-Shipping ?
Ein weiterer Ansatz, um nach einem Server-Ausfall in sehr kurzer Zeit eine "Ersatz-" Datenbank zu erzeugen ist die Logfile Shipping Methode. Mit dieser Methode werden von einer primären Datenbank Transaktionsprotokolle an eine oder mehrere sekundäre Datenbanken versendet und dort zur laufenden Wiederherstellung der sekundären Datenbanken verwendet.
Im Gegensatz zum Database Mirroring wird beim Logfile Shipping eine Netzwerkfreigabe benötigt, auf der die Transaktionsprotokolle vom primären Server kopiert werden. Diese Transaktionsprotokolle werden von den sekundären Instanzen auf ein lokales Laufwerk kopiert und für ein Restore der sekundären Datenbank verwendet. Für die Kopier- und Restore-Aktionen auf dem primären und sekundären Server wird der SQL Server Agent der primären und sekundären Instanzen verwendet.
Der Vorteil beim Logifle Shipping besteht darin, daß mehrere Stand-By-Datenbanken erzeugt werden können, auf die Applikationen lesend zugreifen können. Ein Nachteil im Gegensatz zum Database Mirroring ist die fehlende Möglichkeit eines automatischen Failovers und ein höheres Datenverlust-Risiko bei einem Server-Ausfall.
Welche Edition und Version wird für Database Mirroring benötigt ?
Bei der Wahl der "richtigen" Version sollten Sie folgende Punkte berücksichtigen
Für die Rolle des Principal-Server oder Mirror-Server wird mindestens die Standard Edition des SQL Server benötigt.
Beachten Sie, dass für den Einsatz von Database Mirroring die gleiche SQL Server-Edition auf dem Principal- und auf dem Mirror Server benötigt wird.
Wenn ein Witness-Server eingesetzt werden soll kann für diese Witness-Server Instanz eine andere Edition (z. Bsp. SQL Server Express) verwendet werden.
Microsoft unterstützt Database Mirroring bereits seit dem SQL Server 2005 Service Pack 1 (SP1).
Die Principal- und Mirror Serverinstanz müssen unter derselben Version von SQL Server ausgeführt werden.
Obwohl der Mirror Server eine höhere SQL Server-Version aufweisen darf, wird diese Konfiguration nur für einen sorgfältig geplanten Upgradeprozess empfohlen.
Sollten Sie noch eine ältere Version als SQL Server 2005 Service Pack 1 einsetzen, helfen wir Ihnen gerne dabei diese auf eine neue Version zu migrieren.
Hier noch die Links zu den Seiten von Microsoft zu den Voraussetzungen und dem Einrichten von Database Mirroring
Externer Link zu Microsoft: SQL Server Database Mirroring: Voraussetzungen, Beschränkungen und Empfehlungen | Microsoft Learn
Externer Link zu Microsoft: SQL Server Database Mirroring: Einrichten der Datenbankspiegelung (SQL Server) | Microsoft Learn
Hier noch ein Hinweis zur optimalen Netzwerkanbindung
Für die Kommunikation zwischen dem Witness-Server und dem Principal- bzw dem Mirror-Server sollte ein detiziertes VLAN oder Netzwerk verwendet werden. Auch für die Replikation zwischen Principal und Mirror empfiehlt sich der Einsatz eines gesonderten Netzwerksegementes.
Tipps und Hinweise für den Einsatz von Database Mirroring
Database Mirroring wurde von Microsoft inzwischen abgekündigt und als Nachfolger Always On-Verfügbarkeitsgruppen eingeführt.
In der Standard Edition des SQL Server wird Always On Verfügbarkeitsgruppen in einer Basic-Variante mit einer Untermenge der Funktionen von Always On-Verfügbarkeitsgruppen zur Verfügung gestellt.
Da Database Mirroring auch in der aktuellen SQL Server Version 2022 weiterhin unterstützt wird lohnt sich ein Vergleich der beiden Hochverfügbarkeits-Methoden, insbesondere wenn Sie die SQL Server Standard Edition einsetzten möchten und Sie für Ihre Applikationen die Möglichkeit für ein automatisches Failover nutzen wollen.