Freigeben über

Unterschiede zwischen den Verfügbarkeitsmodi einer Always On-Verfügbarkeitsgruppe

Gilt für:SQL Server

In Always On-Verfügbarkeitsgruppenist der Verfügbarkeitsmodus eine Replikateigenschaft, die bestimmt, ob ein angegebenes Verfügbarkeitsreplikat im Modus für synchrone Commits ausgeführt werden kann. Für jedes Verfügbarkeitsreplikat muss für den Verfügbarkeitsmodus entweder der synchrone Commit-Modus, der asynchroner Commit-Modus oder der reine Konfigurationsmodus konfiguriert werden.

Wenn das primäre Replikat für den asynchronen Commit-Modus konfiguriert ist, wartet es nicht, bis ein sekundäres Replikat eingehende Transaktionsprotokolldatensätze auf den Datenträger schreibt (um das Protokoll zu härten).

Wenn ein bestimmtes sekundäres Replikat für den Modus für asynchrone Commits konfiguriert ist, wartet das primäre Replikat nicht, bis das betreffende sekundäre Replikat das Protokoll festgeschrieben hat. Wenn sowohl das primäre Replikat als auch ein angegebenes sekundäres Replikat für den Modus für synchrone Commits konfiguriert sind, wartet das primäre Replikat, bis das sekundäre Replikat bestätigt, dass es das Protokoll festgeschrieben hat (es sei denn, das sekundäre Replikat konnte innerhalb des Sitzungstimeouts für das primäre Replikat keinen Ping-Befehl an dieses senden).

Hinweis

Wenn ein synchrones commit-sekundäres Replikat den Sitzungstimeoutzeitraum des primären Replikats überschreitet (Standardwert ist 10 Sekunden), markiert das primäre Replikat vorübergehend den Synchronisierungsstatus jeder Datenbank in diesem sekundären Replikat als NOT SYNCHRONIZING und den Replikatstatus als NOT_HEALTHY. Wenn das sekundäre Replikat die Verbindung mit dem primären Replikat erneut herstellt, kehren sie in den synchronen Commit-Modus zurück.

Unterstützte Verfügbarkeitsmodi

AlwaysOn-Verfügbarkeitsgruppen unterstützen drei Verfügbarkeitsmodi:

  • Asynchroner Commit-Modus
  • Synchroner Commit-Modus
  • Nur Konfigurationsmodus

Der Modus für asynchrone Commits ist eine Wiederherstellungslösung für Notfälle, die gut funktioniert, wenn die Verfügbarkeitsreplikate über weite Entfernungen verteilt sind. Wenn jedes sekundäre Replikat im Modus für asynchrone Commits ausgeführt wird, wartet das primäre Replikat nicht, bis ein sekundäres Replikat das Protokoll festschreibt. Stattdessen sendet das primäre Replikat die Transaktionsbestätigung, unmittelbar nachdem es einen Protokolldatensatz in die lokale Protokolldatei geschrieben hat, an den Client. Das primäre Replikat wird mit minimaler Transaktionswartezeit bezogen auf ein sekundäres Replikat ausgeführt, das für den Modus für asynchrone Commits konfiguriert wurde.

Wenn das aktuelle primäre Replikat für den Verfügbarkeitsmodus „Asynchroner Commit“ konfiguriert ist, führt es für alle sekundären Replikate, unabhängig von deren Verfügbarkeitsmoduseinstellungen, asynchron ein Commit für Transaktionen aus.

Weitere Informationen finden Sie im Asynchronous-Commit Verfügbarkeitsmodus in diesem Artikel weiter unten.

