Verfügbarkeitsgruppen für SQL Server unter Linux

Gilt für:SQL Server unter Linux

In diesem Artikel werden die Merkmale von Verfügbarkeitsgruppen unter Linux-basierten SQL Server-Installationen beschrieben. Außerdem werden die Unterschiede zwischen auf Linux-und Windows Server-Failoverclustern (WSFC) basierenden Tags behandelt. Siehe Was ist eine Always On-Verfügbarkeitsgruppe? für die Grundlagen von AGs, da sie unter Windows und Linux gleich funktionieren, mit Ausnahme von WSFC.

Hinweis

In Verfügbarkeitsgruppen, die kein Windows Server Failover Clustering (WSFC) nutzen, z. B. schreibgeschützte Verfügbarkeitsgruppen oder Verfügbarkeitsgruppen unter Linux, zeigen Spalten in den Verfügbarkeitsgruppen-DMVs im Zusammenhang mit dem Cluster möglicherweise Daten zu einem internen Standardcluster an. Diese Spalten sind nur für die interne Verwendung vorgesehen und können ignoriert werden.

Im Allgemeinen entsprechen die Verfügbarkeitsgruppen unter SQL Server für Linux den WSFC-basierten Implementierungen. Das bedeutet, dass alle Einschränkungen und Features (mit einigen Ausnahmen) identisch sind. Die Hauptunterschiede bestehen in Folgendem:

Microsoft Distributed Transaction Coordinator (DTC) wird unter Linux ab SQL Server 2017 CU 16 unterstützt. In Verfügbarkeitsgruppen unter Linux wird DTC jedoch noch nicht unterstützt. Wenn Ihre Anwendungen verteilte Transaktionen verwenden und eine Verfügbarkeitsgruppe benötigen, stellen Sie SQL Server unter Windows bereit.
Für Linux-basierte Bereitstellungen, die Hochverfügbarkeit erfordern, verwenden Sie für das Clustering Pacemaker anstelle eines WSFC.
Im Gegensatz zu den meisten Konfiguration für Verfügbarkeitsgruppen unter Windows (außer im Workgroupclusterszenario) ist Active Directory Domain Services (AD DS) für Pacemaker nicht erforderlich.
Das Failover einer Verfügbarkeitsgruppe von einem Knoten auf einen anderen unterscheidet sich zwischen Linux und Windows.
Bestimmte Einstellungen wie required_synchronized_secondaries_to_commit können unter Linux nur über Pacemaker geändert werden, während bei einer WSFC-basierten Installation Transact-SQL verwendet wird.

Anzahl der Replikate und Clusterknoten

Eine Verfügbarkeitsgruppe in der SQL Server Standard-Edition kann insgesamt über zwei Replikate verfügen: ein primäres Replikat und ein sekundäres Replikat, das nur zu Verfügbarkeitszwecken verwendet werden kann. Es kann nicht für andere Zwecke wie lesbare Abfragen verwendet werden. Eine Verfügbarkeitsgruppe in der SQL Server Enterprise-Edition kann insgesamt über bis zu neun Replikate verfügen: ein primäres Replikat und bis zu acht sekundäre Replikate, von denen bis zu drei (einschließlich des primären Replikats) synchron sein können. Wenn ein zugrunde liegender Cluster verwendet wird, können maximal 16 Knoten vorhanden sein, wenn Corosync beteiligt ist. Eine Verfügbarkeitsgruppe kann mit der SQL Server Enterprise-Edition neun von 16 Knoten umfassen und mit der SQL Server Standard-Edition zwei Knoten.

Für eine Konfiguration mit zwei Replikaten, für die ein automatisches Failover auf ein anderes Replikat möglich sein muss, muss unter Reine Konfigurationsreplikate und Quoren beschrieben ein Replikat verwendet werden, das ausschließlich für die Konfiguration konfiguriert ist. Replikate, die sich nur auf die Konfiguration beziehen, wurden mit SQL Server 2017 (14.x) Cumulative Update 1 (CU 1) eingeführt, sodass dies die Mindestversion sein sollte, die für diese Konfiguration bereitgestellt wird.

Wenn Pacemaker verwendet wird, muss die Software ordnungsgemäß konfiguriert werden, damit sie weiterhin ausgeführt wird. Das bedeutet, dass Quorum und Fencing eines ausgefallenen Knotens aus Pacemaker-Perspektive ordnungsgemäß implementiert werden müssen, zusätzlich zu den SQL Server-Anforderungen, wie z. B. ein Replikat nur für die Konfiguration.

