Partager via

À propos de l'accès de la connexion client aux réplicas de disponibilité (SQL Server)

  • Article

Dans un groupe de disponibilité AlwaysOn, vous pouvez configurez un ou plusieurs réplicas de disponibilité pour autoriser les connexions en lecture seule lors d'une exécution sous le rôle secondaire (autrement dit, avec une exécution en tant que réplica secondaire). Vous pouvez également configurer chaque réplica de disponibilité afin d'autoriser ou exclure les connexions en lecture seule lors d'une exécution sous le rôle principal (autrement dit, avec une exécution comme réplica principal).

Pour faciliter l'accès client aux bases de données primaires ou secondaires d'un groupe de disponibilité donné, vous devez définir un écouteur de groupe de disponibilité. Par défaut, l'écouteur de groupe de disponibilité dirige les connexions entrantes vers le réplica principal. Toutefois, vous pouvez configurer un groupe de disponibilité pour prendre en charge le routage en lecture seule, qui permet à son écouteur de groupe de disponibilité de rediriger les demandes de connexion des applications avec intention de lecture vers un réplica secondaire accessible en lecture. Pour plus d’informations, consultez Configurer le routage en lecture seule pour un groupe de disponibilité (SQL Server).

Lors d'un basculement, un réplica secondaire adopte le rôle principal et l'ancien réplica principal joue le rôle secondaire. Pendant le processus de basculement, toutes les connexions clientes au réplica principal et aux réplicas secondaires prennent fin. Après le basculement, lorsqu'un client se reconnecte à l'écouteur de groupe de disponibilité, l'écouteur reconnecte le client au nouveau réplica principal, sauf dans le cas d'une demande de connexion avec intention de lecture. Si le routage en lecture seule est configuré sur le client et sur les instances de serveur qui hébergent le nouveau réplica principal et sur au moins un réplica secondaire accessible en lecture, les demandes de connexion avec intention de lecture sont à nouveau routées vers un réplica secondaire qui prend en charge le type d'accès à la connexion dont le client a besoin. Pour garantir une expérience naturelle pour le client après un basculement, il est important de configurer l'accès à la connexion pour les rôles secondaires et principaux de chaque réplica de disponibilité.

Notes

Pour plus d’informations sur l’écouteur de groupe de disponibilité, qui traite les demandes de connexion des clients, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server).

Dans cette rubrique :

Types d'accès à la connexion pris en charge par le rôle secondaire

Le rôle secondaire prend en charge trois méthodes pour les connexions clientes, comme suit :

Aucune connexion
Aucune connexion utilisateur n'est autorisée. Les bases de données secondaires ne sont pas disponibles pour l'accès en lecture. Il s'agit du comportement par défaut dans le rôle secondaire.

Connexions d'intention en lecture seule
La ou les bases de données secondaires sont disponibles uniquement pour la connexion pour laquelle la Application Intent propriété de connexion est définie sur ReadOnly (connexions d’intention de lecture).

Pour plus d'informations sur cette propriété de connexion, consultez Prise en charge des fonctionnalités de récupération d'urgence, haute disponibilité par SQL Server Native Client.

autoriser toutes les connexions en lecture seule.
La ou les bases de données secondaires sont toutes disponibles pour les connexions d'accès en lecture. Cette option permet aux clients disposant d'une version antérieure de se connecter.

Pour plus d’informations, consultez Configurer l’accès en lecture seule sur un réplica de disponibilité (SQL Server).

Types d'accès à la connexion pris en charge par le rôle principal

Le rôle principal prend en charge deux méthodes pour les connexions clientes, comme suit :

Toutes les connexions sont autorisées
Les connexions en lecture-écriture et en lecture seule sont autorisées aux bases de données primaires. Il s'agit du comportement par défaut pour le rôle principal.

Autoriser uniquement les connexions en lecture-écriture
Lorsque la Application Intent propriété de connexion a la valeur ReadWrite ou n’est pas définie, la connexion est autorisée. Les connexions pour lesquelles la Application Intent chaîne de connexion mot clé est définie sur ReadOnly ne sont pas autorisées. L'autorisation des seules connexions en lecture-écriture peut empêcher vos clients de connecter une charge de travail avec intention de lecture au réplica principal, par erreur.

Pour plus d'informations sur cette propriété de connexion, consultez Using Connection String Keywords with SQL Server Native Client.

