Freigeben über

Hochverfügbarkeit und Schutz von Daten für Verfügbarkeitsgruppenkonfigurationen

Gilt für:SQL Server unter Linux

In diesem Artikel werden unterstützte Bereitstellungskonfigurationen für SQL Server AlwaysOn-Verfügbarkeitsgruppen auf Linux-Servern vorgestellt. Eine Verfügbarkeitsgruppe unterstützt Hochverfügbarkeit und den Schutz von Daten. Hohe Verfügbarkeit wird durch automatische Fehlererkennung, automatisches Failover und transparente Wiederverbindung nach einem Failover gewährleistet. Synchronisierte Replikate bieten Datenschutz.

In einem Windows Server Failover-Cluster (WSFC) verwendet eine allgemeine Konfiguration für eine hohe Verfügbarkeit zwei synchrone Replikate und einen dritten Server oder eine dritte Dateifreigabe, um Quorum bereitzustellen. Der Dateifreigabezeuge überprüft die Konfiguration der Verfügbarkeitsgruppe, einschließlich des Synchronisierungsstatus und der Rolle des Replikats. Durch diese Konfiguration wird sichergestellt, dass das sekundäre Replikat, das als Failoverziel ausgewählt wurde, über die neuesten Daten verfügt und eine aktuelle Verfügbarkeitsgruppenkonfiguration besitzt.

Der WSFC synchronisiert die Konfigurationsmetadaten für die Failover-Vermittlung zwischen den Verfügbarkeitsgruppenreplikaten und dem Dateifreigabezeugen. Wenn sich eine Verfügbarkeitsgruppe nicht in einem WSFC befindet, speichern die SQL Server Instanzen Konfigurationsmetadaten in der Datenbank master.

Ein Beispiel: Eine Verfügbarkeitsgruppe auf einem Linux-Cluster hat CLUSTER_TYPE = EXTERNAL. Es ist kein WSFC zur Failoververmittlung vorhanden. In diesem Fall werden die Konfigurationsmetadaten von den SQL Server instanzen verwaltet und gepflegt. Da in diesem Cluster kein Zeugenserver vorhanden ist, ist eine dritte SQL Server Instanz erforderlich, um Konfigurationsstatusmetadaten zu speichern. Alle drei SQL Server Instanzen stellen gemeinsam verteilten Metadatenspeicher für den Cluster bereit.

Der Cluster-Manager kann die Instanzen von SQL Server in der Verfügbarkeitsgruppe abfragen und Failover koordinieren, um hohe Verfügbarkeit aufrechtzuerhalten. Auf einem Linux-Cluster ist Pacemaker der Cluster-Manager.

Ab SQL Server 2017 (14.x) CU 1 ist die hohe Verfügbarkeit einer Verfügbarkeitsgruppe mit CLUSTER_TYPE = EXTERNAL für zwei synchrone Replikate und ein reines Konfigurationsreplikat aktiviert. Die Konfigurationsreplik kann in jeder Edition von SQL Server 2017 (14.x) CU 1 oder späteren Versionen (einschließlich der SQL Server Express Edition) gehostet werden. Es verwaltet Konfigurationsinformationen zur Verfügbarkeitsgruppe in der master-Datenbank, enthält jedoch nicht die Benutzerdatenbank in der Verfügbarkeitsgruppe.

Auswirkungen der Konfiguration auf die Standardeinstellungen für Ressourcen

Die Einstellung der REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Clusterressource garantiert, dass bevor das primäre Replikat jede Transaktion verbindlich macht, die angegebene Anzahl von sekundären Replikaten Transaktionsdaten in die Log-Datei schreibt. Wenn Sie einen externen Cluster-Manager verwenden, wirkt sich diese Einstellung sowohl auf die Hochverfügbarkeit als auch auf den Schutz von Daten aus. Der Standardwert für die Einstellung hängt von der Architektur ab, die zu dem Zeitpunkt verwendet wird, an dem die Clusterressource erstellt wird. Wenn Sie den SQL Server Ressourcen-Agent - mssql-server-ha - installieren und eine Clusterressource für die Verfügbarkeitsgruppe erstellen, erkennt der Clustermanager die Verfügbarkeitsgruppenkonfiguration und legt REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT entsprechend fest.

