SQL Server 2017 avec 500 bases de données - Déconnexions fréquentes d'AG depuis CU9
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 à partir de SQL Server 2014 Enterprise sur Windows Server 2012 dans une configuration partagée SAN/FCI, vers SQL Server 2017 Enterprise sur Windows Server 2016 sur un socket 2)/32 core/768 Go RAM et lecteurs SSD locaux utilisant AlwaysOn AG. Le trafic AG utilise des ports 10G NIC NIC $ avec une connexion par câble croisée).
Leur exigence est que toutes les bases de données basculent ensemble, elles ont donc dû toutes les regrouper 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, répertorié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%, IO fois généralement moins de 1 ms, RAM non pleinement utilisée et réseau <1%).
Défis
Les symptômes semblent s'améliorer après le basculement, mais réapparaissent en quelques jours, quel que soit le serveur principal - les symptômes sont identiques sur les deux serveurs.
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.
La tâche de sauvegarde du journal des transactions prend 10 fois plus de temps qu'à terminer. 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.
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.
Un autre problème introduit par CU10 (et non résolu dans CU11): Connexions au délai d'expiration secondaire sur le blocage sur master.sys.databases et même incapable 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 semblent ne pas être 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 principale '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 traite du même type de séquence d'erreurs sur SQL 2016 et là, il dit que c'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 "bizarres" 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 à 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:
Environ 30 secondes plus tard, tout revient à la normale en termes d'attentes, 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 "Résolution", 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 en fonction de cet article ) progressivement jusqu'à 2000 sans 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!
Mise à jour:
- 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.
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é introduit 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 sortie imprudente de mises à jour à moitié cuites.
COMMIT RANT-SACTION;
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!