Geschäftskontinuität und Datenbankwiederherstellung – SQL Server für Linux

Gilt für:SQL Server unter Linux

Dieser Artikel bietet eine Übersicht über Lösungen für Geschäftskontinuität für Hochverfügbarkeit und Notfallwiederherstellung in SQL Server unter Windows und Linux.

Jeder, der SQL Server bereitstellt, muss sicherstellen, dass alle unternehmenskritischen SQL Server-Instanzen und die darin enthaltenen Datenbanken verfügbar sind, wenn die Geschäfts- und Endbenutzer sie benötigen, unabhängig davon, ob diese Verfügbarkeit in regelmäßigen Geschäftszeiten oder rund um die Uhr erfolgt. Das Ziel ist, das Unternehmen mit minimaler oder ohne Unterbrechung aufrechtzuerhalten. Dieses Konzept wird auch als Geschäftskontinuität bezeichnet.

SQL Server 2017 (14.x) und höhere Versionen haben Features und Verbesserungen für die Verfügbarkeit eingeführt. Die größte Ergänzung ist die Unterstützung für SQL Server auf Linux-Verteilungen. Eine vollständige Liste der neuen Features in SQL Server finden Sie in den folgenden Artikeln:

Version	Betriebssystem
Neuerungen in SQL Server 2025 (17.x)	Windows \| Linux
Neuerungen in SQL Server 2022 (16.x)	Windows \| Linux
Neuerungen in SQL Server 2019 (15.x)	Windows \| Linux
Neuerungen in SQL Server 2017 (14.x)	Windows \| Linux

Dieser Artikel konzentriert sich auf die Verfügbarkeitsszenarien in SQL Server 2017 (14.x) und höheren Versionen sowie auf die neuen und erweiterten Verfügbarkeitsfeatures. Zu den Szenarien gehören Hybridbereitstellungen, die SQL Server-Bereitstellungen sowohl unter Windows Server als auch unter Linux umfassen können, und solche, die die Anzahl der lesbaren Kopien einer Datenbank erhöhen können.

Dieser Artikel behandelt zwar keine Verfügbarkeitsoptionen außerhalb von SQL Server (z. B. Virtualisierung), aber alles, was hier behandelt wird, gilt für SQL Server-Installationen innerhalb eines virtuellen Gastcomputers, ob in der öffentlichen Cloud oder in einem lokalen Hypervisorserver gehostet.

SQL Server-Szenarien, die Verfügbarkeitsfeatures verwenden

Sie können AlwaysOn-Verfügbarkeitsgruppen, Failoverclusterinstanzen und Protokollversand auf unterschiedliche Weise und nicht nur für die Verfügbarkeit verwenden. Es gibt vier Hauptmethoden, wie Sie die Verfügbarkeitsfeatures verwenden können:

Hochverfügbarkeit
Notfallwiederherstellung
Migrationen und Upgrades
Horizontales Hochskalieren von lesbaren Kopien von einer oder mehreren Datenbanken

In den folgenden Abschnitten werden die relevanten Features für jedes Szenario beschrieben. Ein Feature, das nicht abgedeckt wird, ist die SQL Server-Replikation. Während die SQL Server-Replikation nicht offiziell als Verfügbarkeitsfeature unter dem Always On-Dach festgelegt ist, wird sie häufig verwendet, um Daten in bestimmten Szenarien redundant zu machen. Die Mergereplikation wird für SQL Server unter Linux nicht unterstützt. Weitere Informationen finden Sie unter SQL Server-Replikation unter Linux.

Wichtig

Die SQL Server-Verfügbarkeitsfeatures ersetzen nicht die Anforderung, eine robuste, gut getestete Sicherungs- und Wiederherstellungsstrategie zu haben. Eine Sicherungs- und Wiederherstellungsstrategie ist der grundlegendste Baustein jeder Verfügbarkeitslösung.

Hochverfügbarkeit

Es ist wichtig, sicherzustellen, dass SQL Server-Instanzen oder -Datenbanken verfügbar sind, wenn ein Problem auftritt, das lokal in einem Rechenzentrum oder einer einzelnen Region in der Cloud liegt. In diesem Abschnitt wird erläutert, wie die SQL Server-Verfügbarkeitsfeatures hilfreich sein können. Alle beschriebenen Features sind für Windows Server und Linux verfügbar.

Verfügbarkeitsgruppen