Wenn der Parameter REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT des Ressourcen-Agents von der Konfiguration unterstützt wird, wird dieser Parameter auf den Wert festgelegt, der Hochverfügbarkeit und den Schutz von Daten bereitstellt. Weitere Informationen finden Sie unter SQL Server Ressourcenagent für Pacemaker verstehen.

In den folgenden Abschnitten wird das Standardverhalten für die Clusterressource beschrieben.

Durch die Auswahl eines bestimmten Entwurfs für Verfügbarkeitsgruppen können Sie spezifische Geschäftsanforderungen an die Hochverfügbarkeit, den Schutz von Daten und die Leseskalierung erfüllen.

In den unten aufgeführten Konfigurationen werden die Entwurfsmuster für Verfügbarkeitsgruppen und die Funktionen der einzelnen Muster beschrieben. Diese Entwurfsmuster gelten für Verfügbarkeitsgruppen mit CLUSTER_TYPE = EXTERNAL für Hochverfügbarkeitslösungen.

  • Drei synchrone Replikate
  • zwei synchrone Replikate
  • zwei synchrone Replikate und ein Konfigurationsreplikat

Drei synchrone Replikate

Diese Konfiguration umfasst drei synchrone Replikate. Die Hochverfügbarkeit und der Schutz von Daten werden standardmäßig gewährleistet. Auch eine Leseskalierung ist möglich.

Diagramm einer Verfügbarkeitsgruppe mit einem primären Replikat, das Daten mit zwei sekundären Replikaten synchronisiert.

Eine Verfügbarkeitsgruppe mit drei synchronen Replikaten ermöglicht die Leseskalierung, Hochverfügbarkeit und den Schutz von Daten. In der folgenden Tabelle wird das Verfügbarkeitsverhalten beschrieben.

Verfügbarkeitsverhalten Leselastverteilung Hochverfügbarkeit und
Datenschutz		 Schutz von Daten
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Hauptausfall Automatisches Failover-Verfahren. Möglicherweise kommt es zu Datenverlusten. Das neue Primär ist Lese-/Schreibzugriff. Automatisches Umschalten bei Ausfall. Das neue primäre Replikat ist Lese-/Schreib-fähig. Automatisches Failover. Der neue Primärserver ist für Lese- oder Schreibvorgänge nicht verfügbar, bis der frühere Primärserver wiederhergestellt wurde und der Verfügbarkeitsgruppe als sekundärer Server wieder beigetreten ist.
Ausfall eines sekundären Replikats Primär hat Lese- und Schreibzugriff. Verfügbare sekundäre Replikate sind für Lesevorgänge verfügbar. Das primäre Replikat ist im Lese-/Schreibmodus. Verfügbare sekundäre Replikate sind für Lesevorgänge verfügbar. Die primäre Instanz bleibt für Lese- oder Schreibvorgänge nicht verfügbar, bis die fehlgeschlagene sekundäre Instanz wiederhergestellt und der Verfügbarkeitsgruppe wieder beigetreten ist.
Ausfall von zwei sekundären Replikaten Die primäre Instanz ist nur für Lesevorgänge und nicht für Schreibvorgänge verfügbar, bis eines der sekundären Replikate wiederhergestellt wird und der Verfügbarkeitsgruppe wieder beitritt. Die primäre Instanz ist nur für Lesevorgänge und nicht für Schreibvorgänge verfügbar, bis eines der sekundären Replikate wiederhergestellt wird und der Verfügbarkeitsgruppe wieder beitritt. Die primäre Datei bleibt für Lese- oder Schreibvorgänge nicht verfügbar, bis alle fehlgeschlagenen sekundären Replikate wiederhergestellt und der Verfügbarkeitsgruppe erneut zugeordnet werden.
Ausfall des primären und eines sekundären Replikats Automatisches Failover. Möglicherweise kommt es zu Datenverlusten. Das neue Primär ist nur für Lesezugriffe und nicht für Schreibvorgänge verfügbar, bis eines der sekundären Replikate wiederhergestellt ist und der Verfügbarkeitsgruppe wieder beitritt. Automatisches Failover. Die neue primäre Instanz ist nur für Lese- und Schreibvorgänge verfügbar, bis eines der sekundären Replikate sich erholt und der Verfügbarkeitsgruppe wieder beitritt. Automatisches Failover. Die neue primäre Instanz bleibt für Lese- oder Schreibvorgänge nicht verfügbar, bis das frühere primäre und das sekundäre Replikat wiederhergestellt werden und der Verfügbarkeitsgruppe erneut beitreten.