ImModus für synchrone Commits hat Hochverfügbarkeit Vorrang vor Leistung, und dies hat eine größere Transaktionswartezeit zur Folge. Im Modus für synchrone Commits wird mit dem Senden der Transaktionsbestätigung an den Client gewartet, bis das sekundäre Replikat das Protokoll auf dem Datenträger festgeschrieben hat. Wenn die Datensynchronisierung für eine sekundäre Datenbank beginnt, fängt das sekundäre Replikat an, eingehende Protokolldatensätze von der entsprechenden primären Datenbank zu übernehmen. Sobald jeder Protokolldatensatz gehärtet wurde, gibt die sekundäre Datenbank den Status ein SYNCHRONIZED . Anschließend wird jede neue Transaktion vom sekundären Replikat festgeschrieben, bevor der Protokolleintrag in die lokale Protokolldatei geschrieben wird. Wenn alle sekundären Datenbanken eines bestimmten sekundären Replikats synchronisiert sind, unterstützt der synchrone Commit-Modus manuelles Failover und optional automatisches Failover.

Weitere Informationen finden Sie weiter unten in diesem Artikel unter Synchronous-Commit Verfügbarkeitsmodus.

Der Konfigurationsmodus gilt nur für Verfügbarkeitsgruppen, die sich nicht auf einem Windows Server-Failovercluster befinden. Ein Replikat im Konfigurationsmodus enthält keine Benutzerdaten. Im Modus "nur Konfiguration" speichert die Replikatdatenbank master die Metadaten zur Konfiguration der Verfügbarkeitsgruppe. Weitere Informationen finden Sie unter High availability and data protection for Availability Group configurations (Hochverfügbarkeit und Datenschutz für Verfügbarkeitsgruppenkonfigurationen).

In der folgenden Abbildung wird eine Verfügbarkeitsgruppe mit fünf Verfügbarkeitsreplikaten angezeigt. Das primäre Replikat und ein sekundäres Replikat sind für den Modus für synchrone Commits mit automatischem Failover konfiguriert. Ein weiteres sekundäres Replikat ist für den Modus für synchrone Commits ausschließlich mit geplantem manuellen Failover konfiguriert, und zwei sekundäre Replikate sind für den Modus für asynchrone Commits konfiguriert, der nur erzwungene manuelle Failover (normalerweise als erzwungene Failoverbezeichnet) unterstützt.

Diagramm der Verfügbarkeit und Failovermodi von Replikaten.

Das Synchronisierungs- und Failoververhalten zwischen zwei Verfügbarkeitsreplikaten hängt vom Verfügbarkeitsmodus beider Replikate ab. Beispielsweise müssen sowohl die primäre Replik als auch die sekundäre Replik für synchronen Commit konfiguriert sein, damit er stattfindet. Ebenso müssen beide Replikate für automatisches Failover konfiguriert sein. Daher kann das Verhalten für das zuvor veranschaulichte Bereitstellungsszenario in der folgenden Tabelle zusammengefasst werden, in der das Verhalten mit jedem potenziellen primären Replikat untersucht wird:

Derzeitiges primäres Replikat Automatische Failoverziele Verhalten im synchronen Commit-Modus mit Verhalten im asynchronen Commit-Modus mit Automatisches Failover möglich
01 02 02 und 03 04 Ja
02 01 01 und 03 04 Ja
03 01 und 02 04 Nein
04 01, 02 und 03 Nein

Normalerweise wird Knoten 04 als Replikat mit asynchronem Commit an einem Standort für die Notfallwiederherstellung bereitgestellt. Die Tatsache, dass die Knoten 01, 02 und 03 nach einem Failover auf Knoten 04 im Modus für asynchrone Commits verbleiben, hilft, einen Leistungsabfall in der Verfügbarkeitsgruppe zu vermeiden, der infolge einer hohen Netzwerklatenz zwischen den beiden Standorten auftritt.

Asynchronous-Commit Availability Mode