Lesbare sekundäre Replikate werden nur mit der SQL Server Enterprise-Edition unterstützt.

Clustertyp und Failovermodus

In SQL Server 2017 (14.x) wurden Clustertypen für Verfügbarkeitsgruppen eingeführt. Für Linux gibt es zwei gültige Werte: External und None. Ein Clustertyp External bedeutet, dass Pacemaker unterhalb der AG verwendet wird. Die Verwendung von External als Clustertyp erfordert, dass der Failover-Modus ebenfalls auf External eingestellt ist (ebenfalls neu in SQL Server 2017 (14.x)). Das automatische Failover wird unterstützt, aber im Gegensatz zu einem WSFC wird der Failovermodus bei Verwendung von Pacemaker nicht automatisch auf „EXTERNAL“ festgelegt. Im Gegensatz zu einem WSFC wird der Pacemaker-Teil der Verfügbarkeitsgruppe nach der Konfiguration der Verfügbarkeitsgruppe erstellt.

Ein Clustertyp None bedeutet, dass Pacemaker weder erforderlich ist noch von der AG verwendet wird. Selbst auf Servern, auf denen Pacemaker konfiguriert ist, wird eine AG, die mit dem Clustertyp None konfiguriert ist, von Pacemaker weder gesehen noch verwaltet. Der Clustertyp „NONE“ unterstützt nur manuelles Failover von einem primären zu einem sekundären Replikat. Eine AG, die mit „None“ erstellt wurde, ist hauptsächlich auf Upgrades und die horizontale Leseskalierung ausgerichtet. Auch wenn es in Szenarien wie der Notfallwiederherstellung oder der lokalen Verfügbarkeit funktioniert, bei denen kein automatisches Failover erforderlich ist, wird es nicht empfohlen. Ohne Pacemaker ist der Listenerverlauf zudem komplexer.

Der Clustertyp wird in der SQL Serverdynamischen Verwaltungssicht (DMV)sys.availability_groups in den Spalten cluster_type und cluster_type_desc gespeichert.

required_synchronized_secondaries_to_commit

In SQL Server 2017 (14.x) ist nun die neue Einstellung required_synchronized_secondaries_to_commit vorhanden, die von Verfügbarkeitsgruppen verwendet wird. Über diese wird der Verfügbarkeitsgruppe die Anzahl der sekundären Replikate mitgeteilt, die auf das primäre Replikat abgestimmt sein müssen. Dadurch können beispielsweise das automatische Failover (nur bei Integration mit Pacemaker und dem Clustertyp „EXTERNAL“) ermöglicht und das Verhalten der Verfügbarkeit des Replikats gesteuert werden, wenn die richtige Anzahl sekundärer Replikate online oder offline ist. Weitere Informationen zu diesem Thema finden Sie unter Hochverfügbarkeit und Schutz von Daten für Verfügbarkeitsgruppenkonfigurationen. Der Wert required_synchronized_secondaries_to_commit wird standardmäßig festgelegt und von Pacemaker/SQL Serververwaltet. Sie können diesen Wert manuell überschreiben.

Die Kombination von required_synchronized_secondaries_to_commit und der neuen Sequenznummer (in sys.availability_groups gespeichert) informiert Pacemaker und SQL Server darüber, dass beispielsweise ein automatisches Failover möglich ist. In diesem Fall hätte ein sekundäres Replikat dieselbe Sequenznummer wie das primäre, d. h. es ist auf dem neuesten Stand mit allen aktuellen Konfigurationsinformationen.

Für required_synchronized_secondaries_to_commit können drei Werte festgelegt werden: 0, 1 oder 2. Sie steuern, was geschieht, wenn ein Replikat nicht mehr verfügbar ist. Die Zahlen entsprechen der Anzahl von sekundären Replikaten, die mit dem primären Replikat synchronisiert werden müssen. Das Verhalten ist unter Linux wie folgt:

Einstellung	Beschreibung
`0`	Sekundäre Replikate müssen nicht mit dem primären Replikat synchronisiert sein. Sollten die Sekundärsysteme jedoch nicht synchronisiert sein, gibt es keine automatische Ausfallsicherung.
`1`	Ein sekundäres Replikat muss sich in einem mit dem primären synchronisierten Zustand befinden; eine automatische Ausfallsicherung ist möglich. Die primäre Datenbank ist erst verfügbar, wenn ein sekundäres synchrones Replikat verfügbar ist.
`2`	Beide sekundären Replikate in einer AG-Konfiguration mit drei oder mehr Knoten müssen mit dem primären synchronisiert werden; eine automatische Ausfallsicherung ist möglich.