Verfügbarkeitsgruppen (Availability Groups, AGs) bieten Schutz auf Datenbankebene, indem jede Transaktion einer Datenbank an eine andere Instanz oder ein Replikat gesendet wird, das eine Kopie dieser Datenbank in einem speziellen Zustand enthält. Sie können eine AG auf den Standard- oder Enterprise-Editionen bereitstellen. Die Instanzen, die in einer Verfügbarkeitsgruppe enthalten sind, können eigenständig oder Always On-Failoverclusterinstanzen (FCIs, im nächsten Abschnitt beschrieben) sein. Da die Transaktionen direkt an ein Replikat gesendet werden, werden Verfügbarkeitsgruppen empfohlen, wenn Anforderungen für niedrigere Ziele bei Wiederherstellungspunkten und der Wiederherstellungszeit gelten. Das Verschieben von Daten zwischen Replikaten kann synchron oder asynchron erfolgen. Die Enterprise Edition unterstützt bis zu drei synchrone Replikate, einschließlich des primären Replikats. Eine Verfügbarkeitsgruppe enthält eine vollständige Lese-/Schreibkopie der Datenbank, die sich auf dem primären Replikat befindet. Sekundäre Replikate können keine Transaktionen direkt von Benutzer*innen oder Anwendungen empfangen.

Hinweis

Always On ist ein Überbegriff für die Verfügbarkeitsfeatures in SQL Server und schließt Verfügbarkeitsgruppen und FCIs ein. Always On ist nicht der Name des AG-Features.

Vor SQL Server 2022 (16.x) boten Verfügbarkeitsgruppen nur Schutz auf Datenbankebene und nicht auf Instanzebene. Alles, was nicht im Transaktionsprotokoll erfasst oder in der Datenbank konfiguriert ist, muss für jedes sekundäre Replikat manuell synchronisiert werden. Einige Beispiele für Objekte, die manuell synchronisiert werden müssen, sind Anmeldungen auf Instanzebene, Verbindungsserver und SQL Server-Agent-Aufträge.

In SQL Server 2022 (16.x) und höheren Versionen können Sie Metadatenobjekte wie Benutzer, Anmeldungen, Berechtigungen und SQL Server-Agent-Aufträge auf AG-Ebene zusätzlich zur Instanzebene verwalten. Weitere Informationen finden Sie unter Was ist eine eigenständige Verfügbarkeitsgruppe?

Eine Verfügbarkeitsgruppe besitzt eine weitere Komponente, die als Listener bezeichnet wird. Durch diesen können Anwendungen und Benutzer*innen eine Verbindung herstellen, ohne zu wissen, welche Instanz von SQL Server das primäre Replikat hostet. Jede AG verfügt über einen eigenen Listener. Die Implementierungen des Listeners unterscheiden sich zwar geringfügig unter Windows Server und Linux, bieten aber beide die gleiche Funktionalität und Nutzbarkeit. Das folgende Diagramm zeigt eine Windows Server-basierte AG, die einen Windows Server-Failovercluster (WSFC) verwendet. Ein zugrunde liegender Cluster auf der Betriebssystemebene ist für die Verfügbarkeit erforderlich, unabhängig davon, ob es sich auf Linux oder Windows Server befindet. Dieses Beispiel zeigt eine einfache Konfiguration für zwei Server oder Knoten, bei der ein WSFC den zugrunde liegenden Cluster darstellt.

Abbildung einer einfachen Verfügbarkeitsgruppe

Bei Replikaten gelten für die Standard Edition und die Enterprise Edition unterschiedliche Höchstwerte. Eine Verfügbarkeitsgruppe in der Standard Edition, die als Basis-Verfügbarkeitsgruppe bezeichnet wird, unterstützt zwei Replikate (ein primäres und ein sekundäres) mit nur einer einzigen Datenbank in der Verfügbarkeitsgruppe. In der Enterprise Edition können nicht nur mehrere Datenbanken für eine einzige Verfügbarkeitsgruppe konfiguriert werden, sondern es können auch bis zu neun Replikate (ein primäres, acht sekundäre) verwendet werden. Die Enterprise Edition bietet weitere optionale Vorteile, z.B. lesbare sekundäre Replikate, das Erstellen von Sicherungen aus einem sekundären Replikat usw.

Hinweis