1 Standard

Zwei synchrone Replikate

Diese Konfiguration ermöglicht den Schutz von Daten. Ebenso wie bei anderen Konfigurationen für Verfügbarkeitsgruppen kann durch diese Konfiguration auch die Leseskalierung aktiviert werden. Die Konfiguration mit zwei synchronen Replikaten gewährleistet nicht automatisch Hochverfügbarkeit. Eine Zwei-Replikatkonfiguration ist nur für SQL Server 2017 (14.x) RTM anwendbar und wird nicht mehr für Versionen von SQL Server 2017 (14.x) ab CU1 unterstützt.

Diagramm einer Verfügbarkeitsgruppe mit einem primären Replikat, das Daten mit einem sekundären Replikat synchronisiert.

Eine Verfügbarkeitsgruppe mit zwei synchronen Replikaten gewährleistet die Leseskalierung und den Schutz von Daten. In der folgenden Tabelle wird das Verfügbarkeitsverhalten beschrieben.

Verfügbarkeitsverhalten Leseskalierung Schutz von Daten
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primärer Ausfall Automatisches Failover. Möglicherweise kommt es zu Datenverlusten. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen. Automatisches Failover. Der neue Primärserver ist für Lese- oder Schreibvorgänge nicht verfügbar, bis der ehemalige Primärserver wiederhergestellt ist und der Verfügbarkeitsgruppe als sekundär erneut beitritt.
Ausfall eines sekundären Replikats Primärinstanz ist Lese-/Schreibbereit und läuft in einem Zustand, der einem Datenverlust ausgesetzt ist. Die primäre Instanz bleibt für Lese- oder Schreibvorgänge nicht verfügbar, bis die fehlgeschlagene sekundäre Instanz wiederhergestellt und der Verfügbarkeitsgruppe wieder beigetreten ist.

1 Voreinstellung

Zwei synchrone Replikate und ein reines Konfigurationsreplikat

Eine Verfügbarkeitsgruppe mit mindestens zwei synchronen Replikaten und einem Konfigurationsreplikat gewährleistet den Schutz von Daten und kann ggf. auch Hochverfügbarkeit sicherstellen. Das folgende Diagramm veranschaulicht diese Architektur:

Diagramm einer Verfügbarkeitsgruppe mit einem primären Replikat, das Daten und Metadaten mit sekundären und nur konfigurationsgeschützten Replikaten synchronisiert.

  1. Synchrone Replikation von Benutzerdaten auf das sekundäre Replikat. Dieser Vorgang schließt auch Metadaten zur Konfiguration der Verfügbarkeitsgruppe ein.
  2. Synchrone Replikation von Metadaten der Verfügbarkeitsgruppen-Konfiguration. Benutzerdaten sind nicht enthalten.

Im obigen Diagramm überträgt ein primäres Replikat die Konfigurationsdaten per Push sowohl an das sekundäre Replikat als auch an das Konfigurationsreplikat. Das sekundäre Replikat empfängt ebenfalls Benutzerdaten, Das Konfigurationsreplikat erhält keine Benutzerdaten. Das sekundäre Replikat befindet sich im synchronen Verfügbarkeitsmodus. Das Konfigurationsreplikat enthält nicht die Datenbanken der Verfügbarkeitsgruppe, sondern nur Metadaten über die Verfügbarkeitsgruppe. Für die Konfigurationsdaten auf dem Konfigurationsreplikat wird synchron ein Commit ausgeführt.

Hinweis

Eine Verfügbarkeitsgruppe mit nur Konfigurationsreplikat ist neu für SQL Server 2017 (14.x) CU 1. Alle Instanzen von SQL Server in der Verfügbarkeitsgruppe müssen SQL Server 2017 (14.x) CU 1 oder höher sein.

