it-swarm.com.de

SQL Server 2017 mit 500 Datenbanken - Frequent AG trennt seit CU9 die Verbindung

Hallo allerseits und vielen Dank im Voraus für Ihre Hilfe. Wir haben Probleme mit SQL Server 2017-Verfügbarkeitsgruppen.

Hintergrund

Das Unternehmen ist eine B2B-Backend-Software für den Einzelhandel. Etwa 500 einzelne Mandantendatenbanken und 5 gemeinsam genutzte Datenbanken, die von allen Mandanten verwendet werden. Die Workload-Charakteristik wird meistens gelesen, und die meisten Datenbanken weisen eine sehr geringe Aktivität auf.

Am gemeinsamen Standort gehostete physische Produktionsserver wurden kürzlich von SQL Server 2014 Enterprise unter Windows Server 2012 in einer gemeinsam genutzten SAN/FCI-Konfiguration) auf SQL Server 2017 Enterprise unter Windows Server 2016 auf einem 2-Socket aktualisiert/32 core/768 GB RAM und lokale SSD-Laufwerke mit AlwaysOn AG. AG-Verkehr verwendet dedizierte 10G NIC-Ports mit gekreuzter Kabelverbindung).

Ihre Anforderung ist, dass alle Datenbanken zusammen ein Failover durchführen, sodass sie alle in einer einzigen AG zusammengefasst werden mussten. Es ist eine einzelne, nicht lesbare synchrone Replik auf einem identischen Server.

Die neuen Server sind seit Juni 2018 in Produktion. Die neuesten CU zu der Zeit CU7) und Windows-Updates wurden installiert, und das System funktionierte einwandfrei. Ungefähr einen Monat später, nachdem die Server von CU7 auf CU9 aktualisiert worden waren, bemerkten sie die folgenden Herausforderungen, die in der Reihenfolge ihrer Priorität aufgelistet waren.

Wir haben die Server mit SQL Sentry überwacht und keine physischen Engpässe festgestellt. Alle Schlüsselindikatoren scheinen gut zu sein. Die CPU hat einen Durchschnitt von 20%, IO mal normalerweise weniger als 1 ms, RAM nicht voll ausgelastet und Netzwerk <1%).

Herausforderungen

Die Symptome scheinen sich nach dem Failover zu bessern, treten jedoch innerhalb weniger Tage wieder auf, unabhängig davon, welcher Server primär ist - die Symptome sind auf beiden Servern identisch.

  1. Sporadische Client-Timeouts und Konnektivitätsfehler wie z

    ... beim Verbindungsaufbau ist ein Fehler aufgetreten ...

    oder

    Das Ausführungszeitlimit ist abgelaufen

    Manchmal dauern diese bis zu 40 Sekunden und lassen dann nach.

  2. Der Abschluss des Transaktionsprotokollsicherungsjobs dauert 10-mal länger als zuvor. Früher dauerte das Sichern der Protokolle aller 500 Datenbanken 2 bis 3 Minuten, jetzt 15 bis 25 Minuten. Wir haben überprüft, dass das Backup selbst bei gutem Durchsatz einwandfrei funktioniert. Nach Abschluss der Sicherung eines Protokolls und vor dem Start des nächsten Protokolls tritt jedoch eine kleine Verzögerung auf. es beginnt sehr niedrig, aber innerhalb von ein oder zwei Tagen erreicht es 2-3 Sekunden. Multipliziert mit 500 Datenbanken, und es gibt den Unterschied.

  3. Gelegentlich bleiben einige scheinbar zufällige Datenbanken nach dem manuellen Failover im Status "Nicht synchronisieren" hängen. Die einzige Möglichkeit, dies zu beheben, besteht darin, entweder den SQL Server-Dienst auf dem sekundären Replikat neu zu starten oder diese Datenbanken zu entfernen und der AG erneut zuzuordnen.

  4. Ein weiteres von CU10 eingeführtes Problem (das in CU11 nicht behoben wurde): Verbindungen zum sekundären Zeitlimit beim Blockieren von master.sys.databases und sogar nicht in der Lage, den SSMS-Objekt-Explorer für das sekundäre Replikat zu verwenden. Die Hauptursache scheint darin zu liegen, dass der Microsoft SQL Server VSS-Writer die folgende Abfrage ausgibt:

    select name, 
           recovery_model_desc, 
           state_desc, 
           CONVERT(integer, is_in_standby), 
           ISNULL(source_database_id,0) 
      from master.sys.databases
    

Beobachtungen

Ich glaube, ich habe die rauchende Waffe in den Fehlerprotokollen gefunden. Die Fehlerprotokolle sind voll von AG-Nachrichten, die als "nur zur Information" gekennzeichnet sind, aber anscheinend überhaupt nicht normal sind, und es besteht eine sehr starke Korrelation ihrer Häufigkeit mit den Anwendungsfehlern.

Es gibt verschiedene Arten von Fehlern, die in folgenden Sequenzen auftreten:

An manchen Tagen gibt es Zehntausende davon.