Die Datenbankspiegelung, die in SQL Server 2012 (11.x) als veraltet markiert wurde, ist in der Linux-Version von SQL Server weder verfügbar noch wird sie hinzugefügt. Kund*innen, die die Datenbankspiegelung immer noch verwenden, sollten die Migration zu Verfügbarkeitsgruppen planen, die den Ersatz für die Datenbankspiegelung darstellen.

Verfügbarkeitsgruppen können für die Verfügbarkeit entweder automatische oder manuelle Failover bereitstellen. Automatische Failover können auftreten, wenn die synchrone Datenverschiebung konfiguriert ist und die Datenbank auf dem primären und sekundären Replikat sich in einem synchronisierten Zustand befindet. Solange der Listener verwendet wird und die Anwendung eine unterstützte Version des .NET Frameworks (3.5 mit Service Pack 1 oder 4.6.2 und höher) nutzt, sollte das Failover mit minimaler bis keiner Auswirkung auf die Endbenutzer durchgeführt werden. Ein Failover zu einem sekundären Replikat, das dieses zum neuen primären Replikat macht, kann als automatisch oder manuell konfiguriert werden und wird im Allgemeinen in Sekunden gemessen.

In der folgenden Liste werden einige Unterschiede mit AGs unter Windows Server und Linux hervorgehoben:

Aufgrund der Funktionsweise des zugrunde liegenden Clusters unter Linux und Windows Server werden alle AG-Failovers (manuell oder automatisch) über den Cluster unter Linux durchgeführt. Bei Bereitstellungen von Windows Server-basierten Verfügbarkeitsgruppen müssen manuelle Failover über SQL Server ausgeführt werden. Automatische Failover werden unter Windows Server und Linux von den zugrunde liegenden Clustern behandelt.

Für SQL Server unter Linux sollten Sie eine Verfügbarkeitsgruppe (AG) mit mindestens drei Replikaten konfigurieren, da dies für das zugrunde liegende Clustering erforderlich ist.
Unter Linux wird der gemeinsame Name, der von jedem Listener verwendet wird, in DNS und nicht im Cluster definiert, wie er sich auf Windows Server befindet.

SQL Server 2017 (14.x) hat die folgenden Features und Verbesserungen für AGs eingeführt:

Clustertypen
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
Erweiterte MS DTC-Unterstützung (Microsoft Distributed Transaction Coordinator) für Windows Server-basierte Konfigurationen
Zusätzliche Szenarios für das horizontale Hochskalieren von schreibgeschützten Datenbanken (später in diesem Artikel beschrieben)

Clustertypen für Verfügbarkeitsgruppen

Das integrierte Verfügbarkeitsformular des Clusterings in Windows Server wird über eine Funktion namens Failoverclustering aktiviert. Dadurch kann ein WSFC erstellt werden, der mit einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz (FCI) verwendet werden kann. SQL Server liefert clusterfähige Ressourcen-DLLs, die Integration für AGs und FCIs bieten.

SQL Server für Linux unterstützt mehrere Clustertechnologien. Microsoft unterstützt die SQL Server Komponenten, während unsere Partner die entsprechende Clustertechnologie bereitstellen. So unterstützt SQL Server für Linux zusammen mit Pacemaker als Clusterlösung auch HPE Serviceguard und DH2i DxEnterprise.

Ein Windows-basierter Failovercluster und eine Linux-Clusterlösung haben mehr Gemeinsamkeiten als Unterschiede. Beide ermöglichen das Kombinieren von einzelnen Servern in einer Konfiguration, um die Verfügbarkeit zu gewährleisten und enthalten Konzepte für Ressourcen, Einschränken (die jedoch unterschiedlich implementiert sind), Failover usw.

Microsoft stellt z. B. für die Unterstützung von Pacemaker für die Konfiguration von Verfügbarkeitsgruppen und FCIs, einschließlich des automatischen Failovers, das Paket mssql-server-ha bereit. Dieses ähnelt den Ressourcen-DLLs in einem WSFC, ist aber nicht mit diesen identisch. Einer der Unterschiede zwischen einem WSFC und Pacemaker besteht darin, dass Pacemaker keine Netzwerknamenressource enthält. Diese Komponente ermöglicht das Abstrahieren des Namens des Listeners (oder der FCI) auf einem WSFC. Verwenden Sie DNS für die Namensauflösung unter Linux.

