Funktionsweise und Richtlinien für Lease-, Cluster- und Zustandsprüfungszeitüberschreitungen bei Always On-Verfügbarkeitsgruppen

Unterschiede bei Hardware, Software und Clusterkonfigurationen sowie unterschiedliche Anwendungsanforderungen hinsichtlich Verfügbarkeit und Leistung erfordern spezifische Konfigurationen der Timeoutwerte für Lease-, Cluster- und Zustandsprüfungen. Für bestimmte Anwendungen und Arbeitsauslastungen ist eine striktere Überwachung erforderlich, um Ausfallzeiten infolge schwerer Fehler zu begrenzen. Andere erfordern eine höhere Toleranz gegenüber vorübergehenden Netzwerkproblemen und Wartezeiten durch hohe Ressourcenauslastung und kommen mit langsameren Failovers zurecht.

Es werden mehrere Dienste auf den einzelnen Knoten zum Erkennen von Fehlern eingesetzt. Der Clusterdienst kann einen Quorumsverlust erkennen, die Ressourcen-DLL kann ein Problem erkennen, das durch die Always On-Integritätserkennung zum Vorschein kommt, oder es kann ein manuelles Failover direkt auf der primären Instanz initiiert werden. Der Clusterdienst, der Ressourcenhost und die SQL Server-Instanz werden über RPC, Shared Memory und T-SQL miteinander synchronisiert. In den meisten Szenarien findet eine erfolgreiche Kommunikation dieser Dienste statt, doch ist diese Kommunikation selbst zwischen Diensten auf demselben Computer nicht hundertprozentig zuverlässig. Darüber hinaus muss die Verfügbarkeitsgruppe (availability group, AG) systemweiten Ereignissen wie Netzwerk- und Datenträgerfehlern standhalten können, durch die eine Kommunikation verhindert oder Funktionen unterbrochen werden. Angesichts vieler möglicher Fehlerfälle und ohne eine vollständig verlässliche Kommunikation zwischen den Diensten ist die Verfügbarkeitsgruppe auf verschiedene Mechanismen zur Erkennung von Failovern angewiesen, um Ausfälle unabhängig voneinander zu erkennen und auf sie zu reagieren, sodass der Clusterzustand für alle Knoten stets konsistent ist.

SQL-Server 2025 verbesserte Integritätsprüfungs-Timeout-Diagnose

Ressourceneinschränkungen wie hohe CPU-Auslastung, Datenträgerlatenz oder Speicherausschöpfung können einen Timeout in der Always On-Verfügbarkeitsgruppe auslösen. Wenn ein Leasetimeout im Clusterprotokoll gemeldet wird, werden die neuesten Leistungsüberwachungsdaten für die CPU-Auslastung, die Speicherauslastung und die Lese- und Schreiblatenz des Datenträgers im Windows-Failoverclusterprotokoll zusammen mit dem Leasetimeout gemeldet.

Ebenso können Ressourceneinschränkungen auch ein Timeout für die Integritätsprüfung auslösen. Ab SQL Server 2025 (17.x) werden die gleichen Leistungsüberwachungsindikatoren jetzt im Windows-Failoverclusterprotokoll gemeldet, wenn ein Timeout für die Integritätsprüfung erkannt wird, ähnlich wie die Diagnoseausgabe des Leasetimeouts.

Im Folgenden finden Sie ein Beispiel für die verbesserte Ausgabe des Windows-Failoverclusterprotokolls für ein Integritätsprüfungstimeout:

