Suchen

Microsoft sagt der Datenbankspiegelung adé Hochverfügbarkeit mit SQL Server 2014 wird teuer

| Autor / Redakteur: Filipe Pereira Martins und Anna Kobylinska / Ulrike Ostler

Seit Microsoft die Datenbankspiegelung zum alten Eisen erklärt hat, suchen Anwender von der Datenbank „SQL Server“ nach Alternativen in Sachen Hochverfügbarkeit. Mit „SQL Server 2012“ vorgestellt und im Release 2014 ausgebaut, soll die Technologie „AlwaysOn“ mit Hochverfügbarkeitsgruppen die Alternative sein. Das birgt Einschränkungen.

Firmen zum Thema

In SQL Server 2014 sind alle Hochverfügbarkeits-Features, für die Microsoft eine Zukunft vorsieht, den Anwendern der Edition Enterprise vorbehalten.
In SQL Server 2014 sind alle Hochverfügbarkeits-Features, für die Microsoft eine Zukunft vorsieht, den Anwendern der Edition Enterprise vorbehalten.
(Bild: Microsoft )

Technische Lösungen rund um die Hochverfügbarkeit (High Availability oder kurz: HA) sollen die Erreichbarkeit von Diensten maximieren, die Auswirkungen eines Hardwareschadens mildern, die Ausfälle der Netzinfrastruktur auffangen. Dank HA-Features lassen sich nicht nur die Ausfallzeiten aus der Sicht des Endbenutzers minimieren, sondern auch der Verlust transaktionaler Daten praktisch ausschließen.

SQL Server 2012 konnte bisher je nach Edition mit bis zu drei Features für die Hochverfügbarkeit aufwarten: der synchronen Datenbankspiegelung, den AlwaysOn Failover-Cluster-Instanzen und den AlwaysOn-Verfügbarkeitsgruppen (die letzte Option ist nur in der „Edition Enterprise“ zu haben). Bei der synchronen Datenbankspiegelung in SQL Server handelte es sich um eine Hochverfügbarkeitslösung; bei der asynchronen Datenbankspiegelung (nur in der Enterprise-Edition verfügbar) um eine Notfalllösung zur Datenwiderherstellung.

Das Wenn und Aber für die Datenbankspiegelung

Bei der Datenbankspiegelung besteht die Umgebung aus zwei Instanzen mit lokalem Speicher, einem Prinzipal-Server mit der Prinzipal-Datenbank und einem Spiegel-Server mit der Spiegel-Datenbank. Im Hochsicherheitsmodus kann ein automatisches Failover stattfinden. Dies erfordert allerdings einen dritten Server, den so genannten Zeugen.

Bei der synchronen Datenbankspiegelung übergibt der Prinzipal-Server den Commit einer jeden Transaktion unmittelbar an den Spiegel-Server und erst nach Erhalt einer Bestätigung meldet er den Vorgang als abgeschlossen. Der Sekundär-Server kann die Aufgaben des Primär-Server sofort übernehmen.

Informationen von außerhalb der betreffenden Datenbank wie Jobs, Joints und Transaktionen, die mehrere Datenbanken gleichzeitig betreffen, gehen entweder verloren oder lassen sich nicht fehlerfrei übernehmen. Diese Lösung ist zudem langsam.

Asynchrone Datenbankspiegelung erfolgt mit einer erheblichen Zeitverzögerung. Daher eignet sich dieses Vorgehen zwar nicht für ein automatisches Failover, dafür aber für die Datensicherung und die Notfallwiederherstellung durch einen Administrator.

Artikelfiles und Artikellinks

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 42556186)