Aufgrund des Unterschieds im Clusterstapel müssen AGs in SQL Server 2017 (14.x) und höheren Versionen einige der Metadaten behandeln, die von einem WSFC nativ behandelt werden. Es gibt z. B. drei Clustertypen für eine Verfügbarkeitsgruppe, die in den cluster_type und cluster_type_desc Spalten gespeichert sys.availability_groups sind:

WSFC
Extern
Keine

Alle Verfügbarkeitsgruppen, die Verfügbarkeit erfordern, müssen einen zugrunde liegenden Cluster verwenden. Dies ist im Fall von SQL Server 2017 (14.x) und höher ein WSFC oder ein Linux-Cluster-Agent. Für Windows Server-basierte AGs, die einen zugrunde liegenden WSFC verwenden, ist der Standardclustertyp WSFC, und Sie müssen ihn nicht festlegen. Bei Linux-basierten AGs müssen Sie den Clustertyp beim Erstellen der AG auf "Extern" festlegen. Die Integration mit einer externen Clusterlösung unter Linux wird nach der Erstellung der Verfügbarkeitsgruppe konfiguriert, während dies bei einem WSFC zur Erstellungszeit erfolgt.

Der Clustertyp „Keiner“ kann für Windows Server- und Linux-Verfügbarkeitsgruppen verwendet werden. Das Festlegen des Clustertyps auf „Keiner“ bedeutet, dass die Verfügbarkeitsgruppe keinen zugrunde liegenden Cluster erfordert. Das bedeutet, dass es sich bei SQL Server 2017 (14.x) um die erste Version von SQL Server handelt, die Verfügbarkeitsgruppen ohne einen Cluster unterstützt. Der Nachteil hierbei ist jedoch, dass diese Konfiguration nicht als Hochverfügbarkeitslösung unterstützt wird.

Wichtig

In SQL Server 2017 (14.x) und höheren Versionen können Sie einen Clustertyp für eine AG nach der Erstellung nicht mehr ändern. Diese Einschränkung bedeutet, dass eine AG nicht von "None" auf "External" oder "WSFC" umgestellt werden kann und umgekehrt.

Wenn Sie nur zusätzliche schreibgeschützte Kopien einer Datenbank hinzufügen möchten oder von den Vorteilen einer AG für Migration und Upgrades profitieren wollen, ohne sich mit der Komplexität eines zugrunde liegenden Clusters oder sogar einer Replikation auseinandersetzen zu müssen, sollten Sie die Einrichtung einer AG mit dem Clustertyp "Keine" in Betracht ziehen. Weitere Informationen finden Sie in den Abschnitten "Migrationen und Upgrades" und " Read-Scale".

Der folgende Screenshot zeigt die Unterstützung für die verschiedenen Arten von Clustertypen in SQL Server Management Studio (SSMS). Sie müssen Version 17.1 oder höher ausführen. Der folgende Screenshot stammt aus Version 17.2:

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

In SQL Server 2016 (13.x) wurde die Unterstützung für die Anzahl von synchronen Replikaten in der Enterprise Edition von zwei auf drei erhöht. Wenn jedoch ein sekundäres Replikat synchronisiert wird, das andere Replikat jedoch ein Problem aufweist, gibt es keine Möglichkeit, das Verhalten zu steuern, um das primäre Replikat entweder auf das fehlerhafte Replikat zu warten oder zuzulassen, dass es fortzufahren. In diesem Szenario konnte das primäre Replikat weiterhin Schreibdatenverkehr empfangen, obwohl sich das sekundäre Replikat nicht in einem synchronisierten Zustand befindet, was zu Datenverlusten im sekundären Replikat führt.

In SQL Server 2017 (14.x) und höheren Versionen können Sie das Verhalten der Vorgänge steuern, wenn synchrone Replikate vorhanden REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITsind. Diese Option funktioniert folgendermaßen:

Es gibt drei mögliche Werte: 0, 1, und 2.
Der Wert ist die Anzahl der sekundären Replikate, die synchronisiert werden müssen, was Auswirkungen auf Datenverlust, AG-Verfügbarkeit und Failover hat.
Für WSFCs und einen Clustertyp von None lautet der Standardwert 0, und Sie können ihn manuell auf 1 oder 2 festlegen.
Bei einem Clustertyp "Extern" legt der Clustermechanismus diesen Wert standardmäßig fest, und Sie können ihn manuell überschreiben. Für drei synchrone Replikate lautet 1der Standardwert .

