Partager via

Prise en charge de SQL Server Native Client pour la haute disponibilité et la reprise après sinistre

Cette rubrique décrit la prise en charge de SQL Server Native Client (ajoutée dans SQL Server 2012) pour les groupes de disponibilité Always On. Pour plus d’informations sur les groupes de disponibilité Always On, consultez les écouteurs de groupe de disponibilité, la connectivité du client et le basculement d’application (SQL Server),la création et la configuration des groupes de disponibilité (SQL Server), le clustering de basculement et les groupes de disponibilité AlwaysOn (SQL Server) et les secondaires actifs : réplicas secondaires lisibles (groupes de disponibilité AlwaysOn).

Vous pouvez spécifier l’écouteur de groupe de disponibilité d’un groupe de disponibilité donné dans la chaîne de connexion. Si une application SQL Server Native Client est connectée à une base de données dans un groupe de disponibilité qui bascule, la connexion d’origine est interrompue et l’application doit ouvrir une nouvelle connexion pour continuer à fonctionner après le basculement.

Si vous ne vous connectez pas à un écouteur de groupe de disponibilité et si plusieurs adresses IP sont associées à un nom d’hôte, SQL Server Native Client effectue une itération séquentielle via toutes les adresses IP associées à l’entrée DNS. Cette opération peut prendre du temps si la première adresse IP retournée par le serveur DNS n'est liée à aucune carte d'interface réseau (NIC). Lors de la connexion à un écouteur de groupe de disponibilité, SQL Server Native Client tente d’établir des connexions à toutes les adresses IP en parallèle et, si une tentative de connexion réussit, le pilote ignore toutes les tentatives de connexion en attente.

Remarque

L'augmentation du délai de connexion et l'implémentation de la logique de tentative de connexion augmente la probabilité qu'une application se connecte à un groupe de disponibilité. En raison du risque d'échec de connexion en cas de basculement d'un groupe de disponibilité, il est également nécessaire d'implémenter la logique de déclenchement de nouvelles tentatives de connexion, afin de multiplier les tentatives jusqu'à ce qu'une connexion soit établie.

Connexion à MultiSubnetFailover

Spécifiez toujours MultiSubnetFailover=Yes lors de la connexion à un écouteur du groupe de disponibilité SQL Server 2012 ou à une instance de cluster de basculement SQL Server 2012. MultiSubnetFailover permet un basculement plus rapide pour tous les groupes de disponibilité et l’instance de cluster de basculement dans SQL Server 2012 et réduit considérablement le temps de basculement pour les topologies AlwaysOn uniques et multi-sous-réseaux. Lors d'un basculement de sous-réseaux multiples, le client tente les connexions en parallèle. Lors d’un basculement de sous-réseau, SQL Server Native Client retentera de manière agressive la connexion TCP.

La MultiSubnetFailover propriété de connexion indique que l’application est déployée dans un groupe de disponibilité ou une instance de cluster de basculement, et que SQL Server Native Client tente de se connecter à la base de données sur l’instance SQL Server principale en essayant de se connecter à toutes les adresses IP. Quand MultiSubnetFailover=Yes est spécifié dans le cadre d’une connexion, le client retente d’établir une connexion TCP plus rapidement que les intervalles de retransmission TCP par défaut du système d’exploitation. Cela permet une reconnexion plus rapide après le basculement d’un groupe de disponibilité AlwaysOn ou d’une instance de cluster de basculement AlwaysOn, et s’applique à la fois aux groupes de disponibilité à plusieurs sous-réseaux et aux instances de cluster de basculement.

Pour plus d’informations sur les mots clés de chaîne de connexion, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.

La spécification lors de MultiSubnetFailover=Yes la connexion à un autre élément qu’un écouteur de groupe de disponibilité ou une instance de cluster de basculement peut entraîner un impact négatif sur les performances et n’est pas prise en charge.

Utilisez les instructions suivantes pour la connexion à un serveur dans un groupe de disponibilité ou dans une instance de cluster de basculement :

  • Utilisez la propriété de connexion MultiSubnetFailover lors de la connexion à un seul réseau ou à plusieurs réseau car elle optimise les performances dans les deux cas de figure.

  • Pour vous connecter à un groupe de disponibilité, spécifiez l'écouteur du groupe de disponibilité en tant que serveur dans votre chaîne de connexion.

  • La connexion à une instance SQL Server configurée avec plus de 64 adresses IP provoque un échec de connexion.

  • Le comportement d’une application qui utilise la propriété de connexion MultiSubnetFailover n’est pas affecté en fonction du type d’authentification : authentification SQL Server, authentification Kerberos ou authentification Windows.

  • Vous pouvez augmenter la valeur à prendre en charge pour le temps de loginTimeout basculement et réduire les tentatives de nouvelle tentative de connexion d’application.

  • Les transactions distribuées ne sont pas prises en charge.