required_synchronized_secondaries_to_commit kontrolliert nicht nur das Verhalten von Failovers mit synchronen Replikaten, sondern auch den Datenverlust. Bei einem Wert von 1 oder 2 muss immer ein sekundäres Replikat synchronisiert werden, um Datenredundanz zu gewährleisten. Dies bedeutet, dass kein Datenverlust auftritt.

Verwenden Sie die folgende Syntax, um den Wert von required_synchronized_secondaries_to_commit zu ändern:

Hinweis

Das Ändern des Werts bewirkt, dass die Ressource neu gestartet wird. Es kommt zu einem kurzen Ausfall. Sie können diesen Ausfall nur vermeiden, indem Sie die Ressource so konfigurieren, dass sie vorübergehend nicht vom Cluster verwaltet wird.

Red Hat Enterprise Linux (RHEL) und Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

In diesem Beispiel ist <AGResourceName> der Name der für die AG konfigurierten Ressource und <value> ist 0, 1 oder 2. Wenn Sie den Standardzustand wiederherstellen möchten, dass Pacemaker den Parameter verwaltet, führen Sie die gleiche Anweisung ohne Wert (value) aus.

Ein automatisches Failover einer Verfügbarkeitsgruppe ist möglich, wenn die folgenden Bedingungen erfüllt sind:

Das primäre und das sekundäre Replikat sind auf synchrone Datenverschiebung festgelegt.
Das sekundäre Replikat weist den Status „Synchronisiert“ (keine Synchronisierung) auf, die beiden Replikate befinden sich also am selben Datenpunkt.
Der Clustertyp ist auf „EXTERNAL“ festgelegt. Ein automatisches Failover ist mit dem Clustertyp „NONE“ nicht möglich.
Der Wert sequence_number des sekundären Replikats, das zum primären Replikat werden soll, weist die höchste Sequenznummer auf. Das bedeutet, dass der sequence_number-Wert des sekundären Replikats dem Wert des ursprünglichen primären Replikats entspricht.

Wenn diese Bedingungen erfüllt sind und der Server, der das primäre Replikat hostet, ausfällt, wechselt die AG den Besitzer auf ein synchrones Replikat. Das Verhalten von synchronen Replikaten (maximal ein primäres und zwei sekundäre Replikate) kann weiter von required_synchronized_secondaries_to_commit gesteuert werden. Das gilt für Verfügbarkeitsgruppen unter Windows und Linux, die Konfiguration unterscheidet sich jedoch. Unter Linux wird der Wert automatisch vom Cluster auf der Verfügbarkeitsgruppenressource konfiguriert.

Reine Konfigurationsreplikate und Quoren

Ein konfigurationsbasiertes Replik wurde eingeführt, um Einschränkungen bei der Quorum-Verarbeitung mit Pacemaker zu beheben, insbesondere beim Fencing eines ausgefallenen Knotens. Eine Konfiguration mit zwei Knoten funktioniert für eine AG nicht. Bei einer FCI können die von Pacemaker bereitgestellten Quorum-Mechanismen geeignet sein, da alle FCI-Failover-Abstimmungen auf der Clusterebene erfolgen. Bei einer Verfügbarkeitsgruppe erfolgt die Vermittlung unter Linux in SQL Server. Dort werden alle Metadaten gespeichert. In diesem Fall können reine Konfigurationsreplikate genutzt werden.

Ohne weitere Schritte wären ein dritter Knoten und mindestens ein synchronisiertes Replikat erforderlich. Das reine Konfigurationsreplikat speichert die Verfügbarkeitsgruppenkonfiguration in der master-Datenbank. Das gleiche gilt für die anderen Replikate in der Verfügbarkeitsgruppenkonfiguration. Das reine Konfigurationsreplikat verfügt nicht über die Benutzerdatenbanken, die an der Verfügbarkeitsgruppe teilnehmen. Die Konfigurationsdaten werden synchron vom primären Replikat gesendet. Diese Konfigurationsdaten werden dann bei automatischen oder manuellen Failover-Vorgängen verwendet.

Damit eine Verfügbarkeitsgruppe das Quorum beibehalten und automatische Failovers für den Clustertyp „EXTERNAL“ ermöglichen kann, muss eine der folgenden Bedingungen erfüllt sein:

Drei synchrone Replikate müssen vorhanden sein (nur SQL Server Enterprise-Edition) oder
Zwei Replikate (primär und sekundär) und ein reines Konfigurationsreplikat müssen vorhanden sein.

