SQL Server 2017 avec 500 bases de données - Déconnexions fréquentes d'AG depuis CU9

15

Salut tout le monde et merci d'avance pour votre aide. Nous rencontrons des difficultés avec les groupes de disponibilité SQL Server 2017.

Contexte

La société est un logiciel back-end B2B de détail. Environ 500 bases de données à locataire unique et 5 bases de données partagées utilisées par tous les locataires. La caractéristique de charge de travail est principalement lue, et la majorité des bases de données ont une activité très faible.

Les serveurs de production physiques hébergés au même emplacement ont récemment été mis à niveau de SQL Server 2014 Enterprise sur Windows Server 2012 dans une configuration SAN / FCI partagée, vers SQL Server 2017 Enterprise sur Windows Server 2016 sur 2 sockets / 32 cœurs / 768 Go de RAM et local Disques SSD utilisant AlwaysOn AG. Le trafic AG utilise des ports NIC 10G dédiés avec une connexion par câble croisé.

Leur exigence est que toutes les bases de données basculent ensemble, elles ont donc dû les mettre toutes dans un seul AG. Il s'agit d'une seule réplique synchrone non lisible sur un serveur identique.

Les nouveaux serveurs sont en production depuis juin 2018. Les dernières mises à jour CU (CU7 à l'époque) et Windows ont été installées et le système fonctionnait bien. Environ un mois plus tard, après avoir mis à jour les serveurs de CU7 à CU9, ils ont commencé à remarquer les défis suivants, classés par ordre de priorité.

Nous avons surveillé les serveurs à l'aide de SQL Sentry et n'avons observé aucun goulot d'étranglement physique. Tous les indicateurs clés semblent bons. Le processeur est en moyenne de 20%, les temps d'E / S généralement inférieurs à 1 ms, la RAM n'est pas entièrement utilisée et le réseau <1%.

Défis

Les symptômes semblent s'améliorer après le basculement, mais réapparaissent dans quelques jours, quel que soit le serveur principal - les symptômes sont identiques sur les deux serveurs.

  1. Expirations sporadiques de clients et échecs de connectivité tels que

    ... une erreur s'est produite lors de l'établissement de la connexion ...

    ou

    Délai d'expiration expiré

    Parfois, ceux-ci durent jusqu'à 40 secondes, puis disparaissent.

  2. La tâche de sauvegarde du journal des transactions prend 10 fois plus de temps qu’auparavant. Auparavant, il fallait 2 à 3 minutes pour sauvegarder les journaux des 500 bases de données, maintenant cela prend 15-25. Nous avons vérifié que cette sauvegarde elle-même fonctionne correctement avec un bon débit. Cependant, il y a un petit délai après avoir terminé la sauvegarde d'un journal et avant de commencer le suivant. il commence très bas, mais en un jour ou deux, il atteint 2-3 secondes. Multiplié par 500 bases de données, et il y a la différence.

  3. Parfois, certaines bases de données apparemment aléatoires restent bloquées dans l'état "Non synchronisé" après un basculement manuel. La seule façon de résoudre ce problème consiste à redémarrer le service SQL Server sur le réplica secondaire ou à supprimer et à rejoindre ces bases de données à l'AG.

  4. Un autre problème introduit par CU10 (et non résolu dans CU11): les connexions au délai d'expiration secondaire lors du blocage sur master.sys.databases et même l'impossibilité d'utiliser l'explorateur d'objets SSMS pour la réplique secondaire. La cause première semble être bloquée par le rédacteur VSS de Microsoft SQL Server émettant la requête suivante:

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

Observations

Je crois avoir trouvé le pistolet fumant dans les journaux d'erreurs. Les journaux d'erreurs sont remplis de messages AG, qui sont étiquetés comme `` informatifs uniquement '', mais il semble qu'ils ne soient pas normaux du tout, et il existe une très forte corrélation de leur fréquence avec les erreurs d'application.

Les erreurs sont de plusieurs types et se présentent en séquences:

  • DbMgrPartnerCommitPolicy :: SetSyncState: GUID

  • DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

  • La connexion des groupes de disponibilité AlwaysOn avec la base de données secondaire s'est terminée pour la base de données principale 'XYZ' sur le réplica de disponibilité 'DB' avec l'ID de réplique: {GUID}. Il s'agit d'un message d'information uniquement. Aucune action de l'utilisateur n'est requise.

  • Connexion des groupes de disponibilité AlwaysOn avec la base de données secondaire établie pour la base de données primaire 'ABC' sur le réplica de disponibilité 'DB' avec l'ID de réplique: {GUID}. Il s'agit d'un message d'information uniquement. Aucune action de l'utilisateur n'est requise.

Certains jours, il y en a des dizaines de milliers.

Cet article décrit le même type de séquence d'erreurs sur SQL 2016 et il dit qu'il est anormal. Cela explique également le phénomène de «non synchronisation» après le basculement. Le problème discuté concernait 2016 et a été résolu plus tôt cette année dans une UC. cependant, c'est la seule référence pertinente que j'ai pu trouver pour les 2 premiers types de messages, à part les références aux messages d'amorçage initial automatiques qui ne devraient pas être le cas ici car l'AG est déjà établie.

Voici un résumé des erreurs quotidiennes de la semaine dernière, pour les jours qui avaient> 10 000 erreurs par type sur le PRIMAIRE (le secondaire affiche «perte de connexion avec le primaire ...»):

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

Nous voyons également occasionnellement des messages "étranges" tels que:

La base de données du groupe de disponibilité «DB» modifie les rôles de «SECONDARY» à «SECONDARY» car la session de mise en miroir ou le groupe de disponibilité a basculé en raison de la synchronisation des rôles. Il s'agit d'un message d'information uniquement. Aucune action de l'utilisateur n'est requise.

... parmi une multitude d'États changeants de "SECONDAIRE" à "RÉSOLU".

Après un basculement manuel, le système peut fonctionner pendant plusieurs jours sans un seul message de ce type, et tout d'un coup, sans raison apparente, nous en obtiendrons des milliers à la fois, ce qui à son tour fait que le serveur ne répond plus et provoque l'application délais de connexion. Il s'agit d'un bogue critique car certaines de leurs applications n'intègrent pas de mécanisme de nouvelle tentative et peuvent donc perdre des données. Quand une telle rafale d'erreurs se produit, les types d'attente suivants fusent le ciel. Cela montre les attentes juste après qu'AG semble avoir perdu la connexion à toutes les bases de données à la fois:

Attend lorsqu'une grave rafale d'erreurs AG se produit

Environ 30 secondes plus tard, tout revient à la normale en termes d'attente, mais les messages AG continuent d'inonder les journaux d'erreurs à des taux variables et à différentes heures de la journée, des heures apparemment aléatoires, y compris en dehors des heures de pointe. L'augmentation simultanée de la charge de travail pendant ces salves d'erreur aggrave bien sûr les choses. Si seules quelques bases de données sont déconnectées, cela n'entraîne généralement pas l'expiration des connexions car elle est résolue assez rapidement par elle-même.

Nous avons essayé de vérifier que c'était bien CU9 qui avait déclenché le problème, mais nous avons pu rétrograder les deux nœuds uniquement vers CU9. Les tentatives de rétrogradation de l'un des nœuds vers CU8 ont entraîné le blocage de ce nœud dans l'état 'Resolving', affichant la même erreur dans le journal:

Impossible de lire la configuration persistante du groupe de disponibilité Always On avec l'ID de ressource correspondant '…. La configuration persistante est écrite par un SQL Server de version supérieure qui héberge le réplica de disponibilité principal. Mettez à niveau l'instance SQL Server locale pour permettre au réplica de disponibilité locale de devenir un réplica secondaire.

Cela signifie que nous devrons introduire un temps d'arrêt pour pouvoir rétrograder les deux nœuds en CU8 en même temps. Cela suggère également qu'il y a eu une mise à jour majeure d'AG qui peut expliquer ce que nous vivons.

Nous avons déjà essayé d'ajuster le max_worker_threads à partir de sa valeur par défaut de 0 (= 960 sur notre boîte basée sur cet article ) progressivement jusqu'à 2000 sans aucun impact observé sur les erreurs.

Que pouvons-nous faire pour résoudre ces déconnexions AG? Quelqu'un connaît-il des problèmes similaires? D'autres personnes disposant d'un grand nombre de bases de données dans un AG peuvent-elles voir des messages similaires dans le journal des erreurs SQL commençant par CU9 ou CU8?

Merci d'avance pour votre aide!

SQLRaptor
la source

Réponses:

9

Mise à jour:

  1. Les déconnexions du groupe de disponibilité fréquente ont été confirmées comme une régression introduite par CU9 et elles ont été résolues après l'installation de CU12.
  2. Les problèmes de blocage sur la réplique secondaire se sont avérés être un problème avec une mise à jour du code d'écriture VSS qui a été introduite dans CU10. Espérons que cela sera résolu dans CU 13. La solution provisoire consiste à remplacer manuellement les DLL de l'écrivain VSS par les DLL Pre-CU10 ...

    BEGIN RANT-SACTION;

    Malheureusement, Microsoft semble échouer à plusieurs reprises à assurer correctement l'AQ non seulement les mises à jour de Windows 10, mais aussi les logiciels critiques pour l'entreprise tels que SQL Server.

    J'ai préféré de loin leur stratégie précédente de service packs, au moins ils ont eu assez de temps pour les tester correctement avant d'infliger une crise de production et une perte de données à leurs clients avec une publication négligente de mises à jour à moitié cuites.

    COMMIT RANT-SACTION;
SQLRaptor
la source
2

Avez-vous vérifié les threads de travail? Normalement, toujours utiliser plus de threads de travail pour travailler et normalement la valeur par défaut n'est pas suffisante. J'ai eu le même problème avec 600 bases de données en permanence, nous ajoutons donc plus de threads sur le paramètre d'instance et cela a résolu notre problème. J'espère que cela t'aides!

Gonzalo bissio
la source
2
Salut @Gonzalo et merci pour les conseils. Nous avons déjà couvert l'angle de réglage de max_worker_threads, bien que nous n'ayons pas rencontré d'erreurs telles que «aucun thread de travail disponible» qui sont communs aux cas où il n'y a pas assez de threads. La valeur par défaut pour notre boîte était inférieure à 1 k threads, nous l'avons augmentée progressivement jusqu'à 2 k sans impact observé sur les erreurs. Nous collectons des métriques de threads de travail, et elles sont en moyenne d'environ 1500, y compris les threads AG qui ne sont pas comptabilisés dans le maximum. Par conséquent, nous sommes loin de la limite de threads.
SQLRaptor