Si le routage en lecture seule n’est pas en vigueur, la connexion à un emplacement de réplica secondaire dans un groupe de disponibilité échoue dans les situations suivantes :

  1. Si l'emplacement du réplica secondaire n'est pas configuré pour accepter des connexions.

  2. Si une application utilise ApplicationIntent=ReadWrite (voir ci-dessous) et si l'emplacement de réplica secondaire est configuré pour un accès en lecture seule.

Une connexion échoue si un réplica principal est configuré pour rejeter des charges de travail en lecture seule et si la chaîne de connexion contient ApplicationIntent=ReadOnly.

Mise à niveau pour utiliser des clusters de sous-réseaux multiples à partir de la mise en miroir de bases de données

Une erreur de connexion se produit si les MultiSubnetFailover mots clés de Failover_Partner connexion sont présents dans la chaîne de connexion. Une erreur se produit également si MultiSubnetFailover elle est utilisée et que SQL Server retourne une réponse partenaire de basculement indiquant qu’elle fait partie d’une paire de mise en miroir de bases de données.

Si vous mettez à niveau une application SQL Server Native Client qui utilise actuellement la mise en miroir de bases de données vers un scénario multi-sous-réseau, vous devez supprimer la Failover_Partner propriété de connexion et la remplacer par MultiSubnetFailover définie sur Yes et remplacer le nom du serveur dans la chaîne de connexion par un écouteur de groupe de disponibilité. Si une chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=Yes, le pilote génère une erreur. Toutefois, si une chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=No (ou ApplicationIntent=ReadWrite), l'application utilise la mise en miroir de bases de données.

Le pilote retourne une erreur si la mise en miroir de bases de données est utilisée sur la base de données primaire dans le groupe de disponibilité et si MultiSubnetFailover=Yes elle est utilisée dans la chaîne de connexion qui se connecte à une base de données primaire au lieu d’un écouteur de groupe de disponibilité.

Spécification de l’intention de l’application

Quand ApplicationIntent=ReadOnly, le client demande une charge de travail de lecture lors de la connexion à une base de données activée par AlwaysOn. Le serveur applique l'intention au moment de la connexion et pendant une instruction de base de données USE mais uniquement sur une base de données prenant en charge AlwaysOn.

Le mot clé ApplicationIntent ne fonctionne pas avec les bases de données en lecture seule existantes.

Une base de données peut autoriser ou interdire les charges de travail de lecture sur la base de données AlwaysOn ciblée. (Pour cela, utilisez la clause ALLOW_CONNECTIONS des instructions SQL-Transact PRIMARY_ROLE et SECONDARY_ROLE.)

Le mot clé ApplicationIntent est utilisé pour activer le routage en lecture seule.

Routage en lecture seule

Le routage en lecture seule est une fonctionnalité qui peut garantir la disponibilité d'un réplica en lecture seule d'une base de données. Pour activer le routage en lecture seule :

  1. Vous devez vous connecter à un écouteur du groupe de disponibilité Always On.

  2. Le mot clé de chaîne de connexion ApplicationIntent doit avoir la valeur ReadOnly.

  3. Le groupe de disponibilité doit être configuré par l'administrateur de base de données pour activer le routage en lecture seule.

Il est possible que plusieurs connexions utilisant le routage en lecture seule ne se connectent pas toutes au même réplica en lecture seule. Les modifications apportées à la synchronisation de base de données ou à la configuration du routage du serveur peuvent entraîner des connexions clientes à différents réplicas en lecture seule. Pour vérifier que toutes les demandes en lecture seule se connectent au même réplica en lecture seule, ne transmettez pas d'écouteur du groupe de disponibilité au mot clé de chaîne de connexion Server. Au lieu de cela, spécifiez le nom de l'instance en lecture seule.

Le routage en lecture seule peut prendre plus de temps que la connexion au réplica primaire car le routage en lecture seule se connecte d'abord au réplica primaire, puis recherche le meilleur réplica secondaire lisible disponible. Pour cette raison, vous devez augmenter le délai de connexion.

ODBC

Deux mots clés de chaîne de connexion ODBC ont été ajoutés pour prendre en charge les groupes de disponibilité Always On dans SQL Server Native Client :

  • ApplicationIntent

  • MultiSubnetFailover

