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

  • Article

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).

À compter de la version 4.0 du Pilote Microsoft JDBC pour SQL Server, il est possible de spécifier l’écouteur du groupe de disponibilité (haute disponibilité et reprise d’activité) depuis la propriété de connexion. Si une application Pilote Microsoft JDBC pour SQL Server est connectée à une base de données du groupe de disponibilité Always On sur laquelle un basculement est effectué, la connexion d’origine sera interrompue. L’application devra alors établir une nouvelle connexion pour poursuivre la tâche 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

Spécifiez multiSubnetFailover=true lors de la connexion à l’écouteur de groupe de disponibilité d’un groupe de disponibilité ou d’une instance de cluster de basculement.

Notes

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

À 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 transparentNetworkIPResolution= a la valeur true, la première tentative de connexion utilise une valeur de délai d’expiration de 500 ms. Les autres tentatives de connexion suivent la même logique qu’avec la fonctionnalité multiSubnetFailover.

Notes

Si vous utilisez la version 4.2 ou une version antérieure de Microsoft JDBC Driver pour SQL Server et que multiSubnetFailover a la valeur false, 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.

Notes

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 toujours multiSubnetFailover=true lors de la connexion à l’écouteur de groupe de disponibilité d’un groupe de disponibilité SQL Server 2012 (11.x) ou d’une instance de cluster de basculement SQL Server 2012 (11.x). multiSubnetFailover permet un basculement plus rapide pour tous les groupes de disponibilité et les instances de cluster de basculement dans SQL Server 2012 (11.x), et réduit considérablement le temps de basculement pour les topologies AlwaysOn uniques et de plusieurs 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, Pilote Microsoft JDBC pour SQL Server tentera intensément d’établir la connexion TCP.

La propriété de connexion multiSubnetFailover indique que l’application est déployée sur un groupe de disponibilité ou une instance de cluster de basculement, et que Pilote Microsoft JDBC pour SQL Server tente de se connecter à la base de données sur l’instance SQL Server principale en essayant toutes les adresses IP. Quand MultiSubnetFailover=true 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. Ce comportement 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 aux groupes de disponibilité et aux instances de cluster de basculement à un seul et à plusieurs sous-réseaux.

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

La spécification de multiSubnetFailover=true quand la connexion ne concerne pas un écouteur de groupe de disponibilité ni une instance de cluster de basculement peut avoir un impact négatif sur les performances et n’est pas prise en charge.

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é JDK est installé, la machine virtuelle Java met en cache les adresses IP virtuelles et n’actualise pas le cache par défaut. Vous devez définir la durée de vie (TTL, time-to-live – networkaddress.cache.ttl) sur un jour pour le cache de la machine virtuelle Java. Si vous ne modifiez pas la valeur par défaut en attribuant une valeur égale à un jour (environ), l’ancienne valeur n’est pas supprimée définitivement 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 https://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html.

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

  • Le pilote génèrera une erreur si la propriété de connexion instanceName est utilisée dans la même chaîne de connexion que la propriété de connexion multiSubnetFailover. Cette erreur révèle que SQL Browser n’est pas utilisé dans un groupe de disponibilité. Toutefois, si la propriété de connexion portNumber est également spécifiée, le pilote ignorera instanceName et utilisera portNumber.

  • Utilisez la propriété de connexionmultiSubnetFailover quand vous vous connectez à un seul sous-réseau ou à des sous-réseaux multiples pour améliorer leurs performances.

  • 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.

  • 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 peut ne pas être affecté en fonction du type d’authentification : authentification SQL Server, authentification Kerberos ou authentification Windows.

  • Augmentez la valeur de loginTimeout pour tenir compte du temps de basculement et réduire les nouvelles tentatives de connexion de l’application.

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(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

Si vous mettez à niveau une application Pilote Microsoft JDBC pour SQL Server qui utilise actuellement la mise en miroir de bases de données pour un scénario de sous-réseaux multiples, vous devez supprimer la propriété de connexion failoverPartner et la remplacer par multiSubnetFailover définie sur true et remplacer le nom du serveur dans la chaîne de connexion par un écouteur du 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 retournera une erreur si la mise en miroir de bases de données est utilisée sur la base de données principale au sein du groupe de disponibilité, et si multiSubnetFailover=true est utilisé dans la chaîne de connexion qui établit une connexion à une base de données principale au lieu d’un écouteur de 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 :

  • 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.

Regroupement de connexions

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

  • Si le routage en lecture seule est configuré ainsi qu’un pool de serveurs en lecture seule que vous souhaitez distribuer en charge, le regroupement de connexions réduit le nombre d’opportunités de nouvelles connexions à répartir sur 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.

Voir aussi

Connexion à SQL Server avec le pilote JDBC
Définition des propriétés de connexion