Unter Linux konfigurieren Sie den Wert für REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT für die AG-Ressource im Cluster. Unter Windows legen Sie sie über Transact-SQL fest.

Ein höherer Wert als 0 gewährleistet einen höheren Datenschutz, denn wenn die erforderliche Anzahl sekundärer Replikate nicht verfügbar ist, ist die primäre Replik nicht verfügbar, bis diese Bedingung behoben wird. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT wirkt sich auch auf das Failoververhalten aus, da das automatische Failover nicht auftreten kann, wenn sich die richtige Anzahl sekundärer Replikate nicht im richtigen Zustand befindet. Unter Linux erlaubt ein Wert von 0 kein automatisches Failover. Wenn Sie also unter Linux synchron mit automatischem Failover verwenden, müssen Sie den Wert höher als 0 festlegen, um automatisches Failover zu erreichen. 0 unter Windows Server entspricht dem Verhalten in SQL Server 2016 (13.x) und früheren Versionen.

Erweiterte Unterstützung für den Microsoft Distributed Transaction Coordinator

Vor SQL Server 2016 (13.x) war die einzige Möglichkeit, die Verfügbarkeit für Anwendungen in SQL Server sicherzustellen, die verteilte Transaktionen erfordern und die intern DTC nutzen, FCIs bereitzustellen. Eine verteilte Transaktion kann auf zwei Arten erfolgen:

Eine Transaktion, die mehrere Datenbanken in derselben SQL Server-Instanz umfasst.
Eine Transaktion, die mehrere SQL Server-Instanzen umfasst oder möglicherweise eine Nicht-SQL Server-Datenquelle umfasst.

In SQL Server 2016 (13.x) wurde eine Teilunterstützung für DTC mit Verfügbarkeitsgruppen eingeführt, die das zweite Szenario abdecken. SQL Server 2017 (14.x) unterstützte dann beide Szenarien mit DTC.

In SQL Server 2017 (14.x) und höheren Versionen können Sie einer AG nach der Erstellung DTC-Unterstützung hinzufügen. In SQL Server 2016 (13.x) können Sie die DTC-Unterstützung nur beim Erstellen der AG aktivieren.

Failoverclusterinstanzen

Failoverclusterinstanzen (FCIs) stellen die Verfügbarkeit für die gesamte Installation von SQL Server bereit, die als Instanz bezeichnet wird. Wenn bei FCIs ein Problem auftritt, wird alles innerhalb der Instanz auf einen anderen Server verschoben, einschließlich Datenbanken, SQL Server-Agent-Aufträgen, verknüpften Servern und mehr. Alle FCIs erfordern einen gemeinsamen Speicher, auch wenn er netzwerkdefiniert ist. Ein Knoten kann jederzeit die Ressourcen der FCI verwalten und besitzen. Im folgenden Diagramm besitzt der erste Knoten des Clusters das FCI. Sie besitzt außerdem die zugeordneten freigegebenen Speicherressourcen, die durch die durchgezogene Linie zum Speicher angezeigt werden.

Diagramm einer Failoverclusterinstanz.

Nach einem Failover ändert sich der Besitz, wie im folgenden Diagramm dargestellt:

Diagramm einer Failoverclusterinstanz nach dem Failover.

Ein FCI hat keinen Datenverlust, aber der zugrunde liegende freigegebene Speicher ist ein einzelner Fehlerpunkt, da eine Kopie der Daten vorhanden ist. Um redundante Kopien von Datenbanken zu haben, kombinieren Sie FCIs mit einer anderen Verfügbarkeitsmethode, z. B. einem AG oder einem Logversand. Die andere Methode muss physisch getrennten Speicher vom FCI verwenden. Wenn der FCI auf einen anderen Knoten überschlägt, wird er auf einem Knoten angehalten und auf einem anderen Knoten gestartet. Dieser Vorgang ähnelt dem Ausschalten eines Servers und dem Aktivieren des Servers.

Ein FCI durchläuft den normalen Wiederherstellungsprozess. Es rollt alle Transaktionen weiter, die vorwärts gerollt werden müssen, und setzt alle unvollständigen Transaktionen zurück. Daher ist die Datenbank von einem Datenpunkt bis zum Zeitpunkt des Fehlers oder manuellen Failovers konsistent, sodass kein Datenverlust auftritt. Datenbanken sind erst verfügbar, nachdem die Wiederherstellung abgeschlossen ist. Die Wiederherstellungszeit hängt von vielen Faktoren ab und ist im Allgemeinen länger als ein Ausfall einer AG. Der Kompromiss besteht darin, dass beim Fehlschlagen einer AG möglicherweise zusätzliche Aufgaben erforderlich sind, um eine Datenbank nutzbar zu machen, z. B. das Aktivieren eines SQL Server-Agent-Auftrags.