Im Modus für asynchrone Commits wird das sekundäre Replikat nie mit dem primären Replikat synchronisiert. Obwohl eine gegebene sekundäre Datenbank den gleichen Datenbestand wie eine entsprechende primäre Datenbank aufweisen kann, kann der Datenbestand jeder sekundären Datenbank jederzeit älter sein. Der Asynchrone Commit-Modus kann in einem Notfallwiederherstellungsszenario hilfreich sein, in dem das primäre Replikat und das sekundäre Replikat durch einen erheblichen Abstand voneinander getrennt sind. In solchen Fällen möchten Sie nicht, dass kleine Fehler das primäre Replikat beeinträchtigen, oder es handelt sich um Situationen, in denen die Leistung wichtiger ist als der synchronisierte Datenschutz. Da das primäre Replikat nicht auf Bestätigungen aus dem sekundären Replikat wartet, wirken sich Probleme im sekundären Replikat nicht auf das primäre Replikat aus.

Das sekundäre Replikat im Modus für asynchrone Commits versucht, mit den vom primären Replikat empfangenen Protokolldatensätzen Schritt zu halten. Sekundäre Datenbanken mit asynchronem Commit bleiben jedoch immer unsynchronisiert und neigen dazu, etwas hinter den entsprechenden primären Datenbanken zurückzubleiben. In der Regel ist die Lücke zwischen einer sekundären Datenbank mit asynchronem Commit und der entsprechenden primären Datenbank klein. Doch kann sich die Lücke erheblich vergrößern, wenn der Server, der das sekundäre Replikat hostet, überlastet oder das Netzwerk langsam ist.

Im Modus für asynchrone Commits wird lediglich ein erzwungenes manuelles Failover (mit möglichem Datenverlust) unterstützt. Das erzwungene Failover ist lediglich als letztes Mittel für Situationen vorgesehen, in denen das aktuelle primäre Replikat über einen längeren Zeitraum nicht verfügbar ist und die sofortige Verfügbarkeit der primären Datenbanken wichtiger ist als das Risiko eines möglichen Datenverlusts. Das Failoverziel muss ein Replikat sein, dessen Rolle sich im SECONDARY- oder RESOLVING-Zustand befindet. Das Failoverziel wechselt in die primäre Rolle, und seine Datenbankkopien werden zur primären Datenbank. Sämtliche verbleibenden sekundären Datenbanken werden zusammen mit den bisherigen primären Datenbanken, sobald diese verfügbar werden, angehalten, bis Sie sie einzeln manuell fortsetzen. Im asynchronen Commit-Modus gehen alle Transaktionsprotokolle, die das ursprüngliche primäre Replikat noch nicht an das frühere sekundäre Replikat gesendet hatte, verloren. Dies bedeutet, dass in den neuen primären Datenbanken möglicherweise einige oder alle Transaktionen fehlen, die kürzlich committet wurden. Weitere Informationen zur Funktionsweise des erzwungenen Failovers und bewährte Methoden zu dessen Verwendung finden Sie unter Failover und Failovermodi (Always On-Verfügbarkeitsgruppen).

Synchronous-Commit Availability Mode

Unter dem Synchron-Commit-Verfügbarkeitsmodus (Synchron-Commit-Modus), nachdem sie zu einer Verfügbarkeitsgruppe hinzugefügt wurde, holt eine sekundäre Datenbank zur entsprechenden primären Datenbank auf und wechselt in den SYNCHRONIZED Zustand. Die sekundäre Datenbank bleibt bestehen SYNCHRONIZED , solange die Datensynchronisierung fortgesetzt wird. Dadurch wird sichergestellt, dass jede Transaktion, die in einer bestimmten primären Datenbank abgeschlossen wird, in der jeweiligen sekundären Datenbank abgeschlossen wird. Wenn jede sekundäre Datenbank eines bestimmten sekundären Replikats synchronisiert ist, ist der Synchronisierungsstatus des sekundären Replikats als Ganzes HEALTHY.

In diesem Abschnitt:

Faktoren, die die Datensynchronisierung unterbrechen