Ein manuelles Failover kann unabhängig davon durchgeführt werden, ob der Clustertyp „EXTERNAL“ oder „NONE“ für Verfügbarkeitsgruppenkonfigurationen verwendet wird. Ein reines Konfigurationsreplikat kann zwar für eine Verfügbarkeitsgruppe konfiguriert werden, deren Clustertyp „NONE“ ist, doch diese Vorgehensweise wird nicht empfohlen, da sie die Bereitstellung erschwert. Ändern Sie bei diesen Konfigurationen required_synchronized_secondaries_to_commit manuell so, dass der Wert mindestens 1 beträgt, sodass es mindestens ein synchronisiertes Replikat gibt.

Ein reines Konfigurationsreplikat kann in jeder SQL Server-Edition (einschließlich SQL Server Express) gehostet werden. Dies minimiert die Lizenzkosten und stellt sicher, dass es mit AGs in der SQL Server Standard Edition funktioniert. Das bedeutet, dass der dritte erforderliche Server lediglich die Mindestspezifikation für SQL Server erfüllen muss, da er keinen Benutzertransaktionsdatenverkehr für die Verfügbarkeitsgruppe empfängt.

Wenn ein reines Konfigurationsreplikat verwendet wird, weist es folgendes Verhalten auf:

required_synchronized_secondaries_to_commit ist standardmäßig auf „0“ festgelegt. Der Wert kann bei Bedarf manuell in „1“ geändert werden.
Wenn das primäre Replikat ausfällt und required_synchronized_secondaries_to_commit gleich 0 ist, wird das sekundäre Replikat zum neuen primären Replikat und steht sowohl zum Lesen als auch zum Schreiben zur Verfügung. Wenn der Wert 1 ist, erfolgt eine automatische Ausfallsicherung, die jedoch keine neuen Transaktionen akzeptiert, bis das andere Replikat online ist.
Wenn ein sekundäres Replikat ausfällt und required_synchronized_secondaries_to_commit gleich 0 ist, nimmt das primäre Replikat weiterhin Transaktionen an, aber wenn das primäre Replikat zu diesem Zeitpunkt ausfällt, gibt es weder einen Schutz für die Daten noch ist ein Failover möglich (manuell oder automatisch), da kein sekundäres Replikat verfügbar ist.
Wenn das Replikat, das nur die Konfiguration enthält, ausfällt, funktioniert die AG normal, aber es ist kein automatisches Failover möglich.
Wenn sowohl das synchrone sekundäre Replikat als auch das Replikat, das nur für die Konfiguration zuständig ist, ausfallen, kann das primäre Replikat keine Transaktionen annehmen und es gibt keine Möglichkeit für das primäre Replikat, den Ausfall zu kompensieren.

Mehrere Verfügbarkeitsgruppen

Pro Pacemaker-Cluster oder -Servergruppe kann mehr als eine Verfügbarkeitsgruppe erstellt werden. Die Systemressourcen stellen die einzige Einschränkung dar. Die Eigentümerschaft der AG wird durch die Primärdaten angezeigt. Unterschiedliche Verfügbarkeitsgruppen können sich im Besitz verschiedener Knoten befinden. Sie müssen nicht alle auf demselben Knoten ausgeführt werden.

Laufwerk und Ordnerpfad für Datenbanken

Bei Windows-basierten Verfügbarkeitsgruppen sollten das Laufwerk und die Ordnerstruktur für die Benutzerdatenbanken, die an einer Verfügbarkeitsgruppe teilnehmen, identisch sein. Wenn sich die Benutzerdatenbank auf Server A beispielsweise unter /var/opt/mssql/userdata befindet, sollte der gleiche Ordner auf Server B vorhanden sein. Die einzige Ausnahme wird im Abschnitt Interoperabilität mit Windows-basierten Verfügbarkeitsgruppen und Replikaten behandelt.

Der Listener unter Linux

Der Listener ist eine optionale Funktionalität für Verfügbarkeitsgruppen. Er bietet einen einzigen Einstiegspunkt für alle Verbindungen (Lese-/Schreibzugriff auf das primäre Replikat und/oder schreibgeschützter Zugriff auf sekundäre Replikate), damit Anwendungen und Endbenutzer nicht darüber informiert sein müssen, auf welchem Server die Daten gehostet werden. In einem WSFC besteht dieser aus einer Netzwerknamenressource und einer IP-Ressource, die dann (bei Bedarf) in AD DS und als DNS registriert wird. In Kombination mit der Verfügbarkeitsgruppenressource wird diese Abstraktion bereitgestellt. Für weitere Informationen über einen Empfänger siehe Verbindung mit einem Empfänger der Always On-Verfügbarkeitsgruppe.

