Résoudre les problèmes rencontrés avec SQL Server Always On

Cet article vous aide à résoudre le problème courant lié à la configuration Always On sur SQL Server.

Note

Pour obtenir une expérience guidée de cet article, consultez Résolution des problèmes liés à SQL Server Always On.

Version de produit d’origine : SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Numéro de la base de connaissances d’origine : 10179

Remarques importantes

• Les données CSS De Microsoft indiquent qu’un pourcentage significatif de problèmes clients est souvent traité dans une mise à jour cu publiée, mais qu’il n’est pas appliqué de manière proactive et recommande donc l’installation continue et proactive des unités de certification au fur et à mesure qu’elles deviennent disponibles. Pour plus d’informations, consultez Annonce des mises à jour du modèle de maintenance incrémentielle SQL Server (ISM).

  Pour vérifier les dernières unités de gestion disponibles pour votre version, consultez Comment déterminer la version, l’édition et le niveau de mise à jour de SQL Server et de ses composants.

• Vous pouvez voir des outils utiles pour la résolution des problèmes et la surveillance des groupes de disponibilité Always On dans le Guide de résolution des problèmes et de surveillance des groupes de disponibilité Always On pour en savoir plus sur les outils que vous pouvez utiliser pour diagnostiquer différents types de problèmes et pour surveiller les groupes de disponibilité. Le guide propose également des scénarios supplémentaires qui peuvent ne pas être abordés dans cette procédure guidée.

• Le nœud parent pour la documentation des groupes de disponibilité Always On et fournit une référence unique pour différentes questions, consultez Groupes de disponibilité Always On (SQL Server).

J’ai besoin de pointeurs sur la configuration et la configuration des groupes de disponibilité Always On

Si vous recherchez de la documentation sur la configuration d’Always On, consultez les documents suivants :

Prise en main des groupes de disponibilité Always On (SQL Server) : le document fournit des réponses à de nombreuses questions que vous pouvez avoir sur les groupes de disponibilité et la configuration. En suivant toutes les étapes décrites dans cet article et en examinant les conditions préalables, les restrictions et les recommandations pour les groupes de disponibilité Always On (SQL Server), vous pouvez éviter de nombreux problèmes que vous pouvez rencontrer lors de la configuration et de la maintenance des groupes de disponibilité dans votre environnement.

Ressources supplémentaires

• Étape par étape : création d’un groupe de disponibilité Always On SQL Server 2012
• Guides d’architecture Always On
• Lien externe : groupes de disponibilité Always On SQL Server

Si ces informations ne sont pas utiles, consultez Plus d’informations sur les groupes de disponibilité Always On.

Je rencontre des problèmes lors de la configuration des groupes de disponibilité Always On

Les problèmes de configuration classiques incluent les groupes de disponibilité Always On sont désactivés, les comptes sont configurés de manière incorrecte, le point de terminaison de mise en miroir de bases de données n’existe pas, le point de terminaison est inaccessible (erreur SQL Server 1418), l’accès réseau n’existe pas et une commande de base de données de jointure échoue (erreur SQL Server 35250). Consultez le document suivant pour obtenir de l’aide sur la résolution de ces problèmes :

Résoudre des problèmes de configuration des groupes de disponibilité Always On (SQL Server)

Lien supplémentaire : Correction : Erreur 41009 lorsque vous essayez de créer plusieurs groupes de disponibilité

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Je rencontre des problèmes avec la configuration de l’écouteur (19471, 19476 et autres erreurs)

L’un des problèmes de configuration les plus courants rencontrés par les clients est la création de l’écouteur de groupe de disponibilité. Les erreurs sont similaires à ce qui suit :

• Msg 19471, Level 16, State 0, Line 2The WSFC cluster could not bring the Network Name resource with DNS name '' online. Le nom DNS peut avoir été pris ou avoir un conflit avec les services de noms existants, ou le service de cluster WSFC peut ne pas être en cours d’exécution ou peut être inaccessible. Utilisez un autre nom DNS pour résoudre les conflits de noms ou consultez le journal du cluster WSFC pour plus d’informations.

• Msg 19476, Level 16, State 4, Line 2The tentative de création du nom réseau et de l’adresse IP pour l’écouteur a échoué. Le service WSFC peut ne pas être en cours d’exécution ou être inaccessible dans son état actuel, ou les valeurs fournies pour le nom réseau et l’adresse IP peuvent être incorrectes. Vérifiez l’état du cluster WSFC et validez le nom réseau et l’adresse IP avec l’administrateur réseau.

La plupart du temps, l’échec de création de l’écouteur résultant des messages précédents est dû à un manque d’autorisations pour l’objet CNO (Cluster Name Object) dans Active Directory pour créer et lire l’objet ordinateur de l’écouteur. Pour résoudre ce problème, consultez les articles suivants :

• Échec de la création de l’écouteur avec le message « Le cluster WSFC n’a pas pu mettre en ligne la ressource Nom du réseau »

• Résolution des problèmes de création de l’écouteur de groupe de disponibilité Always On dans SQL Server 2012