Sobald alle Datenbanken synchronisiert wurden, wechselt ein sekundäres Replikat in den HEALTHY Zustand. Das synchronisierte sekundäre Replikat bleibt funktionsfähig, es sei denn, eines der folgenden Ereignisse tritt ein:

  • Eine Verzögerung oder eine Störung im Netzwerk oder auf dem Computer führt dazu, dass für die Sitzung zwischen dem sekundären und dem primären Replikat ein Timeout auftritt.

    Hinweis

    Informationen zur Sitzungszeiteigenschaft von Verfügbarkeitsreplikaten finden Sie unter Was ist eine AlwaysOn-Verfügbarkeitsgruppe?

  • Eine sekundäre Datenbank auf dem sekundären Replikat wird angehalten. Das sekundäre Replikat hört auf, synchronisiert zu werden, und sein Synchronisierungsstatus wird als "NICHT GESUND" markiert. Das sekundäre Replikat kann erst dann wieder fehlerfrei werden, wenn die angehaltene sekundäre Datenbank entweder fortgesetzt und erneut synchronisiert bzw. aus der Verfügbarkeitsgruppe entfernt wurde.

  • Sie fügen der Verfügbarkeitsgruppe eine primäre Datenbank hinzu. Zuvor synchronisierte sekundäre Replikate gehen in den NOT_HEALTHY Synchronisationsgesundheitszustand. Dieser Zustand gibt an, dass sich mindestens eine Datenbank im NOT SYNCHRONIZING Synchronisierungszustand befindet. Ein bestimmtes sekundäres Replikat kann erst wieder HEALTHY werden, wenn eine entsprechende sekundäre Datenbank für das Replikat vorbereitet wurde, der Verfügbarkeitsgruppe beigetreten ist und mit der neuen primären Datenbank synchronisiert wurde.

  • Sie ändern das primäre Replikat oder das sekundäre Replikat in den Verfügbarkeitsmodus mit asynchronem Commit. Nach dem Wechsel in den asynchronen Commit-Modus verbleibt das sekundäre Replikat im HEALTHY Synchronisationszustand, solange die Datensynchronisierung andauert. Wenn jedoch nur das primäre Replikat in den asynchronen Commit-Modus geändert wird, wechselt das synchronen Commit-sekundären Replikat in den Synchronisierungsintegrität-Status PARTIALLY_HEALTHY. Dieser Zustand gibt an, dass sich mindestens eine Datenbank im SYNCHRONIZING Synchronisierungszustand befindet, aber keine der Datenbanken im NOT SYNCHRONIZING Zustand ist.

  • Sie ändern alle sekundäre Replikate, indem Sie sie in den Verfügbarkeitsmodus mit synchronem Commit versetzen. Dies bewirkt, dass das sekundäre Replikat im Synchronisierungsintegritätsstatus PARTIALLY_HEALTHY gekennzeichnet wird, bis sich alle Datenbanken im SYNCHRONIZED-Synchronisationsstatus befinden.

Tipp

Wenn Sie die Synchronisierungsintegrität einer Verfügbarkeitsgruppe, eines Verfügbarkeitsreplikats oder einer Verfügbarkeitsdatenbank anzeigen möchten, fragen Sie die synchronization_health- oder synchronization_health_desc-Spalte von sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states oder sys.dm_hadr_database_replica_states ab.

Funktionsweise der Synchronisierung für ein sekundäres Replikat

Im synchronen Commit-Modus wird nach dem Beitritt eines sekundären Replikats zur Verfügbarkeitsgruppe eine Sitzung mit dem primären Replikat eingerichtet:

  1. Das sekundäre Replikat schreibt eingehende Protokolldatensätze auf die Festplatte (härtet das Protokoll).
  2. Das sekundäre Replikat sendet eine Bestätigungsmeldung an das primäre Replikat.

Nachdem die gesicherte Protokolldatei der sekundären Datenbank bis zum Ende des Protokolls der primären Datenbank aufgeholt hat, wird der Status der sekundären Datenbank auf SYNCHRONIZED festgelegt.

Die für die Synchronisierung erforderliche Zeit hängt davon ab, wie weit die sekundäre Datenbank zu Beginn der Sitzung hinter der primären Datenbank lag. Dieses Delta wird durch die Anzahl der Protokolldatensätze gemessen, die ursprünglich vom primären Replikat empfangen wurden, die Arbeitslast für die primäre Datenbank und die Geschwindigkeit des Instanzhosts des sekundären Replikats.