Der Listener unter Linux ist anders konfiguriert, aber seine Funktionalität ist identisch. Das Konzept der Netzwerknamenressource ist in Pacemaker nicht vorhanden, und es wird kein Objekt in AD DS erstellt. Es gibt nur eine IP-Adressressource, die in Pacemaker erstellt und auf einem beliebigen Knoten ausgeführt werden kann. Es muss ein Eintrag erstellt werden, der der IP-Ressource für den Listener im DNS mit einem Anzeigenamen zugeordnet ist. Die IP-Ressource für den Empfänger ist nur auf dem Server aktiv, auf dem das primäre Replikat für diese Verfügbarkeitsgruppe gehostet wird.

Wenn Pacemaker verwendet und eine IP-Adressressource erstellt wird, die dem Empfänger zugeordnet ist, kommt es zu einem kurzen Ausfall, weil die IP-Adresse auf einem Server angehalten und auf dem anderen gestartet wird, unabhängig davon, ob es sich um ein automatisches oder manuelles Failover handelt. Dadurch wird zwar durch die Kombination aus einem einzelnen Namen und einer IP-Adresse eine Abstraktion ermöglicht, doch der Ausfall wird nicht maskiert. Eine Anwendung muss den Verbindungsverlust mithilfe einer Funktion zum Erkennen und Wiederherstellen der Verbindung bewältigen können.

Die Kombination aus dem DNS-Namen und der IP-Adresse genügt jedoch nicht, um alle Funktionen zu bieten, die ein Listener auf einem WSFC bietet (z. B. schreibgeschütztes Routing für sekundäre Replikate). Wenn Sie eine AG konfigurieren, muss noch ein Empfänger in SQL Server konfiguriert werden. Das wird im Assistenten und in der Syntax von Transact-SQL deutlich. Es gibt zwei Möglichkeiten, die gleiche Funktionsweise wie unter Windows durch Konfiguration zu erreichen:

Bei einer AG mit dem Clustertyp External sollte die IP-Adresse, die mit dem in SQL Server erstellten Empfänger verbunden ist, die IP-Adresse der in Pacemaker erstellten Ressource sein.
Bei einer Verfügbarkeitsgruppe, die den Clustertyp „NONE“ aufweist, sollten Sie die IP-Adresse verwenden, die dem primären Replikat zugeordnet ist.

Die Instanz, die der bereitgestellten IP-Adresse zugeordnet ist, koordiniert dann beispielsweise schreibgeschützte Routinganforderungen für Anwendungen.

Interoperabilität mit Windows-basierten Verfügbarkeitsgruppen und Replikaten

Eine Verfügbarkeitsgruppe, die den Clustertyp „EXTERNAL“ oder einen nicht in WSFCs verfügbaren Clustertyp aufweist, kann keine plattformübergreifenden Replikate besitzen. Dies gilt unabhängig davon, ob die Verfügbarkeitsgruppe für die SQL Server Standard-Edition oder die SQL Server Enterprise-Edition verwendet wird. Das bedeutet, dass es in einer herkömmlichen Verfügbarkeitsgruppenkonfiguration mit einem zugrunde liegenden Cluster nicht möglich ist, dass ein Replikat sich auf einem WSFC und ein anderes unter Linux mit Pacemaker befindet.

Eine Verfügbarkeitsgruppe mit dem Clustertyp „NONE“ kann Replikate auf unterschiedlichen Betriebssystemen besitzen. Es können also Linux- und Windows-basierte Replikate in derselben Verfügbarkeitsgruppe vorhanden sein. Im Folgenden sehen Sie ein Beispiel, bei dem das primäre Replikat Windows-basiert ist, während das sekundäre sich auf einer Linux-Distribution befindet.

Diagramm von Hybrid None.

Auch eine verteilte Verfügbarkeitsgruppe kann betriebssystemübergreifende Replikate besitzen. Die zugrunde liegenden Verfügbarkeitsgruppen sind an die Regeln der entsprechenden Konfiguration gebunden. So können beispielsweise eine für Linux konfigurierte Verfügbarkeitsgruppe mit dem Clustertyp EXTERNAL und eine mithilfe eines WSFC konfigurierte Verfügbarkeitsgruppe miteinander verknüpft sein. Betrachten Sie das folgende Beispiel:

Diagramm der Hybrid Dist AG.

Feedback

War diese Seite hilfreich?

Last updated on 2025-10-20