Der Standardwert für REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ist 0. In der folgenden Tabelle wird das Verfügbarkeitsverhalten beschrieben.

Verfügbarkeitsverhalten Hochverfügbarkeit und
Datenschutz		 Schutz von Daten
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primärer Ausfall Automatisches Failover. Das neue primäre Replikat ist im Lese-/Schreibmodus. Möglicherweise kommt es zu Datenverlusten. Automatisches Failover. Der neue Primärserver ist für Lese- oder Schreibvorgänge nicht verfügbar, bis der ehemalige Primärserver wiederhergestellt ist und der Verfügbarkeitsgruppe als sekundär erneut beitritt.
Ausfall des sekundären Replikats Das primäre System ist im Lese-/Schreibmodus und läuft daher Gefahr eines Datenverlusts (falls es ausfällt und nicht wiederhergestellt werden kann). Es erfolgt kein automatisches Failover, wenn auch das Primärsystem ausfällt. Die primäre Instanz bleibt für Lese- oder Schreibvorgänge nicht verfügbar, bis die fehlgeschlagene sekundäre Instanz wiederhergestellt und der Verfügbarkeitsgruppe wieder beigetreten ist. Es gibt kein Replikat, das als Failoverziel verwendet werden kann, wenn auch das primäre Replikat ausfällt.
Ausfall bei der Konfigurationsreplikation Primär ist Lese-/Schreibzugriff. Ein automatisches Failover wird nicht durchgeführt, wenn der primäre Server ebenfalls ausfällt. Primär ist Lese/Schreib. Es findet kein automatisches Failover statt, wenn die Primärinstanz ebenfalls ausfällt.
Ausfall des synchronen sekundären Replikats und nur des Konfigurationsreplikats Die primäre Instanz ist für Lese- oder Schreibvorgänge nicht verfügbar. Kein automatisches Failover. Die primäre Instanz ist für Lese- oder Schreibvorgänge nicht verfügbar. Es gibt kein Replikat, das als Failoverziel verwendet werden kann, wenn auch das primäre Replikat ausfällt.

1 Voreinstellung

Hinweis

Die Instanz von SQL Server, die nur das Konfigurationsreplikat hosten, kann auch andere Datenbanken hosten. Sie kann auch als reine Konfigurationsdatenbank für mehr als eine Verfügbarkeitsgruppe fungieren.

Anforderungen

  • Alle Replikate in einer Verfügbarkeitsgruppe mit nur einem Konfigurationsreplikat müssen SQL Server 2017 (14.x) CU 1 oder höher sein.
  • Jede Edition von SQL Server kann nur ein Konfigurationsreplikat hosten, einschließlich SQL Server Express.
  • Für die Verfügbarkeitsgruppe ist mindestens ein sekundäres Replikat zusätzlich zum primären Replikat erforderlich.
  • Konfigurationsreplikate zählen nicht zur Höchstanzahl von Replikaten pro Instanz von SQL Server. SQL Server Standardedition bis zu drei Replikate erlaubt, SQL Server Enterprise Edition bis zu 9.

Überlegungen

  • In einer Verfügbarkeitsgruppe darf es nicht mehr als ein reines Konfigurationsreplikat geben.
  • Ein nur für Konfiguration bestimmtes Replikat kann kein primäres Replikat sein.
  • Sie können den Verfügbarkeitsmodus eines reinen Konfigurationsreplikats nicht anpassen. Wenn Sie von einem Konfigurationsreplikat zu einem synchronen oder asynchronen sekundären Replikat wechseln möchten, müssen Sie das Konfigurationsreplikat entfernen und ein sekundäres Replikat mit dem erforderlichen Verfügbarkeitsmodus hinzufügen.
  • Ein nur für die Konfiguration zuständiges Replikat ist synchron mit den Metadaten der Verfügbarkeitsgruppe. Benutzerdaten sind nicht vorhanden.
  • Eine Verfügbarkeitsgruppe ist ungültig, wenn sie über ein primäres Replikat und ein Konfigurationsreplikat, jedoch nicht über ein sekundäres Replikat verfügt.
  • Sie können keine Verfügbarkeitsgruppe für eine Instanz von SQL Server Express Edition erstellen.

Verstehen Sie den SQL Server Ressourcen-Agent für Pacemaker