• Configurer un écouteur Always On pour un groupe de disponibilité

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Le basculement automatique ne fonctionne pas comme prévu

Si vous remarquez que le basculement automatique ne fonctionne pas comme prévu pendant les tests ou en production, consultez : Résolution des problèmes de basculement automatique dans les environnements Always On SQL Server 2012.

La configuration incorrecte des défaillances maximales dans la période spécifiée est l’une des principales causes du basculement automatique du serveur principal vers la base de données secondaire. La valeur par défaut de ce paramètre est N-1, où N correspond au nombre de réplicas. Pour plus d’informations, consultez La limite maximale des échecs du cluster de basculement (groupe).

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Je rencontre des problèmes de connexion à des groupes de disponibilité Always On

Après avoir configuré l’écouteur du groupe de disponibilité pour un groupe de disponibilité Always On dans SQL Server 2012, vous ne pouvez peut-être pas effectuer un test ping sur l’écouteur ou vous y connecter à partir d’une application. Vous pouvez obtenir une erreur similaire à ce qui suit :

Sqlcmd : Erreur : Microsoft SQL Native Client : expiration du délai d’expiration de la connexion.

Pour résoudre ces erreurs et les erreurs similaires, passez en revue les éléments suivants :

• Erreur de délai d’attente et vous ne pouvez pas vous connecter à un écouteur de groupe de disponibilité Always On SQL Server 2012 dans un environnement multi-sous-réseau
• Délais d’expiration de connexion dans un groupe de disponibilité à plusieurs sous-réseaux

Liens d’informations supplémentaires :

• Une mise à jour introduit la prise en charge des fonctionnalités Always On dans SQL Server 2012 ou une version ultérieure pour the.NET Framework 3.5 SP1
• Clustering de sous-réseaux multiples SQL Server (SQL Server)

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Je rencontre des problèmes lors de la configuration des groupes de disponibilité Always On dans ma machine virtuelle Azure (IaaS)

1. De nombreux problèmes liés à Always On se produisent en raison d’une configuration incorrecte de l’écouteur. Si vous rencontrez des problèmes de connexion à l’écouteur,

   1. Vérifiez que vous lisez toutes les limitations de l’écouteur ILB et suivez toutes les étapes décrites dans l’article suivant qui portent une attention particulière à la configuration des dépendances, à l’adresse IP et à divers autres paramètres dans le script PowerShell.

   2. Si vous ne savez pas, vous souhaiterez peut-être supprimer et recréer l’écouteur conformément au document ci-dessus.

2. Si vous avez récemment déplacé votre machine virtuelle vers un autre service ou si les adresses IP ont changé, vous devez mettre à jour la valeur de la ressource d’adresse IP pour refléter la nouvelle adresse et recréer le point de terminaison à charge équilibrée pour votre groupe de disponibilité. Vous pouvez mettre à jour l’adresse IP à l’aide des commandes ou Set des Get commandes comme suit :

   Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
   

Documents recommandés :

• Configurer un équilibreur de charge pour un groupe de disponibilité SQL Server Always On dans Azure Machines Virtuelles

• Recommandations et meilleures pratiques lors du déploiement de groupes de disponibilité Always On SQL Server dans Microsoft Azure (IaaS)

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Il faut beaucoup de temps pour basculer du serveur principal vers le serveur secondaire ou inversement

Après un basculement automatique ou un basculement manuel planifié sans perte de données sur un groupe de disponibilité, vous constaterez peut-être que le temps de basculement dépasse votre RTO (objectif de temps de récupération). Pour résoudre les causes et les résolutions potentielles, consultez Résoudre les problèmes suivants : Groupe de disponibilité dépassé RTO.

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Les modifications sur le réplica principal ne sont pas reflétées ou lentes à répliquer sur le réplica secondaire

Vous remarquerez peut-être que les modifications sur le réplica principal ne sont pas propagées au réplica secondaire en temps opportun. Pour résoudre et résoudre ces problèmes, essayez les éléments suivants :

• Pour les environnements SQL Server 2012 et SQL Server 2014, consultez CORRECTIF : Synchronisation lente lorsque les disques ont des tailles de secteur différentes pour les fichiers journaux de réplica principal et secondaire dans les environnements DE groupe de disponibilité SQL Server et Logshipping.

• Vérifiez si les nœuds secondaires sont dans un état suspendu dans l’administrateur du cluster.

• Consultez Résoudre les problèmes : les modifications sur le réplica principal ne sont pas répercutées sur le réplica secondaire.

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Comment gérer la taille du journal des transactions pour mes bases de données de groupe de disponibilité

Vous pouvez réduire les tailles du journal des transactions en configurant des sauvegardes régulières sur des serveurs principaux ou secondaires.

Pour plus d’informations, consultez les rubriques suivantes :

• Décharger les sauvegardes prises en charge sur les réplicas secondaires d’un groupe de disponibilité
• Exécution de sauvegardes du journal des transactions à l’aide de réplicas secondaires en lecture seule du groupe de disponibilité Always On - Partie 1

Si ces informations ne sont pas utiles, consultez Plus d’informations sur les groupes de disponibilité Always On.

