Haute disponibilité et récupération d’urgence sur Linux et macOS

  • Article

Télécharger le pilote ODBC

Les pilotes ODBC pour Linux et macOS prennent en charge les groupes de disponibilité Always On. Pour plus d’informations sur les groupes de disponibilité Always On, consultez les pages suivantes :

Vous pouvez spécifier l’écouteur d’un groupe de disponibilité en particulier dans la chaîne de connexion. Si une application ODBC sur Linux ou macOS est connectée à une base de données située dans un groupe de disponibilité qui subit un basculement, la connexion d’origine est rompue. L’application doit ouvrir une nouvelle connexion pour continuer à fonctionner après le basculement.

Les pilotes ODBC sur Linux et macOS effectuent des itérations séquentielles sur toutes les adresses IP associées à un nom d’hôte DNS si vous ne vous connectez pas à un écouteur de groupe de disponibilité. Si la première adresse IP retournée du serveur DNS n’est pas connectable, ces itérations peuvent prendre du temps.

Quand vous vous connectez à un écouteur de groupe de disponibilité, le pilote tente d’établir des connexions avec toutes les adresses IP en parallèle. Si une tentative de connexion réussit, le pilote ignore toutes les tentatives de connexion en attente.

Notes

En raison du risque d’échec de connexion en cas de basculement d’un groupe de disponibilité, implémentez une logique de déclenchement de nouvelles tentatives de connexion. Multipliez les tentatives jusqu’à ce qu’une connexion soit établie. L’augmentation du délai de connexion et l’implémentation d’une logique de déclenchement de nouvelles tentatives de connexion permettent d’augmenter la probabilité de connexion à un groupe de disponibilité.

Connexion avec MultiSubnetFailover

Spécifiez toujours MultiSubnetFailover=Yes lorsque vous vous connectez à un écouteur de groupe de disponibilité SQL Server 2012 (11.x) ou à une instance de cluster de basculement SQL Server 2012 (11.x). MultiSubnetFailover permet une bascule plus rapide pour tous les groupes de disponibilité et toutes les instances de cluster de basculement de SQL Server 2012 (11.x).

Cette propriété de connexion réduit aussi sensiblement le temps de basculement pour les topologies Always On à un seul ou plusieurs sous-réseaux. Pendant un basculement à plusieurs sous-réseaux, le client tente d’établir des connexions en parallèle. Pendant un basculement de sous-réseau, le pilote retente agressivement la connexion TCP.

La propriété de connexion MultiSubnetFailover indique que l’application est déployée dans un groupe de disponibilité ou une instance de cluster de basculement. Le pilote 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 vous vous connectez avec MultiSubnetFailover=Yes, le client retente d’établir une connexion TCP plus rapidement que les intervalles de retransmission TCP par défaut du système d’exploitation. MultiSubnetFailover=Yes permet d’accélérer la reconnexion après le basculement d’un groupe de disponibilité Always On ou d’une instance de cluster de basculement Always On. Cette valeur s’applique à la fois aux groupes de disponibilité et aux instances de cluster de basculement à un seul ou plusieurs sous-réseaux.

Utilisez MultiSubnetFailover=Yes lorsque vous vous connectez à un écouteur de groupe de disponibilité ou à une instance de cluster de basculement. Sinon, les performances de votre application peuvent être impactées négativement.

Recommandations

Quand vous vous connectez à un serveur dans un groupe de disponibilité ou une instance de cluster de basculement, suivez les recommandations ci-dessous :

  • Spécifiez MultiSubnetFailover=Yes pour améliorer le niveau de performance quand vous vous connectez à un groupe de disponibilité à un seul ou plusieurs sous-réseaux.

  • Spécifiez l’écouteur de groupe de disponibilité en tant que serveur dans votre chaîne de connexion.

  • Vous ne pouvez pas vous connecter à une instance SQL Server configurée avec plus de 64 adresses IP.

  • L’authentification SQL Server et l’authentification Kerberos peuvent être utilisées avec MultiSubnetFailover=Yes sans incidence sur le comportement de l’application.

  • Vous pouvez augmenter la valeur de loginTimeout pour tenir compte du temps de basculement et réduire le nombre de nouvelles tentatives de connexion de l’application.

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

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

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

  • Si l’application utilise ApplicationIntent=ReadWrite et que l’emplacement du réplica secondaire est configuré pour un accès en lecture seule.

La connexion échoue si le réplica principal est configuré pour rejeter les charges de travail en lecture seule et que la chaîne de connexion contient ApplicationIntent=ReadOnly.

Spécification de l’intention d’application

Vous pouvez spécifier le mot clé ApplicationIntent dans votre chaîne de connexion. Les valeurs assignables sont ReadWrite (par défaut) ou ReadOnly.

Lorsque vous définissez ApplicationIntent=ReadOnly, le client demande une charge de travail de lecture lors de la connexion. Le serveur applique l’intention au moment de la connexion et pendant une instruction de base de données USE.

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

Cibles de ReadOnly

Lorsqu’une connexion choisit ReadOnly, elle est affectée à l’une des configurations spéciales suivantes qui peuvent exister pour la base de données :

  • Always On. Une base de données peut autoriser ou interdire les charges de travail en lecture sur la base de données ciblée du groupe de disponibilité. Ce choix est contrôlé à l’aide de la clause ALLOW_CONNECTIONS des instructions Transact-SQL PRIMARY_ROLE et SECONDARY_ROLE.

  • Géoréplication

  • Lecture du scale-out

Si aucune cible spéciale n’est disponible, la base de données normale est utilisée pour la lecture.

Le mot clé ApplicationIntent active le routage en lecture seule.

Routage en lecture seule

Le routage en lecture seule est une fonctionnalité qui permet de garantir la disponibilité d'un réplica de base de données en lecture seule. Pour activer le routage en lecture seule, tous les éléments suivants s’appliquent :

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

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

  • L’administrateur de base de données doit configurer le groupe de disponibilité pour activer le routage en lecture seule.

Plusieurs connexions utilisant le routage en lecture seule ne sont pas nécessairement toutes établies avec le 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.

Vous pouvez vérifier que toutes les demandes en lecture seule se connectent au même réplica en lecture seule. Pour cela, ne transmettez pas d’écouteur de 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 est susceptible de prendre plus de temps que la connexion à l’instance principale. En effet, il se connecte d’abord à l’instance principale, puis recherche le meilleur secondaire accessible en lecture disponible. En raison de ces multiples étapes, passez à un délai d’expiration login d’au moins 30 secondes.

Syntaxe ODBC

Deux mots clés de chaîne de connexion ODBC prennent en charge les groupes de disponibilité Always On :

  • ApplicationIntent

  • MultiSubnetFailover

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

Les attributs de connexion équivalents sont :

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Pour plus d’informations sur les attributs de connexion ODBC, consultez SQLSetConnectAttr.

Une application ODBC qui utilise des groupes de disponibilité Always On peut avoir recours à deux fonctions pour établir la connexion :

Fonction Description
SQLConnect, fonction SQLConnect prend en charge ApplicationIntent et MultiSubnetFailover au moyen d’un nom de source de données (DSN, Data Source Name) ou d’un attribut de connexion.
SQLDriverConnect, fonction SQLDriverConnect prend en charge ApplicationIntent et MultiSubnetFailover au moyen d’un DSN, d’un mot clé de chaîne de connexion ou d’un attribut de connexion.

Voir aussi

Mots clés de chaîne de connexion et noms de source de données

Instructions de programmation

Notes de publication