Déterminer la cause possible des problèmes de connectivité entre des réplicas de disponibilité

  • Article

S’applique à :SQL Server

Des problèmes physiques, de système d'exploitation ou SQL Server peuvent provoquer un échec dans une session entre deux réplicas de disponibilité. Un réplica de disponibilité ne contrôle pas régulièrement les composants sur lesquels sqlservr.exe s’appuie pour vérifier s’ils fonctionnent correctement ou s’ils ont échoué. Toutefois, pour certains types d’échecs, le composant affecté signale une erreur à sqlservr.exe. Une erreur signalée par un autre composant est appelée erreur matérielle.

Pour détecter les autres erreurs qui passeraient sinon inaperçues, les groupes de disponibilité AlwaysOn implémentent leur propre mécanisme de délai d’expiration de session. Le délai d’expiration de la session est spécifié en secondes. Ce délai d'attente est la durée maximale pendant laquelle une instance de serveur attend de recevoir un message PING d'une autre instance avant de considérer que cette dernière est déconnectée. Quand un délai d’expiration de session se produit entre deux réplicas de disponibilité, les réplicas de disponibilité partent du principe qu’une erreur s’est produite et déclarent une erreur logicielle.

Important

Les défaillances dans les bases de données autres que la base de données primaire ne sont pas détectables. En outre, il est peu vraisemblable qu'une défaillance du disque de données soit détectée, sauf si la base de données est redémarrée en raison de la défaillance d'un disque de données.

Le temps de détection de l'erreur et, par extension, le temps de réaction face à une erreur, varient selon que l'erreur est matérielle ou logicielle. Certaines erreurs matérielles, telles que les pannes de réseau sont signalées immédiatement. Cependant, il arrive parfois que des délais d'attente spécifiques à un composant retardent la signalisation de certaines erreurs matérielles. Pour les erreurs logicielles, la durée du délai d'expiration de session détermine la vitesse de détection de l'erreur. Par défaut, cette valeur est de 10 secondes. Il s'agit de la valeur minimale recommandée.

Défaillances dues à des erreurs matérielles

Parmi les causes possibles d’erreurs matérielles figurent notamment, sans s’y limiter, les situations suivantes :

  • une connexion ou un câble coupé ;
  • une carte réseau défaillante ;
  • un changement de routeur ;
  • des modifications au pare-feu ;
  • une reconfiguration du point de terminaison ;
  • la perte du lecteur où se trouve le journal de transactions ;
  • une défaillance du système d'exploitation ou d'un processus.

Par exemple, lorsque le lecteur de journalisation de la base de données primaire cesse de répondre et échoue, le système d’exploitation informe sqlservr.exe qu’une erreur grave s’est produite.

Certains composants, tels que les composants réseau et certains sous-systèmes d’E/S, ont leurs propres délais d’attente pour détecter les défaillances. Ces délais sont indépendants des groupes de disponibilité AlwaysOn, qui n’en ont pas connaissance et ne sont pas tenus au courant de leur comportement. Dans ces cas, le délai d'attente augmente la durée entre une défaillance et la réception de son erreur matérielle par le réplica de disponibilité.

Notes

C'est uniquement dans le cas des erreurs logicielles que la détection des erreurs appliquée aux réplicas de disponibilité est active. Pour plus d'informations, consultez « Défaillances dues à des erreurs logicielles » plus loin dans cette rubrique.

Pour vous aider à interpréter les conditions d'erreur qui se produisent sur le réseau, demandez à un ingénieur réseau quels messages d'erreur sont envoyés à un port lorsque les événements ci-dessous se produisent sur une connexion TCP :

  • Le DNS ne fonctionne pas.
  • les câbles sont débranchés ;
  • Microsoft Windows comprend un pare-feu qui bloque un port spécifique ;
  • l'application de surveillance d'un port ne fonctionne pas ;
  • un serveur Windows a été renommé ;
  • un serveur Windows a été redémarré.

Notes

Les groupes de disponibilité AlwaysOn ne protègent pas des problèmes liés à l’accès aux serveurs par le client. Prenons l'exemple d'un cas dans lequel une carte réseau publique gère des connexions clientes au réplica principal, tandis qu'une carte d'interface réseau privée gère le trafic entre les instances de serveur qui hébergent les réplicas d'un groupe de disponibilité. Dans ce cas, l'échec de la carte réseau publique empêcherait les clients d'accéder aux bases de données.

Défaillances dues à des erreurs logicielles

Parmi les conditions susceptibles de provoquer des délais d’expiration de session figurent notamment, sans s’y limiter, les situations suivantes :

  • des erreurs réseau, par exemple, un dépassement de délai de la liaison TCP, des paquets supprimés ou endommagés, des paquets dans le désordre ;

  • Un système d’exploitation, un serveur ou une base de données qui ne répond pas.

  • un serveur Windows en cours de dépassement d'un délai d'expiration ;

  • des ressources informatiques insuffisantes, telles qu'une surcharge de l'unité centrale ou du disque, la taille limite atteinte par le journal de transactions ou l'absence de mémoire ou de threads disponibles. Dans de telles situations, vous devez augmenter le délai d'attente, réduire la charge de travail ou remplacer les matériels pour qu'ils supportent la charge de travail.

Mécanisme du délai d’expiration de session

Étant donné que les erreurs logicielles ne sont pas détectables directement par une instance de serveur, lorsqu’elles surviennent, un réplica de disponibilité peut attendre indéfiniment une réponse de l’autre réplica de disponibilité dans une session. Pour éviter cela, Groupes de disponibilité Always On implémente son propre mécanisme de délai d'expiration de session, selon lequel les réplicas de disponibilités connectés envoient une commande ping sur chaque connexion ouverte à un intervalle fixe. La réception d'un ping au cours du délai d'attente indique que la connexion est toujours ouverte et que les instances de serveur communiquent via celle-ci. À la réception du ping, un réplica réinitialise son compteur de délai d'expiration sur cette connexion. Pour plus d’informations sur la relation entre le mode de disponibilité et les délais d’expiration de session, consultez Modes de disponibilité (Groupes de disponibilité Always On).

Les réplicas primaire et secondaire s'envoient réciproquement une commande ping pour signaler qu'ils sont toujours actifs, et la limite définie par le délai d'expiration de session empêche que l'un ou l'autre réplica attende indéfiniment de recevoir une commande ping de l'autre réplica. La limite définie par le délai d'expiration de session est une propriété de réplica configurable par l'utilisateur dont la valeur par défaut est de 10 secondes. La réception d'un ping au cours du délai d'attente indique que la connexion est toujours ouverte et que les instances de serveur communiquent via celle-ci. À la réception d'un ping, un réplica de disponibilité réinitialise son compteur de délai d'expiration de session sur cette connexion.

Si aucun ping n’est reçu de l’autre réplica au cours de la période d’expiration de session, le réplica expire. La connexion est fermée et le réplica expiré passe à l’état DÉCONNECTÉ. Même si un réplica déconnecté est configuré pour le mode de validation synchrone, les transactions n’attendront pas que ce réplica se reconnecte et se resynchronise.

Réponse à une erreur

Quel que soit le type d'erreur, une instance de serveur qui détecte une erreur réagit comme il se doit en fonction du rôle de l'instance, du mode de disponibilité de la session et de l'état des autres connexions de la session. Pour plus d’informations sur ce qui se passe en cas de perte d’un serveur partenaire, consultez Modes de disponibilité (Groupes de disponibilité Always On).

Voir aussi

Étapes suivantes