Pour plus d’informations sur les mots clés de chaîne de connexion ODBC dans SQL Server Native Client, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.

Les propriétés de connexion équivalentes sont les suivantes :

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Pour plus d’informations sur les propriétés de connexion ODBC dans SQL Server Native Client, consultez SQLSetConnectAttr.

Les fonctionnalités des mots clés et MultiSubnetFailover des ApplicationIntent mots clés sont exposées dans l’administrateur de source de données ODBC pour les DSN qui utilisent le pilote SQL Server Native Client, à compter de SQL Server 2012.

Une application ODBC SQL Server Native Client peut utiliser l’une des trois fonctions pour établir la connexion :

Fonction Descriptif
SQLBrowseConnect La liste des serveurs retournés par SQLBrowseConnect n’inclut pas de réseaux virtuels. Vous verrez uniquement une liste de serveurs sans indication si le serveur est un serveur autonome, ou un serveur principal ou secondaire dans un cluster WSFC (Clustering de basculement Windows Server) qui contient deux instances SQL Server ou plus activées pour les groupes de disponibilité Always On. Si vous vous connectez à un serveur et recevez un échec, cela peut être dû au fait que vous êtes connecté à un serveur et que le ApplicationIntent paramètre n’est pas compatible avec la configuration du serveur.

Étant donné que SQLBrowseConnect ne reconnaît pas les serveurs dans un cluster WSFC (Clustering de basculement Windows Server) qui contient deux instances SQL Server ou plus activées pour les groupes de disponibilité Always On, SQLBrowseConnect ignore le MultiSubnetFailover mot clé de chaîne de connexion.
SQLConnect SQLConnect prend en charge les deux ApplicationIntent et MultiSubnetFailover via un nom de source de données (DSN) ou des propriétés de connexion.
SQLDriverConnect SQLDriverConnect prend en charge ApplicationIntent et MultiSubnetFailover via des mots clés de chaîne de connexion, des propriétés de connexion ou DSN.

OLE DB

OLE DB dans SQL Server Native Client ne prend pas en charge le MultiSubnetFailover mot clé.

OLE DB dans SQL Server Native Client prend en charge l’intention de l’application. L’intention de l’application se comporte de la même façon pour les applications OLE DB que les applications ODBC (voir ci-dessus).

Un mot clé de chaîne de connexion OLE DB ajouté pour prendre en charge les groupes de disponibilité Always On dans SQL Server Native Client :

  • Application Intent

Pour plus d’informations sur les mots clés de chaîne de connexion dans SQL Server Native Client, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.

Les propriétés de connexion équivalentes sont les suivantes :

  • SSPROP_INIT_APPLICATIONINTENT

  • DBPROP_INIT_PROVIDERSTRING

Une application OLE DB SQL Server Native Client peut utiliser l’une des méthodes pour spécifier l’intention de l’application :

IDBInitialize::Initialize
IDBInitialize::Initialize utilise l’ensemble de propriétés précédemment configuré pour initialiser la source de données et créer l’objet de source de données. Spécifiez l’intention de l’application en tant que propriété de fournisseur ou dans le cadre de la chaîne de propriétés étendues.

IDataInitialize::GetDataSource
IDataInitialize::GetDataSource prend une chaîne de connexion d’entrée qui peut contenir le Application Intent mot clé.

IDBProperties::GetProperties
IDBProperties::GetProperties récupère la valeur de la propriété actuellement définie sur la source de données. Vous pouvez récupérer la Application Intent valeur via la propriété DBPROP_INIT_PROVIDERSTRING et la propriété SSPROP_INIT_APPLICATIONINTENT.

IDBProperties::SetProperties
Pour définir la valeur de la ApplicationIntent propriété, appelez IDBProperties::SetProperties le passage de la propriété avec la SSPROP_INIT_APPLICATIONINTENT valeur «ReadWrite » ou « » ou DBPROP_INIT_PROVIDERSTRING laReadOnly propriété avec la valeur contenant «ApplicationIntent=ReadOnly » ou «ApplicationIntent=ReadWrite ».

Vous pouvez spécifier l’intention de l’application dans le champ Propriétés de l’intention de l’application de l’onglet Tous dans la boîte de dialogue Propriétés de la liaison de données .

Lorsque des connexions implicites sont établies, la connexion implicite utilise le paramètre d’intention de l’application de la connexion parente. De même, plusieurs sessions créées à partir de la même source de données héritent du paramètre d’intention de l’application de la source de données.

Voir aussi

Fonctionnalités de SQL Server Native Client
Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client

  • Last updated on