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-Always On-Verfügbarkeitsgruppen auf Linux-Servern vorgestellt. Eine Verfügbarkeitsgruppe unterstützt Hochverfügbarkeit und den Schutz von Daten. Ersteres wird durch die automatische Fehlererkennung, das automatische Failover und durch transparente Neuverbindungen nach dem Failover sichergestellt. Letzteres wird durch synchronisierte Replikate gewährleistet.

Auf einem Windows Server-Failovercluster (WSFC) umfasst eine gängige Hochverfügbarkeitskonfiguration zwei synchrone Replikate und einen dritten Server oder eine Dateifreigabe zur Bereitstellung des Quorums. Der Dateifreigabenzeuge überprüft die Konfiguration der Verfügbarkeitsgruppe, also z. B. den Synchronisierungsstatus und die 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 Failoververmittlung. Dabei wird entschieden, ob ein Failover für die Verfügbarkeitsgruppenreplikate oder den Dateifreigabezeugen ausgeführt wird. Wenn sich eine Verfügbarkeitsgruppe nicht auf einem WSFC befindet, speichern die SQL Server-Instanzen Konfigurationsmetadaten in der master-Datenbank.

Angenommen, für eine Verfügbarkeitsgruppe auf einem Linux-Cluster ist die Einstellung CLUSTER_TYPE = EXTERNAL festgelegt. Es ist kein WSFC zur Failoververmittlung vorhanden. In diesem Fall werden die Konfigurationsmetadaten von den SQL Server-Instanzen verwaltet. Da es keinen Zeugenserver auf diesem Cluster gibt, ist eine dritte SQL Server-Instanz erforderlich, um Metadaten zum Konfigurationszustand zu speichern. Alle drei SQL Server-Instanzen stellen einen verteilten Metadatenspeicher für den Cluster bereit.

Der Cluster-Manager kann die SQL Server-Instanzen in der Verfügbarkeitsgruppe abfragen und das Failover orchestrieren, um Hochverfügbarkeit zu gewährleisten. Auf einem Linux-Cluster ist Pacemaker der Cluster-Manager.