Der Transaktionsvorgang

Im synchronen Commitmodus werden Transaktionen in dieser Reihenfolge an beide Replikate gebunden:

  1. Das primäre Replikat empfängt eine Transaktion von einem Client.

  2. Das primäre Replikat schreibt den Datensatz in das Transaktionsprotokoll und sendet den Protokolldatensatz gleichzeitig an die sekundären Replikate.

    Sobald ein Protokolldatensatz in das Transaktionsprotokoll der primären Datenbank geschrieben wurde, kann die Transaktion nur rückgängig gemacht werden, wenn ein Failover auf einen sekundären Server erfolgt, der das Protokoll nicht empfangen hat.

  3. Das primäre Replikat wartet auf die Bestätigung des sekundären Replikats mit synchronem Commit.

  4. Das sekundäre Replikat schreibt das Protokoll auf den Datenträger und gibt eine Bestätigung an das primäre Replikat zurück.

  5. Das primäre Replikat beendet die Commitverarbeitung und sendet eine Bestätigungsmeldung an den Client.

Timeout bei synchronen Commits

Wenn ein synchrones Commit für sekundäres Replikat ein Timeout verursacht ohne zu bestätigen, dass es das Protokoll festgeschrieben hat, werden in der Verfügbarkeitsgruppe die folgenden Aktionen ausgeführt:

  1. Das primäre Replikat kennzeichnet das sekundäre Replikat als fehlgeschlagen.
  2. Der sekundäre Replikatstatus ändert sich in DISCONNECTED.
  3. Der primäre hält an und wartet auf Bestätigung.
  4. Die Verfügbarkeitsgruppe kennzeichnet den Synchronisierungsstatus als NOT SYNCHRONIZING und den Replikatstatus als NOT_HEALTHY.

Durch dieses Verhalten wird sichergestellt, dass das Festschreiben des Protokolls auf dem primären Replikat nicht vom sekundären Replikat mit fehlgeschlagenem synchronen Commit verhindert wird.

Wenn das sekundäre Replikat wieder online ist:

  1. Der sekundäre Replikatstatus ändert sich in CONNECTED.
  2. Das sekundäre Replikat verarbeitet die Protokoll-Sendewarteschlange des primären Replikats.
  3. Der Synchronisierungsstatus wechselt zu SYNCHRONIZING, und die Replikagesundheit zu PARTIALLY_HEALTHY.

Nachdem die Protokoll-Sendewarteschlange verarbeitet wurde, wird der Synchronisierungsstatus zu SYNCHRONIZED, und die Replikatintegrität zu HEALTHY.

Im Modus für synchrone Commits werden die Daten dadurch geschützt, dass die an zwei Stellen vorhandenen Daten synchronisiert werden müssen. Dies hat allerdings eine etwas höhere Wartezeit für die Transaktion zur Folge.

Modus für synchrone Commits ausschließlich mit manuellem Failover

Wenn diese Replikate verbunden sind und die Datenbank synchronisiert ist, wird das manuelle Failover unterstützt. Ein Ausfall des sekundären Replikats wirkt sich nicht auf das primäre Replikat aus. Das primäre Replikat läuft ungeschützt, wenn keine SYNCHRONIZED Replikate vorhanden sind (d. h. ohne Daten an ein Sekundär-Replikat zu senden). Wenn das primäre Replikat verloren geht, geben die sekundären Replikate den RESOLVING Status ein, aber der Datenbankbesitzer kann ein Failover zum sekundären Replikat erzwingen (mit möglichen Datenverlusten). Weitere Informationen finden Sie unter Failover und Failovermodi (Always On-Verfügbarkeitsgruppen).

Synchroner Commit-Modus mit automatischem Failover

