Symptômes
Supposons que vous utilisez Microsoft SQL Server 2016 ou 2017. Lorsqu’un groupe de disponibilité rejoint un groupe de disponibilité distribué (DAG) existant immédiatement après avoir été supprimé et recréé, il peut ne pas rejoindre le DAG et vous recevez les messages d’erreur similaires aux suivants :
Always On : notification de modification de la configuration du processus AG pour AG 'AGName' dans l’état 'FORWARDER' (7).
Error : 41162, Severity : 16, State : 0.
Échec de la validation du numéro de séquence de la configuration du groupe de disponibilité « AGName ». Le numéro de séquence en mémoire ne correspond pas au numéro de séquence persistant. Le groupe de disponibilité et/ou la réplica de disponibilité locale sont redémarrés automatiquement. Aucune action de l’utilisateur n’est requise pour le moment.
Always On : AR 'AGName' traite désormais les notifications (type 64).
Always On : notification de modification de la configuration du processus AG pour AG 'AGName' dans l’état 'FORWARDER' (7).
Always On : AR 'AGName' valide désormais l’intégrité AG dans WSFC.
Always On : Transition de rôle AR 'AGName' [FORWARDER] --> [FORWARDER], trigger [VALIDATE_AG_CONFIG], state (wsfc = 1, metadata = 1).
Always On : AR 'AGName' traite désormais les notifications (type -2).
De plus, l’erreur 41162 peut entraîner l’état de résolution AG et provoquer deux autres problèmes : l’erreur 19407 et l’échec de l’assertion.
Erreur 19407 :
Les transactions non qualifiées sont restaurées dans la base de données DBName pour une modification de l’état des groupes de disponibilité Always On. Achèvement estimé de la restauration : 100 %. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
[HaDrDbMgr ::SetPrimaryAR] Définition du principal en tant qu’AGID : AGNumber, ReplicaID : ReplicaNumber, AGDBID : AGDBNumber
Erreur : 19407, Gravité : 16, État : 2.
Le bail entre le groupe de disponibilité « GroupName » et le cluster de basculement Windows Server a expiré. Un problème de connectivité s’est produit entre l’instance de SQL Server et le cluster de basculement de Windows Server. Pour déterminer si le groupe de disponibilité bascule correctement, case activée la ressource de groupe de disponibilité correspondante dans le cluster de basculement Windows Server.
Assertion :
Always On : notification de modification de la configuration du groupe de disponibilité pour AG « DatabaseName » dans l’état « RESOLVING_NORMAL » (0).
Always On : AR 'DatabaseName' valide désormais l’intégrité AG dans WSFC.
Always On : GetTransportWithRef() est rejeté, car la RA locale n’est pas en ligne.
Informations d’état de la base de données « DatabaseName » - Lsn renforcé : '(34:304752:1)' Valider LSN : '(0:0:0)' Heure de validation : 'Jan 1 1900 12:00AM'
RECOVERY (DatabaseName, 6) : Début de l’arrêt des travaux de restauration parallèles
**Dump thread - spid = 0, EC = 0x000001F280CC7250
Vidage de pile envoyé à FileLocation
* COMMENCER LE VIDAGE DE LA PILE :
* Emplacement : « FileLocation » :1774
* expression : GetContext ()->GetController ()->GetHadrArRoleExternal () == HADR_ROLE_FORWARDING_SECONDARY
* SPID : SPId
* ID du processus : ProcessId
Erreur : 17066, Gravité : 16, État : 1.
SQL Server Assertion : file : <« filelocation »>, line=1774 Échec de l’assertion = 'GetContext ()->GetController ()->GetHadrArRoleExternal () == HADR_ROLE_FORWARDING_SECONDARY'. Cette erreur peut être liée à la minutage. Si l’erreur persiste après la réexécution de l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de case activée ou redémarrez le serveur pour vous assurer que les structures de données en mémoire ne sont pas endommagées.
Erreur : 3624, Gravité : 20, État : 1.
Une case activée d’assertion système a échoué. Pour plus d’informations, consultez le journal des erreurs de SQL Server. En règle générale, un échec d’assertion est causé par un bogue logiciel ou une altération des données. Pour vérifier la case activée pour la base de données endommagée, envisagez d’exécuter DBCC CHECKDB. Si vous avez accepté d’envoyer des vidages à Microsoft pendant l’installation, un mini-vidage sera envoyé à Microsoft. Une mise à jour peut être disponible auprès de Microsoft dans le dernier Service Pack ou dans un correctif du Support technique.
État
Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Résolution
Ce problème est résolu dans la mise à jour cumulative suivante pour SQL Server :
À propos des mises à jour cumulatives pour SQL Server :
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Informations sur le correctif logiciel à la demande :
Ce problème est résolu dans le correctif logiciel à la demande suivant pour SQL Server :
Références
En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.