it-swarm.com.de

Die Datenbank der Verfügbarkeitsgruppe bleibt nach einem Failover zu lange in "Zurücksetzen"

Architektur: Ich habe 2 Node Sync-Commit AlwaysOn-Konfiguration, die auf einem Multi-Subnetz-Failover-Cluster ausgeführt wird. Der primäre Knoten befindet sich in Der Knoten Europa und Sekundär befindet sich in den USA. Ich habe nur eine Datenbank in der Verfügbarkeitsgruppe, nämlich OperationsManager db von SCOM.

  • Primäre und sekundäre Hosts sind identisch.
  • SQL Server-Version auf beiden Feldern: 13.0.5237 und Windows Core
  • Update: Ich habe beide Server auf 10.0.5270.0 gepatcht, es hat nicht geholfen.
  • DB VLF Anzahl beträgt nur 27.

Problem: Wenn ich ein Failover initiiere, wird die Datenbank innerhalb von Sekunden erfolgreich vom primären zum sekundären Knoten übertragen. Die neue sekundäre (alte primäre) Datenbank geht jedoch in die Phase "Zurücksetzen/In Wiederherstellung" und bleibt dort ungefähr 30 Minuten lang. Ich habe das Gleiche auch erlebt, als ich zur ursprünglichen primären Box zurückgekehrt bin, sodass es sich um ein Problem handelt, das in beide Richtungen auftritt.

Ergebnisse: Ich habe im Internet danach gesucht und die Dokumentation gelesen, um das Problem zu untersuchen. Wenn der Rollenwechsel von Primär zu Sekundär abgeschlossen ist, durchläuft die neue Sekundärdatenbank drei Phasen:

Synchronisationsstatus: "NICHT SYNCHRONISIEREN"; Datenbankstatus: ONLINE

Synchronisationsstatus: "NICHT SYNCHRONISIEREN"; Datenbankstatus: WIEDERHERSTELLEN

Synchronisationsstatus: "REVERTING"; Datenbankstatus: WIEDERHERSTELLEN

In meinem Fall wurde die gesamte Zeit für den letzten Schritt aufgewendet. Ich habe auch den Rückgängig-Prozess überwacht, indem ich den Perfmon-Zähler " SQLServer: Datenbankreplikat Protokoll zum Rückgängigmachen" untersucht habe.

Ich habe die primäre Site vor Failover-Tests überprüft, um lange laufende oder offene Transaktionen zu erkennen, konnte jedoch keine finden. Nach dem Failover betrug "Protokoll zum Rückgängigmachen" etwa 30 MB und es dauerte 30 Minuten, bis die sekundäre Datenbank wieder in den Status "Synchronisiert" zurückkehrte. Wenn man bedenkt, dass wir im Sync-Commit-Modus arbeiten und die primäre Arbeitsbelastung gering ist, sollte die Wiederherstellungsphase imho nicht 30 Minuten dauern.

SQL Server-Fehlerprotokoll: Ich habe diese seltsamen Meldungen gefunden.

  • Die Remote-Härtung der Transaktion 'RECEIVE MSG' (ID 0x000000004d52c65a 0001: 01c4e415), die am 22. Februar 2019 um 14:55 Uhr in der Datenbank 'OperationsManager' bei LSN (2558: 107841: 1) gestartet wurde, ist fehlgeschlagen.

  • Die Remote-Härtung der Transaktion 'GhostCleanupTask' (ID 0x000000004d6d15aa 0001: 01c4eaa0), die am 22. Februar 2019 um 14:59 Uhr in der Datenbank 'OperationsManager' bei LSN (2558: 107843: 46) gestartet wurde, ist fehlgeschlagen.

Das Failover beginnt: enter image description here

(enter image description here

Das Failover endet: enter image description here

Alles in allem

Haben Sie dieses Problem schon einmal gesehen? Haben Sie Empfehlungen?

Eine Sache, die Sie überprüfen sollten, wenn die Datenbankwiederherstellung lange läuft, ob es sich um eine normale Wiederherstellung oder ein AG-Failover handelt, ist Ihre VLF Anzahl. Sie haben viele VLFs (Tausende oder Zehntausende) oder VLFs von Eine ungewöhnliche Größe (ein oder zwei extrem große VLFs) führt dazu, dass dieser Prozess langsamer wird.

Führen Sie den folgenden Befehl in der betreffenden Datenbank aus:

USE YourDatabaseName;
GO

DBCC LOGINFO;

Hinweis: Wenn Sie mit SQL Server 2016 SP2 oder höher arbeiten, können Sie diese dynamische Verwaltungsfunktion anstelle des DBCC-Befehls verwenden: sys.dm_db_log_info

Die Anzahl der Zeilen, die zurückkommen, entspricht der Anzahl der VLFs, die Sie haben. Wenn diese Anzahl sehr groß ist oder wenn in der Spalte FileSize extreme Ausreißer unter Ihren VLFs angezeigt werden, können Sie das Problem der langsamen Wiederherstellung wahrscheinlich folgendermaßen lösen: (auf hoher Ebene):

  1. verkleinern der Protokolldatei so klein wie möglich
  2. wachsen Sie es wieder auf seine Zielgröße
  3. stellen Sie sicher, dass das automatische Wachstum auf eine angemessene Anzahl eingestellt ist, basierend auf Ihrer typischen Protokollwachstumsrate und der Häufigkeit Ihrer Transaktionsprotokollsicherungen

Die Details zur Behebung von VLF Größenproblemen wurden an anderer Stelle ausführlich behandelt. Hier ein Beispiel: A D Busy/Accidental DBA's Guide to Managing VLFs

3
Josh Darnell

Wie bereits beantwortet VLF wäre auch meine erste Wahl. Eine andere Sache, die ich in Betracht ziehen würde, ist, die Infra-Übereinstimmung zwischen 2 Knoten zu betrachten.

Ja, ich weiß, dass dies zu beachten ist, bevor Sie Ihren Server für die Erstellung einrichten. Es kommt jedoch manchmal vor, dass in einem der Szenarien für einen anderen Knoten ein ganz anderes Speichersystem bereitgestellt wurde als für den primären Replikatknoten. Wir hatten SSDs auf dem primären Replikat, während SAN Speicher auf dem sekundären Replikat, da dies ein Fehler des Speicherteams war, und daher scheinen sie beim Failover einige Zeit in Anspruch zu nehmen.

Sammeln Sie am besten alle Leistungsmetriken und versuchen Sie, zwei Replikate zu vergleichen, um festzustellen, ob alles gut aussieht. Nicht zwingend erforderlich, aber gut zu haben, wenn Sie nach einem AG-Failover einen DR-Test durchführen und die Last von einem anderen Rechenzentrum oder einem neuen primären Replikat ausführen

2
KASQLDBA

Wir haben das gleiche Problem mit der Datenbank des Kunden, und die Hauptursache war eine große Datenmenge von Kunden, die FreeBCP zum Masseneinfügen ihrer Daten verwenden. Unsere Problemumgehungslösung bestand darin, die Masseneinfügung vor dem manuellen Failover auszuschalten.

1
tazzman