Hinweis

Die beschleunigte Datenbankwiederherstellung (ADR) kann die Wiederherstellungszeit verringern. Weitere Informationen finden Sie unter Beschleunigte Datenbankwiederherstellung.

FCIs abstrahieren genau wie Verfügbarkeitsgruppen, auf welchem Knoten des zugrunde liegenden Clusters diese gehostet werden. Eine FCI behält immer denselben Namen bei. Anwendungen und Endbenutzer stellen niemals eine Verbindung mit den Knoten her. Stattdessen verwenden sie den eindeutigen Namen, der der FCI zugewiesen ist. Eine FCI kann in einer Verfügbarkeitsgruppe als eine der Instanzen enthalten sein, die entweder ein primäres oder ein sekundäres Replikat hosten.

In der folgenden Liste werden einige Unterschiede mit FCIs unter Windows Server und Linux hervorgehoben:

Unter Windows Server ist FCI ein Teil des Installationsvorgangs. Sie konfigurieren eine FCI unter Linux nach der Installation von SQL Server.
Linux unterstützt nur eine einzelne Installation von SQL Server pro Host, sodass alle FCIs eine Standardinstanz sind. Windows Server unterstützt bis zu 25 FCIs pro WSFC.
Der allgemeine Name, der von FCIs unter Linux verwendet wird, wird in DNS definiert und sollte mit dem der Ressource identisch sein, die für die FCI erstellt wurde.

Protokollversand

Wenn Wiederherstellungspunkt- und Wiederherstellungszeitziele flexibler sind oder Datenbanken nicht äußerst unternehmenskritisch sind, ist der Protokollversand ein weiteres bewährtes Verfügbarkeitsfeature in SQL Server. Basierend auf den nativen Sicherungen von SQL Server generiert der Prozess für den Protokollversand automatisch Transaktionsprotokollsicherungen, kopiert diese auf eine oder mehrere Instanzen, die als betriebsbereit bekannt sind, und wendet sie auf diese Standbyinstanzen an. Der Protokollversand verwendet SQL Server-Agent-Aufträge, um den Sicherungs- und Kopiervorgang sowie den Anwendungsvorgang der Transaktionsprotokollsicherungen zu automatisieren.

Abbildung des Protokollversands

Der größte Vorteil der Verwendung von Log Shipping besteht darin, dass menschliche Fehler berücksichtigt werden, da Sie die Anwendung von Transaktionsprotokollen verzögern können. Wenn beispielsweise jemand eine UPDATE ohne Klausel WHERE ausgibt, hat der Standbymodus möglicherweise nicht die Änderung, sodass Sie während der Reparatur des primären Systems zu diesem Wechseln wechseln können. Während der Protokollversand einfach zu konfigurieren ist, ist der Wechsel von der primären zu einem warmen Standbymodus, der als Rollenänderung bezeichnet wird, immer manuell. Sie initiieren eine Rollenänderung über Transact-SQL und wie eine AG müssen alle Objekte, die nicht im Transaktionsprotokoll erfasst werden, manuell synchronisieren. Sie müssen den Protokollversand pro Datenbank konfigurieren, während eine einzelne AG mehrere Datenbanken enthalten kann.

Im Gegensatz zu einer Verfügbarkeitsgruppe oder FCI bietet der Protokollversand keine Abstraktion für eine Rollenänderung, die Anwendungen verarbeiten können müssen. Techniken wie ein DNS-Alias (CNAME) können eingesetzt werden, es gibt jedoch Vor- und Nachteile, z.B. die Zeit, die ein DNS nach dem Wechsel zum Aktualisieren benötigt.

Notfallwiederherstellung

Wenn Ihr primärer Verfügbarkeitsstandort einer Katastrophe wie einem Erdbeben oder einer Überschwemmung ausgesetzt ist, muss das Unternehmen darauf vorbereitet sein, die Systeme an anderer Stelle online schalten zu können. In diesem Abschnitt wird erläutert, wie die SQL Server-Verfügbarkeitsfeatures die Geschäftskontinuität unterstützen können.