Reconnexion à une session de mise en miroir de bases de données
Si une connexion établie à une session de mise en miroir de bases de données échoue pour une raison quelconque, par exemple suite au basculement de mise en miroir de bases de données, et que l'application tente de se reconnecter au serveur initial, le fournisseur d'accès aux données peut essayer de se reconnecter à l'aide du nom du partenaire de basculement stocké dans le cache du client. La reconnexion n'est cependant pas automatique. L'application doit avoir connaissance de l'erreur. Ensuite, elle doit fermer la connexion qui a échoué et en ouvrir une nouvelle à l'aide des mêmes attributs de chaîne de connexion. À ce stade, le fournisseur d'accès aux données redirige la connexion vers le partenaire de basculement. Si l'instance de serveur identifiée par ce nom est actuellement le serveur principal, la tentative de connexion réussit en général. S'il est incertain si une transaction a été validée ou restaurée, l'application doit vérifier son état, de la même façon que lors de la reconnexion à une instance de serveur autonome.
La reconnexion s'apparente à une connexion initiale pour laquelle la chaîne de connexion a fourni un nom de partenaire de basculement. Si la première tentative de connexion échoue, les tentatives de connexion alternent entre le nom du partenaire initial et le nom du partenaire de basculement jusqu'à ce que le client se connecte au serveur principal ou que le délai d'attente du fournisseur d'accès aux données soit atteint.
[!REMARQUE]
SQL Server Native Client vérifie qu'il se connecte à une instance de serveur principal mais pas si cette instance est le serveur partenaire de l'instance de serveur spécifiée dans le nom de serveur partenaire initial de la chaîne de connexion.
Si les connexions utilisent TCP/IP et que le client utilise Windows XP ou version ultérieure, l'algorithme de nouvelle tentative de connexion détermine la durée allouée aux tentatives de connexion à chaque cycle. Pour plus d'informations, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.
Important
Si le client se retrouve déconnecté de la base de données, le fournisseur d'accès aux données n'essaie pas de se reconnecter. Le client doit faire une nouvelle demande de connexion. De plus, si une application s'arrête suite à la perte de la connexion, elle perd les noms de partenaire mis en cache. Si la perte de la connexion est due à l'indisponibilité soudaine du serveur principal, la seule solution pour l'application de se reconnecter au serveur miroir consiste à fournir le nom du partenaire de basculement dans sa chaîne de connexion.
Impact de la redirection sur une application cliente
Après un basculement, le fournisseur d'accès aux données redirige la connexion vers l'instance de serveur principal actuelle. La redirection est cependant transparente pour les clients. Pour un client, une connexion redirigée semble être une connexion à l'instance de serveur identifiée par le nom de partenaire initial. Lorsque le partenaire initial est actuellement le serveur miroir, le client peut sembler être connecté au serveur miroir et mettre à jour la base de données miroir. En réalité, le client a été redirigé vers le partenaire de basculement (qui est la base de données principale actuelle) et il met à jour la nouvelle base de données principale.
Après avoir été redirigé vers le partenaire de basculement, un client peut rencontrer des résultats inattendus lors de l'utilisation d'une instruction Transact-SQL USE pour utiliser une base de données différente. Cela peut se produire si l'instance de serveur principal actuelle (le partenaire de basculement) possède un ensemble de bases de données différent du serveur principal d'origine (le partenaire initial).
Voir aussi