Prise en charge de la haute disponibilité et de la récupération d'urgence par le pilote JDBC

Télécharger le pilote JDBC

Cet article traite de la prise en charge par le pilote Microsoft JDBC Driver pour SQL Server de la haute disponibilité et de la récupération d’urgence : les groupes de disponibilité Always On. Pour plus d’informations sur Groupes de disponibilité Always On, consultez la documentation en ligne de SQL Server 2012 (11.x).

À partir de la version 4.0 de Microsoft JDBC Driver for SQL Server, vous pouvez spécifier dans la propriété de connexion l’écouteur d’un groupe de disponibilité haute disponibilité/reprise d’activité (AG). Si une application qui utilise le pilote Microsoft JDBC pour SQL Server est connectée à une base de données Always On qui fait l’objet d’un basculement, la connexion d’origine est interrompue et l’application doit ouvrir une nouvelle connexion pour poursuivre son travail après le basculement. Les propriétés de connexion suivantes ont été ajoutées dans Microsoft JDBC Driver 4.0 pour SQL Server :

  • multiSubnetFailover

  • applicationIntent

Définissez multiSubnetFailover=true lorsque la cible est Azure SQL Database, Azure SQL Managed Instance, une base de données SQL dans Microsoft Fabric, un écouteur de groupe de disponibilité ou une instance de cluster de basculement.

Note

multiSubnetFailover a la valeur false par défaut. Utilisez applicationIntent pour déclarer le type de charge de travail de l’application. Pour plus d’informations, consultez les sections suivantes.

À compter de la version 6.0 de Microsoft JDBC Driver pour SQL Server, une nouvelle propriété de connexion transparentNetworkIPResolution (TNIR) est ajoutée pour la connexion transparente à des groupes de disponibilité AlwaysOn ou à un serveur auquel plusieurs adresses IP sont associées. Lorsque transparentNetworkIPResolution a la valeur true, le pilote tente de se connecter à la première adresse IP disponible. Si la première tentative échoue, le pilote tente de se connecter à toutes les adresses IP en parallèle jusqu’à ce que le délai expire, ignorant toutes les tentatives de connexion en attente lorsque l’une d’elles réussit.

Remarque :

  • transparentNetworkIPResolution a la valeur true par défaut.
  • transparentNetworkIPResolution est ignoré si multiSubnetFailover a la valeur true.
  • transparentNetworkIPResolution est ignoré si la mise en miroir de bases de données est utilisée.
  • transparentNetworkIPResolution est ignoré s’il y a plus de 64 adresses IP.
  • Lorsque la solution transparentNetworkIP est vraie, la première tentative de connexion utilise une valeur d’attente de 500 millisecondes. Le reste des tentatives de connexion suit la même logique que la fonction multiSubnetFailover.

Note

Si vous utilisez le pilote Microsoft JDBC pour SQL Server version 4.2 (ou antérieure) et que multiSubnetFailover est défini sur false, le pilote Microsoft JDBC pour SQL Server tente de se connecter à la première adresse IP. Si le Pilote Microsoft JDBC pour SQL Server ne parvient pas à établir de connexion avec la première adresse IP, la connexion échoue. Le Pilote Microsoft JDBC pour SQL Server ne tentera pas de se connecter à l’adresse IP suivante qui est associée au serveur.

Note

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 avec multiSubnetFailover

Spécifiez systématiquement multiSubnetFailover=true lorsque la cible est Azure SQL Database, Azure SQL Managed Instance, Base de données SQL dans Microsoft Fabric, un écouteur de groupe de disponibilité d’une instance SQL Server 2012 (11.x) dans un groupe de disponibilité, ou une instance de cluster de basculement SQL Server 2012 (11.x).

Lorsque le nom du serveur dans votre chaîne de connexion se résout vers plus d’une adresse IP, multiSubnetFailover=true permet au pilote JDBC Microsoft pour SQL Server d’ouvrir les connexions à toutes ces adresses en même temps et d’utiliser la première qui répond. En son absence, le pilote utilise alors Transparent Network IP Resolution (TNIR), qui est activé par défaut. TNIR essaie une seule adresse avec un délai d’attente de 500 millisecondes, et n’ouvre les connexions à toutes les adresses résolues qu’à la tentative suivante. Si vous définissez aussi transparentNetworkIPResolution=false, le pilote essaie une seule adresse avec le loginTimeout complet et n’essaie jamais les autres, donc une connexion qui réussirait contre une autre adresse échoue à la place. Après qu’un basculement a déplacé la base de données vers une réplique située à une autre adresse, multiSubnetFailover=true se connecte à la nouvelle adresse dès la première tentative.

multiSubnetFailover=true modifie la rapidité avec laquelle le client trouve la réplique qui sert la base de données. Cela ne change pas le temps que le serveur met à basculer.

multiSubnetFailover=true est sûr sur des cibles IP uniques. Lorsque le DNS se résout à une seule adresse, le pilote tente une seule connexion et ne lance aucun thread de connexion parallèle, donc le réglage ne coûte rien quand il n’est pas nécessaire.

Pour plus d’informations sur les mots-clés de la chaîne de connexion dans le Pilote Microsoft JDBC pour SQL Server, consultez Définition des propriétés de connexion.