Serveurs principaux ou secondaires frappés dans l’état de résolution ou vous rencontrez des basculements inattendus

• Vérifiez les journaux des événements système et application pour connaître les problèmes matériels et d’autres erreurs et contactez le fournisseur pour les corriger.

• Si vous utilisez des machines virtuelles, vérifiez leur base de connaissances pour voir s’il existe des problèmes récemment signalés qui peuvent contribuer au problème. Par exemple, une perte de paquets volumineuse au niveau du système d’exploitation invité sur la carte réseau virtuelle VMXNET3 dans ESXi (2039495) a provoqué des problèmes de configuration du groupe de disponibilité dans certains cas.

• Informations supplémentaires :

  • Diagnostiquer un basculement inattendu ou un groupe de disponibilité dans l’état RÉSOLUTION
  • Lien externe : SQL SERVER - Groupe de disponibilité Always On bloqué dans la résolution de l’état pendant longtemps

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Impossible de mettre les ressources en ligne

Vérifiez si les bases de données prennent beaucoup de temps pour récupérer en examinant les messages dans sql ErrorLog.

Si le problème existe toujours, consultez Plus d’informations sur les groupes de disponibilité Always On.

Forum aux questions

1. Est-il possible d’avoir deux écouteurs pour un groupe de disponibilité ?

   Oui, vous pouvez configurer plusieurs écouteurs pour le même groupe de disponibilité. Découvrez comment créer plusieurs écouteurs pour le même groupe de disponibilité (Goden Yao).

2. Est-il possible d’avoir une carte de carte réseau distincte pour toujours le trafic et la connectivité client ?

   Oui, vous pouvez avoir une carte de carte réseau dédiée pour le trafic Always On. Consultez Configurer le groupe de disponibilité pour communiquer sur un réseau dédié.

3. Quelles éditions prennent en charge les instances de cluster de basculement Always On ?

   Cette rubrique de la documentation en ligne de SQL Server contient plus d’informations : éditions et fonctionnalités prises en charge pour SQL Server 2016.

4. Comment récupérer en cas de défaillance sur tous les nœuds de votre cluster ?

   Consultez la récupération d’urgence WSFC par le biais du quorum forcé (SQL Server).

5. Où puis-je trouver des informations sur la prise en charge des transactions distribuées dans les configurations de groupe de disponibilité ?

   Consultez Transactions : groupes de disponibilité et mise en miroir de bases de données.

6. Comment mettre à jour les configurations Always On ?

   Consultez Mise à niveau des instances de réplica de groupe de disponibilité Always On.

7. Comment ajouter une base de données TDE (Transparent Data Encryption) à la configuration du groupe de disponibilité ?

   Pour ajouter la base de données activée par TDE au groupe de disponibilité, consultez Comment configurer Always On pour une base de données TDE.

8. Comment configurer des alertes pour vérifier si le secondaire est en retard derrière le serveur principal ?

   Vous pouvez utiliser le script suivant :

   SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
   dr_state.database_id AS database_id,
   is_ag_replica_local = CASE
       WHEN ar_state.is_local = 1 THEN N'LOCAL'
       ELSE 'REMOTE'
       END,
   ag_replica_role = CASE
       WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
       ELSE ar_state.role_desc
       END,
   dr_state.last_hardened_lsn, dr_state.last_hardened_time,
   datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
   FROM (( sys.availability_groups AS ag
   JOIN sys.availability_replicas AS ar
       ON ag.group_id = ar.group_id)
   JOIN sys.dm_hadr_availability_replica_states AS ar_state
       ON ar.replica_id = ar_state.replica_id)
   JOIN sys.dm_hadr_database_replica_states dr_state
       ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
   

9. Comment obtenir une alerte si l’état de la base de données est autre que synchronisé ?

   Vous pouvez utiliser le script suivant :

   SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
   dr_state.database_id AS database_id,
   is_ag_replica_local = CASE
       WHEN ar_state.is_local = 1 THEN N'LOCAL'
       ELSE 'REMOTE'
       END,
   ag_replica_role = CASE
       WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
       ELSE ar_state.role_desc
       END,
   ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
   FROM (( sys.availability_groups AS ag
   JOIN sys.availability_replicas AS ar
       ON ag.group_id = ar.group_id )
   JOIN sys.dm_hadr_availability_replica_states AS ar_state
       ON ar.replica_id = ar_state.replica_id)
   JOIN sys.dm_hadr_database_replica_states dr_state
       ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
   

   Vous pouvez également consulter les liens suivants pour obtenir des méthodes supplémentaires pour surveiller les groupes Always On :

   • Gestion basée sur des stratégies pour les problèmes opérationnels avec les groupes de disponibilité Always On

   • Lien externe : Utilisation de la gestion basée sur des stratégies pour les alertes de perte de données des groupes de disponibilité SQL Server

   • Comportement du témoin dynamique sur le clustering de basculement Windows Server 2012 R2

Plus d’informations sur les groupes de disponibilité Always On

• Guide de surveillance et de résolution des problèmes des groupes de disponibilité Always On
• Groupes de disponibilité Always On : une solution de haute disponibilité et de récupération d’urgence