Établissement de la connexion initiale à une session de mise en miroir de bases de données
Pour établir la connexion initiale avec une base de données mise en miroir, un client doit fournir une chaîne de connexion contenant au minimum le nom d'une instance de serveur. Ce nom de serveur obligatoire doit identifier l'instance du serveur principal actuel et est appelé nom du serveur partenaire initial.
Éventuellement, la chaîne de connexion peut également fournir le nom d'une autre instance de serveur, qui doit alors identifier l'instance du serveur miroir actuel, à utiliser si le serveur partenaire initial n'est pas disponible lors de la première tentative de connexion. Ce deuxième nom est appelé nom du serveur partenaire de basculement.
La chaîne de connexion doit également contenir un nom de base de données. Cette information est requise pour permettre au fournisseur d'accès aux données d'effectuer des tentatives de basculement.
À la réception d'une chaîne de connexion, le fournisseur d'accès aux données stocke le nom du serveur partenaire initial et, le cas échéant, le nom du serveur partenaire de basculement dans un cache de la mémoire volatile du client (pour le code managé, le cache se limite au domaine d'application). Une fois mis en cache, le nom du serveur partenaire initial n'est jamais mis à jour par le fournisseur d'accès aux données. Lorsque le client fournit le nom du serveur partenaire de basculement, le fournisseur d'accès aux données stocke aussi ce nom temporairement pour pouvoir se connecter s'il ne peut pas le faire en utilisant le nom du serveur partenaire initial.
Une session de mise en miroir de bases de données ne fournit aucune protection contre les problèmes d'accès au serveur qui sont spécifiques aux clients, comme lorsqu'un ordinateur client n'arrive pas à communiquer avec le réseau. Une tentative de connexion à une base de données mise en miroir peut également échouer pour diverses raisons qui n'ont aucun rapport avec le fournisseur d'accès aux données ; par exemple, une tentative de connexion peut échouer parce que l'instance du serveur principal est inactive, comme c'est le cas pendant le basculement de la base de données, ou à cause d'une erreur réseau.
Lorsque le fournisseur d'accès aux données tente de se connecter, il commence par utiliser le nom du serveur partenaire initial. En règle générale, si l'instance de serveur spécifiée est disponible et qu'il s'agit bien de l'instance du serveur principal actuel, la tentative de connexion aboutit.
Notes
Si la session de mise en miroir est suspendue, le client se connecte généralement au serveur principal et télécharge le nom du serveur partenaire. Cependant, le client ne peut pas accéder à la base de données tant que la mise en miroir n'a pas redémarré.
Si cette tentative échoue, le fournisseur d'accès aux données essaie de se connecter à l'aide du nom du serveur partenaire de basculement (s'il est disponible). Si l'un des noms de serveur partenaire identifie correctement le serveur principal actuel, le fournisseur d'accès aux données réussit généralement à ouvrir la connexion initiale. Une fois cette connexion établie, le fournisseur d'accès aux données télécharge le nom d'instance de serveur du serveur miroir actuel. Ce nom est stocké dans le cache en tant que nom du serveur partenaire de basculement et remplace, le cas échéant, le nom du serveur partenaire de basculement fourni par le client. Par la suite, le fournisseur de données .NET Framework pour SQL Server ne met pas à jour le nom du serveur partenaire de basculement. En revanche, SQL Server Native Client met le cache à jour à chaque fois qu'une connexion ou réinitialisation de connexion ultérieure retourne un nom de serveur partenaire différent.
La figure suivante représente une connexion cliente au serveur partenaire initial, Partner_A, pour une base de données en miroir appelée Db_1. Cette figure illustre le cas où le nom du serveur partenaire initial fourni par le client identifie correctement le serveur principal actuel, Partner_A. La tentative de connexion initiale aboutit et le fournisseur d'accès aux données stocke le nom du serveur miroir (actuellement Partner_B) en tant que nom du serveur partenaire de basculement dans le cache local. Pour terminer, le client se connecte à la copie principale de la base de données Db_1.
.gif "Connexion cliente si le serveur partenaire initial est le principal")
La tentative de connexion initiale peut échouer, entre autres, à cause d'une erreur réseau ou d'une instance de serveur inactive. Étant donné que le serveur partenaire initial est alors indisponible, pour que le fournisseur d'accès aux données puisse essayer de se connecter au serveur partenaire de basculement, le client doit avoir fourni le nom de ce dernier dans la chaîne de connexion.
Si ce n'est pas le cas et que le nom du serveur partenaire de basculement n'est pas disponible, la tentative de connexion initiale se poursuit jusqu'à l'expiration de la connexion réseau ou jusqu'à ce qu'une erreur soit retournée (exactement comme pour une base de données qui n'est pas mise en miroir).
Lorsque le nom du serveur partenaire de basculement est fourni dans la chaîne de connexion, le comportement du fournisseur d'accès aux données dépend du protocole réseau et du système d'exploitation du client, comme indiqué ci-après :
Pour TCP/IP, si le client exécute Microsoft Windows XP ou version ultérieure, les tentatives de connexion sont régies par un algorithme de tentative de connexion qui est spécifique à la mise en miroir de bases de données. L'algorithme de tentative de connexion détermine la durée maximale (la durée d'essai) allouée à l'ouverture d'une connexion pendant une tentative de connexion donnée. Pour plus d'informations, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.
Pour les autres protocoles réseau et pour les clients n'exécutant pas Microsoft Windows XP ou version ultérieure
Si une erreur se produit ou si le serveur partenaire initial est indisponible, la tentative de connexion initiale attend l'expiration du délai d'attente de la connexion réseau ou du délai d'attente de la connexion du fournisseur d'accès aux données. En général, ce délai est de l'ordre de 20 à 30 secondes. Ensuite, si la connexion du fournisseur d'accès aux données n'a pas expiré, le fournisseur tente de se connecter au serveur partenaire de basculement. Si le délai d'attente de la connexion expire avant l'établissement de la connexion ou si le serveur partenaire de basculement est indisponible, la tentative de connexion échoue. Par contre, si le serveur partenaire de basculement est disponible avant l'expiration du délai d'attente de la connexion et qu'il s'agit désormais du serveur principal, la tentative de connexion aboutit généralement.
Chaînes de connexion pour une base de données en miroir
La chaîne de connexion fournie par le client contient des informations que le fournisseur d'accès aux données utilise pour se connecter à la base de données. Cette section présente les mots clés qui sont tout particulièrement appropriés pour se connecter à une base de données mise en miroir à l'aide d'une connexion au pilote ODBC de SQL Server Native Client. Pour plus d'informations sur l'ensemble des mots clés de chaînes de connexion, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.
Attribut Network
La chaîne de connexion doit contenir l'attribut Network pour spécifier le protocole réseau. Cela permet d'assurer la persistance du protocole réseau spécifié entre les connexions avec différents serveurs partenaires. TCP/IP est le meilleur protocole pour se connecter à une base de données mise en miroir. Pour garantir que le client exige TCP/IP à chaque fois qu'il se connecte aux serveurs partenaires, la chaîne de connexion doit fournir l'attribut suivant :
Network=dbmssocn;
Important
Nous vous recommandons de laisser TCP/IP en haut de la liste de protocoles d'un client. Toutefois, si la chaîne de connexion spécifie l'attribut Network, l'ordre de cette liste est ignoré.
Sinon, pour garantir que le client exige des canaux nommés à chaque fois qu'il se connecte aux serveurs partenaires, la chaîne de connexion doit fournir l'attribut suivant :
Network=dbnmpntw;
Important
Étant donné que le protocole des canaux nommés n'utilise pas l'algorithme de tentative de connexion TCP/IP, une tentative de connexion utilisant des canaux nommés risque, dans de nombreux cas, d'expirer avant de se connecter à une base de données mise en miroir.
Attribut Server
La chaîne de connexion doit contenir un attribut Server indiquant le nom du serveur partenaire initial, lequel doit identifier l'instance du serveur principal actuel.
La façon la plus simple d'identifier l'instance de serveur consiste à spécifier son nom : <server_name>[\<SQL_Server_instance_name>]. Par exemple :
Server=Partner_A;
ou
Server=Partner_A\Instance_2;
Cependant, lorsque le nom système est utilisé, le client doit effectuer une recherche DNS pour obtenir l'adresse IP du serveur et une requête SQL Server Browser pour obtenir le numéro de port du serveur sur lequel le serveur partenaire réside. Ces recherches et requêtes peuvent être évitées en spécifiant l'adresse IP et le numéro de port du serveur partenaire dans l'attribut Server, au lieu de spécifier le nom du serveur. Cette méthode est recommandée afin de minimiser la possibilité de délais externes pendant la connexion à ce serveur partenaire.
Notes
Il est nécessaire d'effectuer une requête SQL Server Browser si la chaîne de connexion spécifie le nom de l'instance nommée et pas le port.
Pour spécifier l'adresse IP et le numéro de port, l'attribut Server doit se présenter sous la forme suivante : Server=<ip_address>,<port>. Par exemple :
Server=123.34.45.56,4724;
Notes
L'adresse IP peut être une adresse IPv4 (IP version 4) ou IPv6 (IP version 6).
Attribut Database
En outre, la chaîne de connexion doit spécifier l'attribut Database pour fournir le nom de la base de données mise en miroir. Si la base de données est indisponible lors de la tentative de connexion du client, une exception est générée.
Par exemple, pour se connecter explicitement à la base de données AdventureWorks2008R2 sur le serveur principal Partner_A, un client doit utiliser la chaîne de connexion suivante :
" Server=Partner_A; Database=AdventureWorks2008R2 "
Notes
Cette chaîne omet les informations d'authentification. Pour plus d'informations sur les mots clés à utiliser pour l'authentification intégrée, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.
Important
L'intégration du préfixe du protocole avec l'attribut Server (Server=tcp:<servername>) est incompatible avec l'attribut Network et si vous spécifiez le protocole dans les deux endroits, vous allez probablement obtenir une erreur. Par conséquent, il est recommandé qu'une chaîne de connexion spécifie le protocole à l'aide de l'attribut Network et spécifie uniquement le nom du serveur dans l'attribut Server ("Network=dbmssocn; Server=<servername>").
Attribut Failover Partner
Outre le nom du serveur partenaire initial, le client peut aussi spécifier le nom du serveur partenaire de basculement, lequel doit identifier l'instance du serveur miroir actuel. Le serveur partenaire de basculement est spécifié par l'un des mots clés pour l'attribut de serveur partenaire de basculement. Le mot clé de cet attribut dépend de l'API que vous utilisez. La table suivante répertorie ces mots clés :
API |
Mot clé pour l'attribut de serveur partenaire de basculement |
|---|---|
Fournisseur OLE DB |
FailoverPartner |
Pilote ODBC |
Failover_Partner |
ActiveX Data Objects (ADO) |
Failover Partner |
Pour plus d'informations sur les mots clés de ces API, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.
La façon la plus simple d'identifier l'instance de serveur consiste à spécifier son nom système : <server_name>[\<SQL_Server_instance_name>].
Sinon, l'adresse IP et le numéro de port peuvent être fournis dans l'attribut Failover Partner. Si la tentative de connexion initiale échoue au cours de la première connexion à la base de données, la tentative de connexion au serveur partenaire de basculement ne sera pas tributaire de DNS et de SQL Server Browser. Une fois qu'une connexion est établie, le nom du serveur partenaire de basculement sera remplacé par le nom du serveur partenaire de basculement, si bien qu'en cas de basculement, les connexions redirigées feront appel à DNS et à SQL Server Browser.
Notes
Lorsque seul le nom du serveur partenaire initial est fourni, les développeurs d'applications n'ont rien à faire, ni aucun code à écrire, mis à part le code relatif à la reconnexion.
Notes
Les développeurs d'applications en code managé fournissent le nom du serveur partenaire de basculement dans la propriété ConnectionString de l'objet SqlConnection. Pour plus d'informations sur l'utilisation de cette chaîne de connexion, consultez « Database Mirroring Support in the .NET Framework Data Provider for SQL Server » (en anglais) dans la documentation ADO.NET qui fait partie du kit de développement logiciel (SDK) Microsoft .NET Framework.
Exemple de chaîne de connexion
Par exemple, pour se connecter explicitement à l'aide de TCP/IP à la base de données AdventureWorks2008R2 sur Partner_A ou sur Partner_B, une application cliente qui utilise le pilote ODBC peut fournir la chaîne de connexion suivante :
"Server=Partner_A; Failover_Partner=Partner_B; Database=AdventureWorks2008R2; Network=dbmssocn"
Sinon, le client peut utiliser l'adresse IP et le numéro de port pour identifier le serveur partenaire initial, Partner_A ; par exemple, si l'adresse IP est 250.65.43.21 et le numéro de port est 4734, la chaîne de connexion est la suivante :
"Server=250.65.43.21,4734; Failover_Partner=Partner_B; Database=AdventureWorks2008R2; Network=dbmssocn"
Voir aussi