Pour plus d’informations, consultez Configurer l’accès en lecture seule sur un réplica de disponibilité (SQL Server).

Comment la configuration d'accès à la connexion affecte la connectivité client

Les paramètres d'accès à la connexion d'un réplica déterminent si une tentative de connexion échoue ou réussit. Le tableau suivant récapitule si une tentative de connexion donnée réussit ou échoue pour chaque paramètre d'accès à la connexion.

Rôle du réplica Accès à la connexion pris en charge sur le réplica Intention de connexion Résultat de la tentative de connexion
Secondary Tous Intention de lecture, lecture-écriture, ou aucune intention de connexion spécifiée Succès
Secondary Aucun (il s'agit du comportement secondaire par défaut.) Intention de lecture, lecture-écriture, ou aucune intention de connexion spécifiée Échec
Secondary Intention de lecture uniquement Intention de lecture Succès
Secondary Intention de lecture uniquement Lecture-écriture ou aucune intention de connexion spécifiée Échec
Principal Tous (il s'agit du comportement principal par défaut.) Lecture seule, lecture-écriture ou aucune intention de connexion spécifiée Succès
Principal Lecture-écriture Intention de lecture uniquement Échec
Principal Lecture-écriture Lecture-écriture ou aucune intention de connexion spécifiée Succès

Pour plus d’informations sur la configuration d’un groupe de disponibilité pour accepter les connexions des clients à ses réplicas, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server).

Exemple de configuration d'accès à la connexion

Selon la façon dont différents réplicas de disponibilité sont configurés pour l'accès à la connexion, la prise en charge des connexions clientes peut changer après le basculement d'un groupe de disponibilité. Par exemple, considérez un groupe de disponibilité pour lequel la création de rapports est exécutée sur des réplicas secondaires distants avec validation asynchrone. Toutes les applications en lecture seule des bases de données dans ce groupe de disponibilité définissent leur propriété de connexion Application Intent avec la valeur ReadOnly, de sorte que toutes les connexions en lecture seule soient des connexions avec intention de lecture.

Cet exemple de groupe de disponibilité compte deux réplicas de validation synchrone au centre de calcul principal et deux réplicas de validation asynchrone sur un site satellite. Pour le rôle principal, tous les réplicas sont configurés pour l'accès en lecture-écriture, ce qui empêche les connexions avec intention de lecture au réplica principal dans tous les cas. Le rôle secondaire avec validation synchrone utilise la configuration par défaut d'accès à la connexion (« aucun »), ce qui empêche toute connexion cliente sous le rôle secondaire. Par opposition, les réplicas avec validation asynchrone sont configurés pour autoriser les connexions avec intention de lecture sous le rôle secondaire. Le tableau suivant récapitule cette configuration d'exemple :

Réplica Mode de validation Rôle initial Accès à la connexion pour le rôle secondaire Accès à la connexion pour le rôle principal
Replica1 Synchrone Principal None Lecture-écriture
Replica2 Synchrone Secondary None Lecture-écriture
Replica3 Asynchrone Secondary Intention de lecture uniquement Lecture-écriture
Replica4 Asynchrone Secondary Intention de lecture uniquement Lecture-écriture

En général, dans cet exemple de scénario, les basculements se produisent uniquement entre les réplicas avec validation synchrone et immédiatement après le basculement, les applications avec intention de lecture peuvent se reconnecter à l’un des réplicas secondaires avec validation asynchrone. Toutefois, lorsqu'un incident se produit au centre de calcul principal, les deux réplicas avec validation synchrone sont perdus. L'administrateur de base de données sur le site satellite répond en effectuant un basculement manuel forcé vers un réplica secondaire avec validation asynchrone. Les bases de données secondaires sur le réplica secondaire restant sont interrompues par le basculement forcé, ce qui les rend indisponibles pour les charges de travail en lecture seule. Le nouveau réplica principal, qui est configuré pour les connexions en lecture-écriture, empêche la charge de travail avec intention de lecture de concurrencer la charge de travail en lecture-écriture. Cela signifie que tant que l'administrateur de base de données n'a pas repris les bases de données secondaires sur le réplica secondaire restant avec validation asynchrone, les clients avec intention de lecture ne peuvent se connecter à aucun réplica de disponibilité.

Tâches associées

Contenu associé

Voir aussi

Vue d'ensemble des groupes de disponibilité AlwaysOn (SQL Server)
Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server)
Statistiques