--- (Dieser Artikel beschreibt die gleiche Art von Fehlerfolge in SQL 2016 und sagt dort, dass sie abnormal ist. Dies erklärt auch das Phänomen "Nicht synchronisieren" nach dem Failover. Das besprochene Problem war für 2016 und wurde Anfang dieses Jahres in einer CU behoben. Es ist jedoch die einzige relevante Referenz, die ich für die ersten beiden Nachrichtentypen finden konnte, abgesehen von Verweisen auf automatische Initial Seeding-Nachrichten, die hier nicht der Fall sein sollten, da die AG bereits eingerichtet ist.

Hier ist eine Zusammenfassung der täglichen Fehler der letzten Woche für Tage mit> 10.000 Fehlern pro Typ auf dem PRIMARY (sekundär zeigt 'Verbindung mit primär verlieren ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Gelegentlich sehen wir auch "seltsame" Nachrichten wie:

Die Verfügbarkeitsgruppendatenbank "DB" ändert die Rollen von "SECONDARY" in "SECONDARY", da die Spiegelungssitzung oder Verfügbarkeitsgruppe aufgrund der Rollensynchronisierung ein Failover durchgeführt hat. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

... unter einer Vielzahl von Staaten, die sich von "SECONDARY" zu "RESOLVING" ändern.

Nach einem manuellen Failover kann das System mehrere Tage lang ohne eine einzige Meldung dieser Art auskommen, und plötzlich erhalten wir ohne ersichtlichen Grund Tausende auf einmal, was wiederum dazu führt, dass der Server nicht mehr reagiert und eine Anwendung verursacht Verbindungszeitüberschreitungen. Dies ist ein kritischer Fehler, da einige ihrer Anwendungen keinen Wiederholungsmechanismus enthalten und daher möglicherweise Daten verlieren. Wenn ein solcher Fehlerstoß auftritt, werden die folgenden Wartetypen Sky-Rocket. Dies zeigt die Wartezeiten direkt nachdem AG die Verbindung zu allen Datenbanken auf einmal verloren zu haben scheint:

(Waits when severe burst of AG errors occur

Ungefähr 30 Sekunden später wird in Bezug auf Wartezeiten alles wieder normal, aber die AG-Meldungen überfluten die Fehlerprotokolle immer wieder mit unterschiedlichen Raten und zu unterschiedlichen Tageszeiten, scheinbar zufälligen Zeiten, einschließlich außerhalb der Spitzenzeiten. Die gleichzeitige Erhöhung der Arbeitslast während dieser Fehler-Bursts macht die Sache natürlich noch schlimmer. Wenn nur wenige Datenbanken getrennt werden, tritt in der Regel keine Zeitüberschreitung bei Verbindungen auf, da die Lösung selbst schnell genug erfolgt.

Wir haben versucht zu überprüfen, ob es tatsächlich CU9 war, das das Problem ausgelöst hat, aber wir konnten beide Knoten nur auf CU9 herunterstufen. Versuche, einen der Knoten auf CU8 herunterzustufen, führten dazu, dass dieser Knoten im Status "Auflösen" hängen blieb und denselben Fehler im Protokoll aufwies:

Die persistente Konfiguration der Verfügbarkeitsgruppe Immer ein mit der entsprechenden Ressourcen-ID '… kann nicht gelesen werden. Die beibehaltene Konfiguration wird von einem SQL Server einer höheren Version geschrieben, der das primäre Verfügbarkeitsreplikat hostet. Aktualisieren Sie die lokale SQL Server-Instanz, damit das lokale Verfügbarkeitsreplikat zu einem sekundären Replikat wird.

Dies bedeutet, dass wir eine Ausfallzeit einführen müssen, um beide Knoten gleichzeitig auf CU8 herunterstufen zu können. Dies deutet auch darauf hin, dass die AG einige wichtige Aktualisierungen vorgenommen hat, die möglicherweise erklären, was wir erleben.

Wir haben bereits versucht, die max_worker_threads von der Standardeinstellung 0 (= 960 in unserer Box basierend auf dieser Artikel ) schrittweise auf 2.000 anzupassen, ohne dass dies Auswirkungen auf die Fehler hat.

Was können wir tun, um diese AG-Unterbrechungen zu lösen? Hat jemand da draußen ähnliche Probleme? Können andere Personen mit einer großen Anzahl von Datenbanken in einer AG möglicherweise ähnliche Meldungen im SQL-Fehlerprotokoll sehen, die mit CU9 oder CU8 beginnen?

Vielen Dank im Voraus für jede Hilfe!

15
SQLRaptor

Aktualisieren:

  1. Es wurde bestätigt, dass die Verbindungsabbrüche der Gruppe für häufige Verfügbarkeit eine von CU9 eingeführte Regression sind, und sie wurden nach der Installation von CU12 behoben.
  2. Es wurde bestätigt, dass die Blockierungsprobleme auf dem sekundären Replikat ein Problem mit einer Aktualisierung des in CU10 eingeführten VSS-Writer-Codes sind. Hoffentlich wird es in CU 13 behoben. Die vorläufige Lösung besteht darin, die VSS-Writer-DLLs manuell durch die Pre-CU10-DLLs zu ersetzen ...

    BEGIN RANT-SACTION;
    

    Leider scheint Microsoft nicht nur Windows 10-Updates, sondern auch unternehmenskritische Unternehmenssoftware wie SQL Server wiederholt nicht ordnungsgemäß zu überprüfen.

    Ich habe ihre bisherige Strategie der Service Packs sehr bevorzugt. Zumindest hatten sie genug Zeit, um sie ordnungsgemäß zu testen, bevor sie ihren Kunden eine Produktionskrise und Datenverluste zufügten, indem sie unachtsam halbgebackene Updates veröffentlichten.

    COMMIT RANT-SACTION;
    
9
SQLRaptor

Haben Sie die Worker-Threads überprüft? Normalerweise wird immer mehr Worker-Thread zum Arbeiten verwendet, und normalerweise reicht der Standardwert nicht aus. Ich hatte das gleiche Problem mit 600 Datenbanken in einer ständig aktiven Version. Daher fügen wir dem Instanzparameter weitere Threads hinzu, wodurch unser Problem behoben wurde. Hoffe das hilft!

2
Gonzalo bissio