Si le gestionnaire de sécurité n’est pas installé, la machine virtuelle Java met en cache les adresses IP virtuelles pour une durée définie par défaut par votre implémentation JDK et les propriétés Java networkaddress.cache.ttl et networkaddress.cache.negative.ttl. Si le gestionnaire de sécurité du JDK est installé, la machine virtuelle Java met en cache les VIP et n’actualise pas ce cache par défaut. Vous devez définir « time-to-live » (networkaddress.cache.ttl) à un jour pour le cache de la machine virtuelle Java. Si vous ne modifiez pas la valeur par défaut pour la porter à un jour environ, l’ancienne valeur ne sera pas purgée du cache de la machine virtuelle Java lorsqu’une adresse IP virtuelle est ajoutée ou mise à jour. Pour plus d’informations sur networkaddress.cache.ttl et networkaddress.cache.negative.ttl, consultez Propriétés réseau.

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

  • Réglez la propriété de connexion multiSubnetFailover sur true.

  • 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. Par exemple, jdbc:sqlserver://VNN1.

  • Vous pouvez utiliser la propriété de connexion instanceName avec multiSubnetFailover. Le pilote interroge SQL Browser à chaque adresse résolue pour trouver le port de l’instance. Si vous spécifiez aussi portNumber, le pilote utilise portNumber et ne requête pas SQL Browser.

  • La connexion à une instance SQL Server configurée avec plus de 64 adresses IP échoue. Le pilote considère cela comme une configuration non prise en charge et ne réessaie pas la connexion.

  • Vous ne pouvez pas utiliser multiSubnetFailover avec la mise en miroir de bases de données. Le pilote renvoie une erreur lorsque la chaîne de connexion spécifie Partenaire de basculement, et aussi lorsque le serveur retourne un partenaire de basculement. Le miroir de base de données est obsolète dans toutes les versions supportées de SQL Server. Utilisez plutôt les groupes de disponibilité Always On.

  • Le comportement d’une application qui utilise la propriété de connexion multiSubnetFailover peut ne pas être affecté en fonction du type d’authentification : authentification SQL Server, authentification Kerberos ou authentification Windows.

  • Augmenter la valeur de loginTimeout pour gérer le temps de basculement et réduire les tentatives de reconnexion de l’application. Pour Azure SQL Database serverless avec la pause automatique activée, loginTimeout doit aussi être suffisamment grand pour contenir les tentatives de connexion du pilote. Pour plus d’informations, consultez Se connecter à une base de données sans serveur mise en pause automatiquement.

Si le routage en lecture seule n’est pas appliqué, la connexion à un emplacement de 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 une application utilise applicationIntent=ReadWrite (décrit plus loin dans cet article) et que l’emplacement de la réplique 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

Si vous mettez à niveau une application utilisant Microsoft JDBC Driver for SQL Server, qui utilise actuellement la mise en miroir de base de données, vers une configuration multi-sous-réseau, vous devez supprimer la propriété de connexion failoverPartner et la remplacer par multiSubnetFailover définie sur true, puis 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 failoverPartner et multiSubnetFailover=true, le pilote génère une erreur. Cependant, si une chaîne de connexion utilise failoverPartner et multiSubnetFailover=false (ou ApplicationIntent=ReadWrite), l’application utilise la mise en miroir de bases de données.

Le pilote renvoie une erreur si vous utilisez la mise en miroir de bases de données sur la réplique primaire dans l’AG, et si vous utilisez multiSubnetFailover=true dans la chaîne de connexion utilisée pour se connecter à une réplique primaire au lieu de l’écouteur du groupe de disponibilité.

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 :

  • Toujours allumé. 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 horizontale en lecture

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 la base de données ou à la configuration du routage du serveur peuvent amener les clients à se connecter à différentes répliques 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. C’est parce que le routage en lecture seule se connecte d’abord au serveur principal, puis recherche le meilleur serveur secondaire disponible accessible en lecture. En raison de ces multiples étapes, passez à un délai d’expiration login d’au moins 30 secondes.

Regroupement de connexions

Lorsque vous utilisez le Microsoft JDBC Driver for SQL Server avec une bibliothèque de regroupement de connexions, vous devez prendre en compte les points suivants :

  • Si le routage en lecture seule est configuré et que vous disposez d’un pool de serveurs en lecture seule sur lequel vous souhaitez répartir la charge, le pooling de connexions réduira les possibilités de répartir les nouvelles connexions entre les serveurs cibles.
  • Pour éviter une charge plus élevée sur un serveur unique dans un pool, choisissez des options de pool qui encouragent une répartition égale des connexions dans le pool.
  • Assurez-vous que votre pool de connexions est configuré avec une durée de vie de connexion. Dans le cas où un réplica en lecture seule n’est pas disponible lorsqu’une connexion en lecture seule est établie, la configuration doit s’assurer que la connexion est éventuellement fermée et rétablie sur un réplica en lecture seule lorsqu’un réplica redevient disponible.

Nouvelles méthodes prenant en charge multiSubnetFailover et applicationIntent

Les méthodes suivantes permettent d’accéder programmatiquement aux mots clés de chaîne de connexion multiSubnetFailover, applicationIntent et transparentNetworkIPResolution :

Les méthodes getMultiSubnetFailover, setMultiSubnetFailover, getApplicationIntent, setApplicationIntent, getTransparentNetworkIPResolution et setTransparentNetworkIPResolution sont également ajoutées à SQLServerDataSource Class, à SQLServerConnectionPoolDataSource Class et à SQLServerXADataSource Class.

Validation du certificat TLS/SSL

Un groupe de disponibilité se compose de plusieurs serveurs physiques. Microsoft JDBC Driver 4.0 pour SQL Server prend désormais en charge Autre nom du sujet dans les certificats TLS/SSL de manière à permettre l’association de plusieurs hôtes à un même certificat. Pour plus d’informations sur le protocole TLS, consultez Comprendre la prise en charge du chiffrement.

Contenu connexe

  • Last updated on