[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 ERR   [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] AG health check failed, logging perf counter data collected so far
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:25.0, 21.857418, 3248349184.000000, 0.000000, 0.000253
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:35.0, 11.442071, 3255394304.000000, 0.000907, 0.000382
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:45.0, 9.979768, 3253981184.000000, 0.000415, 0.000549
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:55.0, 9.762850, 3251232768.000000, 0.001989, 0.000638
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:56:5.0, 9.827234, 3250462720.000000, 0.002250, 0.001418

Erkennung von Clusterknoten und -ressourcen

Jeder Knoten im Cluster führt einen einzelnen Clusterdienst aus, der den Failovercluster verwaltet und alle Clusterressourcen überwacht. Der Ressourcenhost funktioniert als separater Prozess und stellt die Schnittstelle zwischen dem Clusterdienst und den Clusterressourcen dar. Der Ressourcenhost führt Vorgänge für Clusterressourcen aus, wenn er vom Clusterdienst dazu aufgerufen wird. Clusterfähige Anwendungen wie SQL Server bieten benutzerdefinierte Schnittstellen zum Ressourcenmonitor über Ressourcen-DLLs. Die Ressourcen-DLL implementiert Online- und Offlinevorgänge sowie die Zustandsüberwachung für benutzerdefinierte Ressourcen. Beim Ressourcenhost handelt es sich um einen untergeordneten Prozess des Clusterdiensts, der beendet wird, sobald der Clusterdienst beendet wird.

Bei SQL Server bestimmt die Ressourcen-DLL der AG den Zustand der AG auf Grundlage des AG-Leasemechanismus und der Always On-Zustandserkennung. Die Ressourcen-DLL der Verfügbarkeitsgruppe macht den Ressourcenzustand über den Vorgang IsAlive verfügbar. Der Ressourcenmonitor fragt IsAlive im Taktintervall des Clusters ab, das durch die clusterübergreifenden Werte CrossSubnetDelay und SameSubnetDelay festgelegt ist. Auf einem primären Knoten initiiert der Clusterdienst immer dann ein Failover, wenn der IsAlive-Aufruf an die Ressourcen-DLL zurückgibt, dass die Verfügbarkeitsgruppe nicht fehlerfrei ist.

Der Clusterdienst sendet Heartbeats an andere Knoten im Cluster und bestätigt die von ihnen empfangenen Heartbeats. Wenn ein Knoten anhand einer Reihe nicht bestätigter Heartbeats einen Kommunikationsausfall erkennt, sendet er eine Nachricht an alle erreichbaren Knoten, damit diese ihre Sicht auf den Zustand der Clusterknoten abgleichen. Dieses Ereignis wird Neugruppierungsereignis genannt und bewahrt die Konsistenz des Clusterstatus auf allen Knoten. Nach einem Neuformierungsereignis werden bei Verlust des Quorums alle Clusterressourcen einschließlich der AGs in dieser Partition offline genommen. Alle Knoten in dieser Partition gehen in einen Auflösungsstatus über. Wenn eine Partition vorhanden ist, die ein Quorum hält, wird die Verfügbarkeitsgruppe einem Knoten in der Partition zugeordnet, der dann zum primären Replikat wird, während alle anderen Knoten zu sekundären Replikaten werden.

Always On-Statuserkennung

Die Always On-Ressourcen-DLL überwacht den Status interner SQL Server-Komponenten. sp_server_diagnostics meldet die Integrität dieser SQL Server-Komponenten in einem durch HealthCheckTimeout gesteuerten Intervall. sp_server_diagnostics meldet den Integritätsstatus von fünf Komponenten auf Instanzebene: System, Ressource, Abfrageverarbeitung, E/A-Subsystem und Ereignisse. Außerdem wird der Zustand jeder AG gemeldet. Bei jeder Aktualisierung aktualisiert die Ressourcen-DLL den Integritätszustand der AG-Ressource anhand der Fehlerebene der AG. Bei der Rückgabe von Daten von sp_server_diagnostics ist für jede Komponente ein Status vom Typ Fehlerfrei, Warnung, Fehler oder Unbekannt mit einigen XML-Daten angegeben, die den Status der Komponente beschreiben. Bei der Integritätsprüfung wird die Ressourcen-DLL nur aktiv, wenn sich eine Komponente in einem Fehlerzustand befindet.

Wenn die Integritätsprüfung über mehrere Intervalle hinweg keine Aktualisierung der Ressourcen-DLL meldet, wird die AG als fehlerhaft eingestuft und meldet bei IsAlive-Aufrufen Fehler.

Leasemechanismus

Im Gegensatz zu anderen Failovermechanismen spielt die SQL Server-Instanz beim Leasemechanismus eine aktive Rolle. Der Leasingmechanismus wird als Looks-Alive-Prüfung zwischen dem Clusterressourcenhost und dem SQL Server-Prozess verwendet. Der Mechanismus dient der Sicherstellung, dass die beiden Seiten (Cluster- und SQL Server-Dienst) in häufigem Kontakt stehen, den Zustand des jeweils anderen überprüfen und schließlich ein Split-Brain-Szenario verhindern. Wenn die Verfügbarkeitsgruppe als primäres Replikat online gebracht wird, startet die SQL Server-Instanz einen dedizierten Lease-Worker-Thread für die Verfügbarkeitsgruppe. Der Leaseworker teilt sich einen kleinen Bereich des Speichers mit dem Ressourcenhost, der die Ereignisse für Leaseverlängerung und Leasebeendigung enthält. Der Leaseworker und der Ressourcenhost arbeiten kreisförmig, indem sie das jeweilige Leaseverlängerungsereignis signalisieren und dann im Ruhezustand darauf warten, dass die andere Seite das eigene Leaseverlängerungsereignis oder das Beendigungsereignis signalisiert. Sowohl der Ressourcenhost als auch der SQL Server-Lease-Thread verwalten einen Time-to-Live-Wert, der jedes Mal aktualisiert wird, wenn der Thread aufwacht, nachdem er von dem anderen Thread signalisiert wurde. Wenn beim Warten auf das Signal die Gültigkeitsdauer erreicht wird, läuft die Lease ab und das Replikat geht dann in den Auflösungsstatus für die jeweilige Verfügbarkeitsgruppe über. Wenn das Leasebeendigungsereignis signalisiert wird, geht das Replikat in eine Auflösungsrolle über.

Der Leasemechanismus erzwingt die Synchronisierung zwischen SQL Server und Windows Server-Failovercluster. Bei Ausgabe eines Failoverbefehls sendet der Clusterdienst einen Offline-Aufruf an die Ressourcen-DLL des aktuellen primären Replikats. Die Ressourcen-DLL versucht zunächst, die Verfügbarkeitsgruppe mithilfe einer gespeicherten Prozedur offline zu schalten. Wenn bei dieser gespeicherten Prozedur ein Fehler oder ein Timeout auftritt, wird dies dem Clusterdienst zurückgemeldet, der dann einen Befehl zum Beenden ausgibt. Der Beendigungsvorgang versucht erneut, dieselbe gespeicherte Prozedur auszuführen, doch diesmal wartet der Cluster nicht darauf, dass die Ressourcen-DLL Erfolg oder Fehler meldet, bevor er die AG auf einem neuen Replikat online schaltet. Wenn dieser zweite Prozeduraufruf fehlschlägt, muss sich der Ressourcenhost darauf verlassen, dass die Instanz vom Leasemechanismus offline geschaltet wird. Wenn die Ressourcen-DLL aufgerufen wird, um die AG offline zu schalten, signalisiert die Ressourcen-DLL das Lease-Stoppereignis und weckt den SQL Server-Lease-Workerthread auf, damit dieser die AG offline schaltet. Auch wenn dieses Beendigungsereignis nicht signalisiert wird, läuft die Lease ab und das Replikat geht in den Auflösungsstatus über.

Der Lease ist in erster Linie ein Synchronisierungsmechanismus zwischen der primären Instanz und dem Cluster, kann jedoch auch Fehlersituationen verursachen, obwohl andernfalls kein Failover nötig wäre. Beispielsweise können hohe CPU-Werte, Situation mit fehlendem Arbeitsspeicher (wenig virtueller Arbeitsspeicher, Prozesspaging), SQL-Prozesse, die beim Erzeugen eines Speicherabbilds nicht reagieren, ein nicht reagierendes System, oder ein Cluster (WSFC), der offline geht (z. B. wegen Quorumverlust), die Verlängerung der Lease-Dauer durch die SQL-Instanz verhindern und einen Neustart oder ein Failover verursachen.

Richtlinien für Timeoutwerte des Clusters

Wägen Sie die Vor- und Nachteile sorgfältig ab, und machen Sie sich die Konsequenzen einer weniger strikten Überwachung des SQL Server-Clusters bewusst. Durch höhere Timeoutwerte des Clusters ergibt sich eine größere Toleranz gegenüber vorübergehenden Netzwerkproblemen, doch verlangsamt sich gleichzeitig die Reaktion auf schwerwiegende Fehler. Werden höhere Timeoutwerte für den Fall einer Ressourcenüberlastung oder hoher geografischer Latenz verwendet, verlängert sich auch die Zeit für die Wiederherstellung nach schwerwiegenden oder nicht behebbaren Fehlern. Zwar ist dies bei vielen Anwendungen akzeptabel, jedoch nicht in allen Fällen die optimale Lösung.

Die Standardeinstellungen werden für schnelles Reagieren auf Symptome schwerwiegender Fehler und eine Begrenzung von Ausfallzeiten optimiert, doch können diese Einstellungen für bestimmte Arbeitslasten und Konfigurationen zu strikt sein. Es wird nicht empfohlen, LeaseTimeout, CrossSubnetDelay, CrossSubnetThreshold, SameSubnetDelay, SameSubnetThreshold oder HealthCheckTimeout auf Werte unterhalb der Standardwerte zu setzen. Die jeweils richtigen Einstellungen für eine Bereitstellung variieren und ergeben sich wahrscheinlich erst nach einem längeren Optimierungszeitraum. Nehmen Sie Änderungen an diesen Werten nur schrittweise und unter Berücksichtigung der Beziehungen und Abhängigkeiten vor, die zwischen diesen Werten bestehen.

Zusammenhang zwischen Clustertimeout und Leasetimeout

Die primäre Funktion des Leasemechanismus besteht darin, die SQL Server-Ressource dann offline zu nehmen, wenn der Clusterdienst nicht mit der Instanz kommunizieren kann, während ein Failover zu einem anderen Knoten erfolgt. Wenn der Cluster die AG-Clusterressource offline nimmt, führt der Clusterdienst einen RPC-Aufruf an rhs.exe aus, um die Ressource offline zu nehmen. Die Ressourcen-DLL verwendet gespeicherte Prozeduren, um SQL Server anzuweisen, die Verfügbarkeitsgruppe offline zu schalten, doch kann bei dieser gespeicherten Prozedur ein Fehler oder Timeout auftreten. Der Ressourcen-Host stoppt während des Offline-Aufrufs auch seinen eigenen Lease Renewal Thread. Im ungünstigsten Fall führt SQL Server dazu, dass das Lease nach ½ * LeaseTimeout abläuft, und versetzt die Instanz in einen Resolving-Zustand. Failover können von mehreren verschiedenen Seiten aus initiiert werden, doch ist es äußerst wichtig, dass die Sicht des Clusterstatus im gesamten Cluster und auf allen SQL Server-Instanzen konsistent ist. Stellen Sie sich beispielsweise ein Szenario vor, in dem die primäre Instanz die Verbindung mit dem restlichen Cluster verliert. Aufgrund der Timeoutwerte des Clusters ermittelt jeder Knoten im Cluster zur gleichen Zeit einen Fehler, doch kann nur der primäre Knoten mit der primären SQL Server-Instanz interagieren, um ein Aufgeben der primären Rolle zu erzwingen.

Aus Sichtweise des primären Knotens hat der Clusterdienst das Quorum verloren, und der Dienst beginnt sich selbst zu beenden. Der Clusterdienst gibt einen RPC-Aufruf an den Ressourcenhost zum Beenden des Prozesses aus. Dieser Beendigungsaufruf sorgt dafür, dass die Verfügbarkeitsgruppe auf der SQL Server-Instanz offline geschaltet wird. Dieser Offlineaufruf erfolgt über T-SQL, kann jedoch nicht gewährleisten, dass die Verbindung zwischen SQL und der Ressourcen-DLL erfolgreich hergestellt wird.

Aus Sicht des restlichen Clusters gibt es derzeit kein primäres Replikat, also stimmt der Cluster ab und legt ein einziges neues primäres Replikat für die verbleibenden Knoten im Cluster fest. Wenn bei der von der Ressourcen-DLL aufgerufenen gespeicherten Prozedur ein Fehler oder Timeout auftritt, könnte es beim Cluster zu einem Split-Brain-Szenario kommen.

Das Lease-Timeout verhindert Split-Brain-Szenarien bei Kommunikationsfehlern. Selbst wenn sämtliche Kommunikation fehlschlägt, wird der Ressourcen-DLL-Prozess beendet und das Lease kann nicht aktualisiert werden. Nach Ablauf der Lease wird sie automatisch offline geschaltet. Die SQL Server-Instanz muss erkennen, dass sie nicht mehr das primäre Replikat hostet, bevor der Cluster ein neues Replikat erstellt. Da der restliche Cluster, der für das Auswählen eines neuen primären Replikats zuständig ist, keine Möglichkeit zur Koordination mit dem aktuellen primären Replikat hat, wird durch die Timeoutwerte sichergestellt, dass ein neues primäres Replikat erst dann erstellt wird, wenn sich das aktuelle primäre Replikat offline geschaltet hat.

Bei einem Failover des Clusters muss die SQL Server-Instanz, auf der das vorherige primäre Replikat gehostet ist, in einen Auflösungsstatus übergehen, bevor das neue primäre Replikat online geschaltet wird. Der SQL Server-Lease-Thread weist jederzeit eine verbleibende Gültigkeitsdauer von ½ * des LeaseTimeout auf, da bei jeder Verlängerung der Lease die neue Gültigkeitsdauer auf LeaseInterval oder ½ * LeaseTimeout aktualisiert wird. Wenn der Clusterdienst oder der Ressourcenhost stoppt oder beendet wird, ohne das Leasebeendigungsereignis zu signalisieren, deklariert der Cluster den primären Knoten nach SameSubnetThreshold\ SameSubnetDelay Millisekunden als inaktiv. Innerhalb dieses Zeitraums muss die Lease ablaufen, sodass garantiert ist, dass das primäre Replikat offline ist. Da die maximale Gültigkeitszeit für das Lease-Timeout ½ * LeaseTimeout beträgt, muss ½ * LeaseTimeout kleiner als SameSubnetThreshold * SameSubnetDelay sein.

SameSubnetThreshold \<= CrossSubnetThreshold und SameSubnetDelay \<= CrossSubnetDelay sollte für alle SQL Server-Cluster zutreffen.

Funktionsweise des Timeouts für die Integritätsprüfung

Das Timeout für die Zustandsprüfung ist flexibler, da kein anderer Failover-Mechanismus direkt davon abhängt. Beim Standardwert von 30 Sekunden ist das sp_server_diagnostics-Intervall auf 10 Sekunden festgelegt, mit einem Mindestwert von 15 Sekunden für das Timeout und einem Intervall von 5 Sekunden. Allgemeiner ausgedrückt: Das sp_server_diagnostics-Aktualisierungsintervall beträgt immer 1/3 * HealthCheckTimeout. Wenn die Ressourcen-DLL innerhalb eines Intervalls keine neuen Integritätsdaten erhält, verwendet sie weiterhin die Integritätsdaten aus dem vorherigen Intervall, um die aktuelle Verfügbarkeitsgruppe und den Zustand der Instanz zu bestimmen. Ein höherer Timeoutwert für die Integritätsprüfung macht das primäre Replikat toleranter gegenüber hoher CPU-Last, die verhindern kann, dass sp_server_diagnostics in jedem Intervall neue Daten bereitstellt; allerdings stützt es sich dann länger auf Integritätsprüfungen auf Basis veralteter Daten. Unabhängig vom Timeoutwert geschieht Folgendes: Sobald Daten empfangen werden, die darauf hinweisen, dass das Replikat nicht fehlerfrei ist, wird im nächsten IsAlive-Aufruf zurückgegeben, dass die Instanz fehlerhaft ist, und der Clusterdienst initiiert ein Failover.

Die Stufe der Fehlerbedingungen der Verfügbarkeitsgruppe ändert die Fehlerbedingungen für die Integritätsprüfung. Bei jeder Fehlerstufe gilt: Wenn das AG-Element von sp_server_diagnostics als fehlerhaft gemeldet wird, schlägt die Integritätsprüfung fehl. Jede Ebene übernimmt alle Fehlerbedingungen der darunter liegenden Ebenen.

Aktualisieren der Timeoutwerte für Cluster und Always On

Clusterwerte

Es gibt vier Werte in der WSFC-Konfiguration, die zur Bestimmung von Timeoutwerten für den Cluster herangezogen werden:

• SameSubnetVerzögerung
• Schwellenwert für dasselbe Subnetz
• Subnetzüberschreitungsverzögerung
• CrossSubnet-Schwelle

Die Verzögerungswerte bestimmen die Wartezeit zwischen Takten vom Clusterdienst. Die Schwellenwerte legen die Anzahl der Takte fest, die keine Bestätigung vom Zielknoten oder der Ressource empfangen können, bevor das Objekt vom Cluster als inaktiv deklariert wird. Wenn zwischen Knoten im selben Subnetz länger als SameSubnetDelay \* SameSubnetThreshold Millisekunden kein erfolgreicher Heartbeat stattfindet, wird der Knoten als ausgefallen eingestuft. Dasselbe gilt für die subnetzübergreifende Kommunikation unter Verwendung der subnetzübergreifenden Werte.

Zum Auflisten aller aktuellen Clusterwerte öffnen Sie auf einem beliebigen Knoten im Zielcluster einen PowerShell-Terminal mit erhöhten Rechten. Führen Sie den folgenden Befehl aus:

 Get-Cluster | fl *

Um einen dieser Werte zu aktualisieren, führen Sie den folgenden Befehl auf einem PowerShell-Terminal mit erhöhten Rechten aus:

(Get-Cluster).<ValueName> = <NewValue>

Wenn Sie das Produkt aus Verzögerung und Schwellenwert erhöhen, um das Cluster-Timeout toleranter zu machen, ist es wirksamer, zunächst den Wert für die Verzögerung zu erhöhen, bevor der Schwellenwert erhöht wird. Durch Erhöhen der Verzögerung wird die Zeit zwischen den einzelnen Heartbeats verlängert. Ein längerer Zeitraum zwischen den Takten bietet mehr Zeit, damit sich vorübergehende Netzwerkprobleme von selbst lösen können, und verringert eine Netzwerküberlastung im Vergleich zum Senden von mehr Takten im gleichen Zeitraum.

Lease-Zeitüberschreitung

Der Leasemechanismus wird durch einen einzelnen, für jede AG in einem WSFC-Cluster spezifischen Wert gesteuert. Ein Lease-Timeout kann zu den folgenden Fehlern führen:

Error 35201:
A connection timeout has occurred while attempting to establish a connection to availability replica 'replicaname'
Error 35206:
A connection timeout has occurred on a previously established connection to availability replica 'replicaname'

Verwenden Sie zum Ändern des Leasetimeout-Werts den Failovercluster-Manager, und führen Sie die folgenden Schritte aus:

1. Suchen Sie auf der Registerkarte „Rollen“ nach der Ziel-AG-Rolle. Wählen Sie die Ziel-AG-Rolle aus.

2. Klicken Sie mit der rechten Maustaste unten im Fenster auf die AG-Ressource und wählen Sie Eigenschaften aus.

   

3. Navigieren Sie im Popupfenster zur Registerkarte Eigenschaften, um eine Liste der für diese AG spezifischen Werte anzuzeigen. Wählen Sie den LeaseTimeout-Wert aus, um ihn zu ändern.

   

   Je nach AG-Konfiguration kann es zusätzliche Ressourcen wie Listener, freigegebene Datenträger, Dateifreigaben usw. geben. Diese Ressourcen erfordern keine weitere Konfiguration.

Werte der Zustandsprüfung

Zwei Werte steuern die Always On-Zustandsprüfung: FailureConditionLevel und HealthCheckTimeout. FailureConditionLevel gibt die Toleranzstufe für bestimmte Fehlerbedingungen an, die von sp_server_diagnostics gemeldet werden. HealthCheckTimeout legt den Zeitraum fest, über den die Ressourcen-DLL keine Aktualisierung von sp_server_diagnostics empfangen muss. Das Aktualisierungsintervall für sp_server_diagnostics ist immer HealthCheckTimeout / 3.

Verwenden Sie zum Konfigurieren der Failoverbedingungsebene die Option FAILURE_CONDITION_LEVEL = <n> der Anweisung CREATE oder ALTER AVAILABILITY GROUP, wobei <n> eine ganze Zahl zwischen 1 und 5 ist. Mit dem folgenden Befehl wird die Fehlerbedingungsebene für AG „AG1“ auf 1 festgelegt:

ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);

Verwenden Sie zum Konfigurieren des Zeitlimits für die Zustandsprüfung die Option HEALTH_CHECK_TIMEOUT der Anweisungen CREATE oder ALTERAVAILABILITY GROUP. Der folgende Befehl setzt das Timeout für die Integritätsprüfung für AG AG1 auf 60.000 Millisekunden fest:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);

Zusammenfassung der Timeout-Richtlinien

• Es wird davon abgeraten, Timeoutwerte unter ihre Standardwerte zu senken.

• Das Lease-Intervall (½ * LeaseTimeout) muss kürzer als SameSubnetThreshold * SameSubnetDelay sein

• SameSubnetThreshold <= CrossSubnetThreshold

• SameSubnetDelay <= CrossSubnetDelay

Zugehöriger Inhalt

• Aktive sekundäre Replikate: Sicherung auf sekundären Replikaten (Always On-Verfügbarkeitsgruppen)
• ALTER AVAILABILITY GROUP (Transact-SQL)