Das automatische Failover bietet Hochverfügbarkeit, indem sichergestellt wird, dass die Datenbank nach dem Ausfall des primären Replikats schnell wieder verfügbar gemacht wird. Um eine Verfügbarkeitsgruppe für ein automatisches Failover zu konfigurieren, müssen Sie sowohl das aktuelle primäre Replikat als auch mindestens ein sekundäres Replikat für den Modus für synchrone Commits mit automatischem Failover festlegen. In SQL Server 2019 (15.x) wird die maximale Anzahl der synchronen Replikate von ehemals 3 in SQL Server 2017 (14.x) auf 5 erhöht. Sie können diese Gruppe aus fünf Replikaten für das automatische Failover in der Gruppe konfigurieren. Es gibt ein primäres Replikat sowie vier synchrone sekundäre Replikate.

Damit ein automatisches Failover innerhalb einer bestimmten Zeit ausgeführt werden kann, muss dieses sekundäre Replikat darüber hinaus mit dem primären Replikat synchronisiert werden (Synchronisierung aller sekundären Datenbanken), und der WSFC (Windows Server Failover Clustering)-Cluster muss über ein Quorum verfügen. Wenn das primäre Replikat unter diesen Bedingungen ausfällt, findet ein automatisches Failover statt. Das sekundäre Replikat wechselt in die Rolle des primären Replikats und bietet seine Datenbank als primäre Datenbank an. Weitere Informationen finden Sie im Abschnitt „Automatisches Failover“ des Artikels „Failover und Failovermodi (Always On Availability Groups)“.

Hinweis

Weitere Informationen zu WSFC-Quorum und Always On-Verfügbarkeitsgruppen finden Sie unter Weitere Informationen finden Sie unter WSFC-Quorummodi und Abstimmungskonfiguration (SQL Server).

Datenlatenz beim sekundären Replikat

Das Implementieren von schreibgeschütztem Zugriff auf sekundäre Replikate ist hilfreich, sofern Ihre schreibgeschützten Arbeitsauslastungen eine gewisse Datenlatenz tolerieren können. Führen Sie in Situationen mit inakzeptabler Datenlatenz ggf. schreibgeschützte Arbeitsauslastungen für das primäre Replikat aus.

Vom primären Replikat werden Protokolldatensätze der Änderungen in der primären Datenbank an die sekundären Replikate gesendet. In der jeweiligen sekundären Datenbank werden die Protokolldatensätze von einem dedizierten REDO-Thread angewendet. Bei einer sekundären Lesezugriffsdatenbank wird eine bestimmte Datenänderung erst in Abfrageergebnissen angezeigt, wenn der Protokolldatensatz, der die Änderung enthält, auf die sekundäre Datenbank angewendet wurde und die Transaktion für die primäre Datenbank zugesichert wurde.

Dies bedeutet, dass zwischen den primären und sekundären Replikaten eine Latenz besteht, in der Regel nur eine Frage von Sekunden. In außergewöhnlichen Fällen, beispielsweise bei Netzwerkproblemen, die den Durchsatz reduzieren, kann die Latenz jedoch signifikant werden. Die Latenz nimmt bei E/A-Engpässen und bei angehaltener Datenbewegung zu. Um die angehaltene Datenübertragung zu überwachen, können Sie das Dashboard "Always On Availability Group" (SQL Server Management Studio) oder die dynamische Verwaltungsansicht sys.dm_hadr_database_replica_states verwenden.

Um die Latenz in SQL Server 2025 (17.x) und höheren Versionen zu verringern, können Sie die Zeit (in Millisekunden) verringern, die das primäre Replikat benötigt, um Transaktionen an das sekundäre Replikat zu übernehmen. Weitere Informationen finden Sie unter Serverkonfiguration: Verfügbarkeitsgruppen-Commitzeit (ms).

So ändern Sie den Verfügbarkeitsmodus und Failovermodus

So passen Sie Quorumsstimmen an

So führen Sie ein manuelles Failover aus

So zeigen Sie Verfügbarkeitsgruppe, Verfügbarkeitsreplikat und Datenbankstatus an

Verwandte Inhalte

  • Last updated on