SQL Server 2017 (14.x) hat sequence_number eingeführt, um sys.availability_groups anzuzeigen, ob ein Replikat, das als SYNCHRONOUS_COMMIT gekennzeichnet ist, auf dem neuesten Stand ist. sequence_number ist ein monoton wachsendes bigint, das angibt, wie aktuell das lokale Verfügbarkeitsgruppenreplikat im Vergleich zu den anderen Replikaten der Verfügbarkeitsgruppe ist.

Diese Nummer wird aktualisiert, wenn Sie Failovers ausführen, Replikas hinzufügen oder entfernen sowie andere Vorgänge in Verfügbarkeitsgruppen durchführen.

Das primäre Replikat aktualisiert die Nummer und verschiebt sie dann an sekundäre Replikate. Ein sekundäres Replikat, das auf dem neuesten Stand ist, hat denselben sequence_number wie das primäre.

Wenn Pacemaker entscheidet, ein Replikat als primär zu bewerben, sendet es zuerst eine Benachrichtigung an alle Replikate, um die Sequenznummer zu extrahieren und zu speichern. Diese Benachrichtigung wird als Pre-Promotion-Benachrichtigung bezeichnet. Als Nächstes, wenn Pacemaker versucht, eine Replik zum Primär zu befördern, wird die Replik nur dann selbst zum Primär, wenn ihre Sequenznummer die höchste unter allen Sequenznummern der Repliken ist. Andernfalls wird der Beförderungsvorgang abgelehnt. Durch die Verwendung dieses Prozesses kann nur das Replikat mit der höchsten Sequenznummer zum Primär befördert werden, wodurch Datenverlust verhindert wird.

Die Heraufstufung funktioniert solange, wie mindestens ein Replikat für die Heraufstufung verfügbar ist und dieselbe Sequenznummer wie der vorherige Primär hat. Der Pacemaker-Ressourcen-Agent legt standardmäßig automatisch REQUIRED_COPIES_TO_COMMIT fest, sodass mindestens ein synchrones Commit-sekundäres Replikat auf dem neuesten Stand und als Ziel eines automatischen Failovers verfügbar ist. Mit jeder Überwachungsaktion wird der Wert REQUIRED_COPIES_TO_COMMIT mithilfe der Formel „Anzahl der Replikate mit synchronem Commit geteilt durch zwei“ berechnet und ggf. aktualisiert. Zum Zeitpunkt des Failovers erfordert der Ressourcen-Agent (total number of replicas - required_copies_to_commit-Replikate) eine Reaktion auf die Vorabbenachrichtigung, um ein Replikat zum primären heraufzustufen. Das Replikat mit dem höchsten sequence_number-Wert wird zum primären Replikat heraufgestuft.

Betrachten Sie z. B. den Fall einer Verfügbarkeitsgruppe mit drei synchronen Replikaten – ein primäres Replikat und zwei synchrone commit-sekundäre Replikate.

  • REQUIRED_COPIES_TO_COMMIT ist 3 / 2 = 1

  • Die für die Reaktion auf die Vorabaktion erforderliche Anzahl von Replikaten ist 3 - 1 = 2. Es muss also zwei Replikate geben, damit das Failover ausgelöst werden kann. Wenn ein primärer Ausfall auftritt und eines der sekundären Replikate nicht reagiert, während nur eines der anderen auf die Aktion zur Vorbereitung einer Höherstufung reagiert, kann der Ressourcen-Agent nicht garantieren, dass das antwortende sekundäre Replikat den höchsten sequence_number-Wert hat. Ein Failover wird daher nicht ausgelöst.

Sie können das Standardverhalten außer Kraft setzen und die Verfügbarkeitsgruppenressource so konfigurieren, dass sie nicht automatisch gesetzt wird REQUIRED_COPIES_TO_COMMIT.

Wichtig

Wenn REQUIRED_COPIES_TO_COMMIT0 ist, besteht die Gefahr eines Datenverlusts. Wenn es einen Ausfall der primären Ressource gibt, löst der Ressourcen-Agent nicht automatisch ein Failover aus. Sie müssen sich entscheiden, ob Sie auf die Wiederherstellung des primären Systems warten oder einen manuellen Failover durchführen.