Ab SQL Server 2017 (14.x) CU 1 ist hohe Verfügbarkeit für eine Verfügbarkeitsgruppe mit CLUSTER_TYPE = EXTERNAL zwei synchronen Replikaten und nur einem Konfigurationsreplikat aktiviert. Das letztgenannte Replikat kann auf jeder Edition von SQL Server 2017 (14.x) CU 1 oder höhere Versionen (einschließlich 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 Cluster-Manager die Konfiguration der Verfügbarkeitsgruppe 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 Grundlegendes zum SQL Server-Ressourcen-Agent für Pacemaker.

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. Die folgenden Entwurfsmuster können für Verfügbarkeitsgruppen mit der Einstellung CLUSTER_TYPE = EXTERNAL in Lösungen verwendet werden, in denen Hochverfügbarkeit erforderlich ist:

• 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.

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	Leseskalierung	Hochverfügbarkeit und Datenschutz	Schutz von Daten
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1	2
Ausfall des primären Replikats	Automatisches Failover. Möglicherweise kommt es zu Datenverlusten. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen.	Automatisches Failover. 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 frühere Primärserver wiederhergestellt wurde und der Verfügbarkeitsgruppe als sekundärer Server wieder beigetreten ist.
Ausfall eines sekundären Replikats	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Verfügbare sekundäre Replikate sind für Lesevorgänge verfügbar.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. 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.

¹ Standard

Zwei synchrone Replikate

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

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
Ausfall des primären Replikats	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	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Es wird nicht gespiegelt, weshalb die Gefahr eines Datenverlusts besteht.	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.

¹ Standard

Zwei synchrone Replikate und ein 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:

1. Eine synchrone Replikation von Benutzerdaten wird auf einem sekundären Replikat ausgeführt. Dieser Vorgang schließt auch Metadaten zur Konfiguration der Verfügbarkeitsgruppe ein.
2. Eine synchrone Replikation von Metadaten zur Konfiguration der Verfügbarkeitsgruppe wird ausgeführt. 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 hingegen nicht. Das sekundäre Replikat befindet sich im synchronen Verfügbarkeitsmodus. Das Konfigurationsreplikat umfasst nicht die Datenbanken in der Verfügbarkeitsgruppe, sondern nur die Metadaten zur Verfügbarkeitsgruppe. Für die Konfigurationsdaten auf dem Konfigurationsreplikat wird synchron ein Commit ausgeführt.

Hinweis

Ab SQL Server 2017 (14.x) CU1 wird erstmals eine Verfügbarkeitsgruppe mit einem Konfigurationsreplikat eingesetzt. Alle SQL Server-Instanzen in der Verfügbarkeitsgruppe müssen SQL Server 2017 (14.x) CU1 oder höheren Versionen entsprechen.

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
Ausfall des primären Replikats	Automatisches Failover. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen. 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 Replikat besitzt Lese-/Schreibberechtigungen. Es wird nicht gespiegelt, weshalb die Gefahr eines Datenverlusts besteht (falls das primäre Replikat ausfällt und nicht wiederhergestellt werden kann). Es wird kein automatisches Failover ausgeführt, wenn auch das primäre Replikat 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 des Konfigurationsreplikats	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Es wird kein automatisches Failover ausgeführt, wenn auch das primäre Replikat ausfällt.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Es wird kein automatisches Failover ausgeführt, wenn auch das primäre Replikat ausfällt.
Ausfall des synchronen sekundären Replikats und des Konfigurationsreplikats	Die primäre Instanz ist für Lese- oder Schreibvorgänge nicht verfügbar. Es wird kein automatisches Failover ausgeführt.	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.

¹ Standard

Hinweis

Die SQL Server-Instanz, die das Konfigurationsreplikat hostet, kann auch andere Datenbanken hosten. Sie kann auch als Konfigurationsdatenbank für mehrere Verfügbarkeitsgruppen verwendet werden.

Anforderungen

• Alle Replikate in einer Verfügbarkeitsgruppe mit einem Konfigurationsreplikat müssen SQL Server 2017 (14.x) CU 1 oder höheren Versionen entsprechen.
• Jede Edition von SQL Server kann ein Konfigurationsreplikat hosten. Dies gilt auch für SQL Server Express.
• Für die Verfügbarkeitsgruppe ist mindestens ein sekundäres Replikat zusätzlich zum primären Replikat erforderlich.
• Die maximale Anzahl der Replikate pro SQL Server-Instanz ist unabhängig von der Anzahl der Konfigurationsreplikate. Für die Standard Edition von SQL Server werden maximal drei Replikate unterstützt, für die Enterprise Edition von SQL Server maximal neun.

Überlegungen

• Eine Verfügbarkeitsgruppe kann höchstens ein Konfigurationsreplikat enthalten.
• Ein Konfigurationsreplikat kann kein primäres Replikat sein.
• Sie können den Verfügbarkeitsmodus eines 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.
• Die Daten des Konfigurationsreplikats sind mit den Metadaten der Verfügbarkeitsgruppe synchron. 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 auf einer Instanz erstellen, die der SQL Server Express Edition entspricht.

Grundlegendes zum SQL Server-Ressourcen-Agent für Pacemaker

SQL Server 2017 (14.x) führte sequence_number ein, um sys.availability_groups anzuzeigen, ob ein Replikat, das als SYNCHRONOUS_COMMIT markiert 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 Antwort auf die Vorabbenachrichtigung erforderliche Anzahl von Replikaten ist 3 - 1 = 2. Es muss also zwei Replikate geben, damit das Failover ausgelöst werden kann. Wenn das primäre Replikat ausfällt und nur eines der sekundären Replikate auf die Vorabaktion zum Höherstufen reagiert, kann der Ressourcen-Agent nicht garantieren, dass das sekundäre Replikat, das geantwortet hat, die höchste sequence_number 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 der folgenden Tabelle wird das Ergebnis eines Ausfalls des primären oder sekundären Replikats in verschiedenen Ressourcenkonfigurationen von Verfügbarkeitsgruppen beschrieben:

Verfügbarkeitsgruppe – zwei Synchronisierungsreplikate

Konfiguration	Ausfall des primären Replikats	Ausfall eines sekundären Replikats
REQUIRED_COPIES_TO_COMMIT = 0	Sie müssen manuell ein FAILOVER ausstellen. Kann zu Datenverlust führen. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Es wird nicht gespiegelt, weshalb die Gefahr eines Datenverlusts besteht.
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.	Das primäre Replikat lehnt alle Verbindungen ab, bis das sekundäre wiederhergestellt ist.

¹ Standardverhalten des SQL Server-Ressourcen-Agents für Pacemaker

Verfügbarkeitsgruppe – drei Synchronisierungsreplikate

Konfiguration	Ausfall des primären Replikats	Ausfall eines sekundären Replikats
REQUIRED_COPIES_TO_COMMIT = 0	Sie müssen manuell ein FAILOVER erteilen. Kann zu Datenverlust führen. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen.
REQUIRED_COPIES_TO_COMMIT = 1 1	Der Cluster gibt automatisch FAILOVER aus. Kein Datenverlust. Das neue primäre Replikat besitzt Lese-/Schreibberechtigungen.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen.

¹ Standardverhalten des SQL Server-Ressourcen-Agents für Pacemaker

Zugehöriger Inhalt

• Verfügbarkeitsgruppen für SQL Server für Linux