La base de données du groupe de disponibilité reste dans la restauration trop longtemps après un basculement
Architecture: J'ai 2 Node Configuration Sync-Commit AlwaysOn s'exécutant sur un cluster de basculement multi-sous-réseau. Le nœud principal est en Le nœud Europe et secondaire est aux États-Unis. Je n'ai qu'une seule base de données dans le groupe de disponibilité qui est OperationsManager db de SCOM.
- Les hôtes primaires et secondaires sont identiques.
- Version de SQL Server sur les deux boîtes: 13.0.5237 et Windows Core
- Mise à jour: j'ai corrigé les deux serveurs à 10.0.5270.0, cela n'a pas aidé.
- DB VLF count est seulement 27.
Problème: Lorsque j'initie un basculement, la base de données bascule avec succès du nœud principal au nœud secondaire en quelques secondes. Cependant, la nouvelle base de données secondaire (ancienne principale) entre en phase de restauration/récupération et y reste pendant environ 30 minutes.
Résultats: J'ai cherché à ce sujet sur Internet et j'ai lu la documentation pour enquêter sur le problème. Lorsque le changement de rôle du primaire au secondaire est terminé, la nouvelle base de données secondaire passe par 3 phases:
État de synchronisation: "PAS DE SYNCHRONISATION"; État de la base de données: EN LIGNE
État de synchronisation: "PAS DE SYNCHRONISATION"; État de la base de données: RÉCUPÉRATION
État de synchronisation: "REVERTING"; État de la base de données: RÉCUPÉRATION
Dans mon cas, tout le temps a été consacré à la dernière étape. J'ai également surveillé le processus d'annulation en examinant le compteur perfmon " SQLServer: réplique de la base de données Journal restant pour l'annulation"
J'ai vérifié le site principal avant les tests de basculement pour repérer les transactions de longue durée ou les transactions ouvertes, mais je n'ai pas pu en trouver. Après le basculement, le "journal restant à annuler" était d'environ 30 Mo et il fallait 30 minutes à la base de données secondaire pour revenir à l'état "synchronisé". Lorsque l'on considère que nous fonctionnons en mode Sync-Commit et qu'il y a une petite charge de travail sur le primaire, cela ne devrait pas prendre 30 minutes pour la répétition de la phase à mon humble avis.
Journal d'erreurs SQL Server: J'ai trouvé ces étranges messages.
Échec du durcissement à distance de la transaction 'RECEIVE MSG' (ID 0x000000004d52c65a 0001: 01c4e415) démarrée le 22 février 2019 à 14h55 dans la base de données 'OperationsManager' sur LSN (2558: 107841: 1).
Échec du durcissement à distance de la transaction 'GhostCleanupTask' (ID 0x000000004d6d15aa 0001: 01c4eaa0) démarrée le 22 février 2019 à 14h59 dans la base de données 'OperationsManager' sur LSN (2558: 107843: 46).
Le basculement démarre: 
Le basculement se termine: 
En tout
Avez-vous déjà vu ce problème auparavant? Avez-vous des recommandations?
Une chose à vérifier lorsque la récupération de la base de données est longue, qu'il s'agisse d'une restauration normale ou d'un basculement AG, est votre VLF count. Avoir beaucoup de VLF (milliers ou dizaines de milliers), ou VLF de une taille inhabituelle (un ou deux VLF extrêmement grands) entraînera un ralentissement de ce processus.
Exécutez la commande suivante sur votre base de données en question:
USE YourDatabaseName;
GO
DBCC LOGINFO;
Remarque: si vous utilisez SQL Server 2016 SP2 ou une version plus récente, vous pouvez utiliser cette fonction de gestion dynamique au lieu de la commande DBCC: sys.dm_db_log_info
Le nombre de lignes qui revient est le nombre de VLF que vous avez. Si ce nombre est très élevé, ou si la colonne FileSize montre des valeurs extrêmes extrêmes parmi vos VLF, vous pouvez probablement résoudre le problème de récupération lente en (à un niveau élevé):
- réduire le fichier journal aussi petit que possible
- repoussant à sa taille cible
- s'assurer que la croissance automatique est définie sur un nombre raisonnable en fonction de votre taux de croissance de journal typique et de la fréquence de vos sauvegardes de journal des transactions
Les détails de la correction de VLF problèmes de dimensionnement ont été largement abordés ailleurs, voici un exemple: n guide DBA occupé/accidentel pour gérer les VLF
Comme déjà répondu VLF serait aussi mon premier choix pour commencer. Une autre chose que je considérerais est de regarder la correspondance infra entre 2 nœuds.
Oui, je sais que ce sont des choses à considérer avant de configurer votre serveur pour qu'il soit prêt à être construit. Mais cela arrive parfois comme dans notre cas pour l'un des scénarios où un autre nœud avait un système de stockage complètement différent fourni par rapport à son nœud de réplique principal. Nous avions des SSD sur la réplique principale tandis que SAN stockage sur la réplique secondaire car c'était un manque de l'équipe de stockage et donc lorsque nous faisions un basculement, ils semblent prendre un certain temps.
Le meilleur pari rassemble toutes les mesures de performance et essaie de comparer entre 2 répliques pour trouver si tout semble bon. Pas obligatoire d'être le même, mais bon d'avoir si vous allez tester DR et exécuter la charge à partir d'un autre centre de données ou d'une nouvelle réplique principale après le basculement AG
Nous avons le même problème avec la base de données du client et la cause principale était une grande quantité de données des clients utilisant FreeBCP pour insérer leurs données en bloc. Notre solution de contournement a été de désactiver l'insertion en vrac avant le basculement manuel permanent.