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

Gilt für: SQL Server – 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.

SQL Server 2017 (14.x) CU1 ermöglicht für eine Verfügbarkeitsgruppe mit der Einstellung CLUSTER_TYPE = EXTERNAL Hochverfügbarkeit für zwei synchrone Replikate und für ein Replikat, das ausschließlich zur Konfiguration verwendet wird. 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

Ab SQL Server 2017 (14.x) wird die Einstellung REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT für Clusterressourcen verwendet. Diese gewährleistet, dass die angegebenen sekundären Replikate die Transaktionsdaten in ein Protokoll schreiben, bevor das primäre Replikat für jede Transaktion einen Commit ausführt. 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. Das neue primäre Replikat steht erst dann für Benutzer-Updatetransaktionen zur Verfügung, wenn das vorherige primäre Replikat wiederhergestellt wurde und der Verfügbarkeitsgruppe als sekundäres Replikat beigetreten ist.
Ausfall eines sekundären Replikats	Das primäre Replikat besitzt Lese-/Schreibberechtigungen.	Das primäre Replikat besitzt Lese-/Schreibberechtigungen.	Das primäre Replikat steht erst dann für Benutzer-Updatetransaktionen zur Verfügung, wenn das ausgefallene sekundäre Replikat wiederhergestellt wurde und der Verfügbarkeitsgruppe beigetreten ist.

¹ 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. Das neue primäre Replikat steht erst dann für Benutzer-Updatetransaktionen zur Verfügung, wenn das vorherige primäre Replikat wiederhergestellt wurde und der Verfügbarkeitsgruppe als sekundäres Replikat beigetreten ist.
Ausfall eines sekundären Replikats	Das primäre Replikat besitzt Lese-/Schreibberechtigungen. Es wird nicht gespiegelt, weshalb die Gefahr eines Datenverlusts besteht.	Das primäre Replikat steht erst dann für Benutzer-Updatetransaktionen zur Verfügung, wenn das sekundäre Replikat wiederhergestellt wurde.

¹ 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. Das neue primäre Replikat steht nicht für Benutzer-Updatetransaktionen zur Verfügung.
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.	Das primäre Replikat steht nicht für Benutzertransaktionen zur Verfügung. 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	Das primäre Replikat steht nicht für Benutzertransaktionen zur Verfügung. Es wird kein automatisches Failover ausgeführt.	Das primäre Replikat steht nicht für Benutzertransaktionen zur Verfügung. 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

In SQL Server 2017 (14.x) wurde sequence_number in sys.availability_groups eingeführt, um anzuzeigen, ob ein als SYNCHRONOUS_COMMIT markiertes Replikat auf dem neuesten Stand ist. sequence_number ist ein monoton ansteigender BIGINT-Datentyp, der darstellt, wie aktuell das lokale Verfügbarkeitsgruppenreplikat in Bezug auf den Rest der Replikate in der Verfügbarkeitsgruppe ist. Durch das Durchführen von Failovern, Hinzufügen oder Entfernen von Replikaten und andere Verfügbarkeitsgruppenvorgänge wird diese Zahl aktualisiert. Die Zahl wird auf dem primären Replikat aktualisiert und anschließend an sekundäre Replikate übertragen. Daher verfügt ein aktualisiertes sekundäres Replikat über die gleiche sequence_number wie das primäre Replikat.

Wenn Pacemaker entscheidet, ein Replikat zum einem primären heraufzustufen, wird zuerst eine Benachrichtigung an alle Replikate gesendet (diese Benachrichtigung wird Vorabbenachrichtigung genannt), um die Sequenznummer zu extrahieren und zu speichern. Wenn Pacemaker als Nächstes tatsächlich versucht, ein Replikat zu einem primären heraufzustufen, stuft das Replikat sich selbst nur herauf, wenn seine Sequenznummer die höchste aller Replikate ist, und lehnt andernfalls den Heraufstufung ab. Auf diese Weise kann nur das Replikat mit der höchsten Sequenznummer zu einem primären heraufgestuft werden, sodass es nicht zu Datenverlust kommt.

Diese Heraufstufung funktioniert nur sicher, solange mindestens ein für die Heraufstufung verfügbares Replikat über die gleiche Sequenznummer wie das bisherige primäre Replikat verfügt. Der Pacemaker-Ressourcen-Agent REQUIRED_COPIES_TO_COMMIT legt standardmäßig automatisch fest, sodass mindestens ein sekundäres Replikat mit synchronem Commit auf dem neuesten Stand und als Ziel für ein automatisches Failover 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.

Verwenden wir als Beispiel eine Verfügbarkeitsgruppe mit drei synchronen Replikaten: einem primären Replikat und zwei sekundären Replikate mit synchronem Commit.

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

Ein Benutzer kann das Standardverhalten bei Bedarf überschreiben und die Verfügbarkeitsgruppenressource so konfigurieren, dass REQUIRED_COPIES_TO_COMMIT nicht wie oben beschrieben automatisch festgelegt wird.

Wichtig

Wenn REQUIRED_COPIES_TO_COMMIT 0 entspricht, besteht das Risiko von Datenverlust. Wenn das primäre Replikat ausfällt, löst der Ressourcen-Agent nicht automatisch ein Failover aus. Der Benutzer muss entscheiden, ob gewartet wird, bis das primäre Replikat wiederhergestellt wird, oder ob ein manuelles Failover durchgeführt werden soll.

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, der crm (unter SLES) nutzt, ist:

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. Das bedeutet, dass das primäre vorübergehend zum sekundären Replikat herabgestuft und dann erneut höhergestuft wird. Deswegen sind Schreibvorgänge vorübergehend nicht verfügbar. Der neue Wert für REQUIRED_COPIES_TO_COMMIT wird erst nach dem Neustart der Replikate festgelegt, also nicht gleichzeitig mit dem pcs-Befehl.

Ausgleich zwischen Hochverfügbarkeit und Datenschutz

Das oben beschriebene Standardverhalten gilt auch für den Fall von zwei synchronen Replikaten (ein primäres und ein sekundäres). Pacemaker legt REQUIRED_COPIES_TO_COMMIT = 1 auf das Standardverhalten fest, um sicherzustellen, dass das sekundäre Replikat für maximalen Datenschutz immer auf dem neuesten Stand ist.

Warnung

Dies geht mit einem höheren Risiko von Nichtverfügbarkeit des primären Replikats aufgrund von geplanten und ungeplanten Ausfällen auf dem sekundären Replikat einher. Der Benutzer kann das Standardverhalten des Ressourcen-Agents ändern und REQUIRED_COPIES_TO_COMMIT wahlweise auf 0 überschreiben:

sudo pcs resource update <ag1> required_copies_to_commit=0

Wenn die Überschreibung beendet ist, nutzt der Ressourcen-Agent die neue Einstellung für REQUIRED_COPIES_TO_COMMIT und berechnet sie nicht mehr. Benutzer müssen diese entsprechend 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	Der Benutzer muss ein manuelles FAILOVER durchführen. Möglicherweise kommt es zu Datenverlusten. Neues primäres Replikat ist R/W	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	Der Benutzer muss ein manuelles FAILOVER durchführen. Möglicherweise kommt es zu Datenverlusten. Neues primäres Replikat ist R/W	Primäres Replikat ist R/W
REQUIRED_COPIES_TO_COMMIT = 1 1	Der Cluster gibt automatisch FAILOVER aus. Kein Datenverlust. Neues primäres Replikat ist R/W	Primäres Replikat ist R/W

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

Zugehöriger Inhalt

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