Um REQUIRED_COPIES_TO_COMMIT auf 0 festzulegen, führen Sie Folgendes aus:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Der entsprechende Befehl unter Verwendung von CRM (auf SUSE Linux Enterprise Server) lautet:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Um es auf den standardmäßig berechneten Wert zurückzusetzen, führen Sie Folgendes aus:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Hinweis

Das Aktualisieren der Ressourceneigenschaften bewirkt, dass alle Replikate beendet und neu gestartet werden. Diese Änderung stuft die primäre Instanz vorübergehend auf sekundär herab und fördert sie dann wieder, was zu einer vorübergehenden Nichtverfügbarkeit von Schreibvorgängen führt. Der neue Wert REQUIRED_COPIES_TO_COMMIT wird erst nach dem Neustart von Replikaten festgelegt, sodass er nicht sofort mit dem Ausführen des PCs-Befehls ausgeführt wird.

Ausgleich zwischen Hochverfügbarkeit und Datenschutz

Das weiter oben beschriebene Standardverhalten gilt auch für den Fall von zwei synchronen Replikaten (primär und sekundär). Pacemaker setzt REQUIRED_COPIES_TO_COMMIT auf 1, um sicherzustellen, dass das sekundäre Replikat immer auf dem neuesten Stand ist und maximaler Datenschutz gewährleistet wird.

Warnung

Diese Einstellung birgt ein höheres Risiko, dass das primäre Replikat aufgrund geplanter oder ungeplanter Ausfälle des sekundären Replikats nicht verfügbar ist. Sie können das Standardverhalten des Ressourcen-Agents ändern und den REQUIRED_COPIES_TO_COMMIT Wert durch den 0 Wert überschreiben:

sudo pcs resource update <ag1> required_copies_to_commit=0

Wenn Sie diesen Wert außer Kraft setzen, verwendet der Ressourcen-Agent die neue Einstellung für REQUIRED_COPIES_TO_COMMIT und beendet dessen Berechnung. Sie müssen es bei Bedarf manuell aktualisieren (z. B. wenn Sie die Anzahl der Replikate erhöhen).

In den folgenden Tabellen wird das Ergebnis eines Ausfalls des primären oder sekundären Replikats in verschiedenen Konfigurationen von Verfügbarkeitsgruppen-Ressourcen beschrieben.

Verfügbarkeitsgruppe – zwei synchrone Replikate

Konfiguration Primärer Ausfall Ausfall eines sekundären Replikats
REQUIRED_COPIES_TO_COMMIT = 0 Sie müssen manuell ein FAILOVER ausstellen.

Kann zu Datenverlust führen.

Die neue primäre Instanz ist lesend und schreibend.		 Das Primärsystem hat Lese-/Schreibzugriff und läuft mit einem Risiko für Datenverlust.
REQUIRED_COPIES_TO_COMMIT = 1 1 Der Cluster gibt automatisch FAILOVER aus

Kein Datenverlust.

Das neue primäre Replikat lehnt alle Verbindungen ab, bis das vorherige primäre Replikat wiederhergestellt ist und als sekundäres Replikat mit der Verfügbarkeitsgruppe verknüpft wird.		 Primär lehnt alle Verbindungen ab, bis Sekundär wiederhergestellt ist.

1 SQL Server-Ressourcenagent für das Standardverhalten von Pacemaker.

Verfügbarkeitsgruppe – drei synchrone Replikate

Konfiguration Primärausfall Ausfall eines sekundären Replikats
REQUIRED_COPIES_TO_COMMIT = 0 Sie müssen manuell ein FAILOVER ausstellen.

Kann zu Datenverlust führen.

Die neue primäre Instanz ist Lese-/Schreibfähig.		 Primär hat Lese-/Schreibzugriff.
REQUIRED_COPIES_TO_COMMIT = 1 1 Der Cluster gibt automatisch FAILOVER aus.

Kein Datenverlust.

Das neue Primärsystem ist Lese-/Schreibfähig.		 Die primäre Instanz ist auf Lese-/Schreibzugriff eingestellt.

1 SQL Server Ressourcen-Agent für Pacemaker-Standardverhalten.

Zugehöriger Inhalt

  • Last updated on