Seit SQL 2005 SP1 steht das MIrroringvon MIcrosoft supported zur Verfügung. Wie und welche Leistung das Spiegeln einer Datenbank bringt lesen Sie in diesem Beitrag.

MIt SQL 2005 wurde das Spiegeln von Datenbanken eingeführt. Ziel war es hochreduntante Datenbanken zu erhalten. Das Feature wird allerdings nur von der Enterprise Version unterstützt und ab SP1 von Microsoft supportet.

MInimalszenario - manueller Failover

Eine Minimalkonfiguration erreicht man mit mind. zwei Servern, wobei einer als Prinzipal und der andere als Spiegel dient. Der prinzipal übernimmt szusagen die führende Rolle und ist dabei die Produktivdatenbank, während der Spiegelpartner im Notfall per Failover aktiv geschalten werden kann und bis dahin im Restore Modus steht - also weder schreibbar, noch lesbar. In diesem Szenario muss der Failover manuell durchgeführt werden.

Automatischer Failover

In einem erweiterten Szenario kann eine weitere Instanz die Kontrolle über die Verbindung zu dem Prinzipal übernehmen und im Fall des Falles den Spiegel online schalten. Sobald der Prinzipal wieder zur Verfügung steht, wird er zum Spiegel gemacht und übernimmt solange diese Rolle, bis manuell oder automatisch ein Failover stattfindet. Die weiteree Instanz mit der Kontrollfunktion wird Zeuge oder Witness genannt und kann durchaus der SQL Server Express verwendet werden.

Die Datenbankspiegelung beginnt mit einer Kopie der Prinzipaldatenk, die am besten per Sicherung übertragen wird. Leider ist in dem Spiegel Assistenten keine Werkzeug enthalten, um diese Aufgabe zu übernehmen. Leider auch deswegen, weil dies gerade beim Logshipping der Fall ist. Wer schlau ist, kann diese Aufgabe aslo auch mit Transaktionsprotokollversand Assistenten lösen. Dieser Fall ist auch deswegen interessant, da MIrroring und Logshipping durchaus kombinierbar sind.

Beachten Sie, daß das Wiederherstellungsmodel auf Vollständig gesetzt werden muss. Übrigens sind Systemdatenbanken nicht spiegelbar.
Das Prinzip des Spiegelns beruht darauf, daß nicht das Transaktionsprotokoll versandt wird, sondern die einzelnen Transaktionen selber. 
Eine Prinzipal kann nur einmal gespiegelt werden.

Für die Arbeit des Spiegels wird nicht der Standardport des SQL Server verwendet, sondern eine Spiegelendpunkt jweils auf dem Prinzipal, Spiegelpartner und Zeuge eingerichten. Standardmäßig wird dafür der Port 5022 verwendet. Sofern allerdings mehrere Aufgaben wie Spiegel und Zeuge auf einem Server sein sollten, dann müssen die Ports verschieden angelegt werden.

Betriebsmodi: Synchron - Asynchron

Zur Durchführung der Spiegelung stehen mehrere Betriebsmodi zu Verfügung. Entweder hohe Verfügbarkeit oder hoher Schutz. Der Modus hohe Verfügbarkeit stellt sicher, daß Transaktionen auf dem Spiegel und auf dem prinzipal abgeschlossen sind, beovr die nächste Transaktion umgesetzt wird.  Im Modus hoher Schutz wird ebenfalls erst eine Transaktion umgesetzt, sofern Sie auf dem Spiegel ebenfalls commited wurde. Allerdings erfolgt die Kommunikation synchron und ohne Zeuge. Insofern kann es passieren, dass der Spiegel zeitlich ein wenig hinterher hinkt.

Die Hohe Verfügbarkeit kann übrigens auch im asynchronen Modus betriebenwerden, was zur Folge hat, dass der Prinzipal nicht auf eine Bestätigung warten muss und somit Anwendungen weiter arbeiten können.

Assistent zum Eirichten einer Spiegelung mit automatischen Failover

Konfiguration der Dienstkonten

Konfiguration der Dienstkonten

Fazit:
Die Spiegelung der Datenbank ist ein sehr einfaches MIttel um Redundanz und Ausfallsicherheit zu erreichen. Der automatische Failover sollte innerhalb von 3 Sekunden durchgeführt sein. zudem ist die Spiegelung im Vergleich zum Cluster noch streckengebunden.Insofern ist