Utilisation de la mise en miroir de bases de données

 

System_CAPS_ICON_note.jpg Remarque


Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.Utilisez Groupes de disponibilité AlwaysOn à la place.

La mise en miroir de bases de données, introduite dans SQL Server 2005, est une solution permettant d'accroître la disponibilité de la base de données et la redondance des données. SQL ServerNative Client fournit la prise en charge implicite pour la mise en miroir de base de données, le développeur n’a donc pas à écrire du code ou effectuer toute autre action une fois qu’il a été configuré pour la base de données.

Base de données mise en miroir, qui est implémentée par base de données, conserve une copie d’un SQL Server base de données de production sur un serveur de secours. Ce serveur est un serveur de secours automatique ou semi-automatique, selon la configuration et l'état de la session de mise en miroir de bases de données. Un serveur de secours automatique prend en charge le basculement rapide sans perte de transactions validées et un serveur de secours semi-automatique prend en charge le service forcé (avec perte de données possible).

La base de données de production est appelé le base de données principale, et la copie de secours est appelée le base de données miroir. La base de données principale et la base de données miroir doivent résider sur des instances distinctes de SQL Server (instances de serveur), et ils doivent résider sur des ordinateurs distincts, si possible.

L’instance de serveur de production, appelée la serveur principal, communique avec l’instance de serveur de secours, appelée la serveur miroir. Les serveurs principal et miroir agissent en tant que partenaires au sein d’une base de données mise en miroir session. Si le serveur principal échoue, le serveur miroir peut apporter sa base de données dans la base de données principale via un processus appelé basculement. Par exemple, Partner_A et Partner_B sont deux serveurs partenaires, avec initialement la base de données principale sur Partner_A comme serveur principal et la base de données miroir sur Partner_B comme serveur miroir. Si Partner_A se retrouve hors connexion, la base de données sur Partner_B peut basculer pour devenir la base de données principale en cours. Lorsque Partner_A rejoint la session de mise en miroir, il devient le serveur miroir et sa base de données devient la base de données miroir.

D'autres configurations de mise en miroir de bases de données offrent des niveaux différents de performances et de sécurité des données, et prennent en charge diverses formes de basculement. Pour plus d’informations, consultez Mise en miroir de bases de données (SQL Server).

Il est possible d'utiliser un alias lors de la spécification du nom d'une base de données miroir.

System_CAPS_ICON_note.jpg Remarque


Pour plus d’informations sur les tentatives de connexion initial et les tentatives de reconnexion à une base de données mise en miroir, consultez Clients de se connecter à une Session de mise en miroir de base de données (SQL Server).

Lorsque le serveur de la base de données principale échoue, l'application cliente reçoit des erreurs en réponse aux appels d'API, erreurs qui signifient que la connexion à la base de données a été perdue. Lorsque cela se produit, toutes les modifications apportées à la base de données qui n'ont pas été validées sont perdues et la transaction en cours est annulée. Si cela se produit, l'application doit fermer la connexion (ou libérer l'objet source de données) et la rouvrir. La connexion est redirigée de façon transparente vers la base de données miroir, qui fait désormais office de serveur principal.

Lorsqu'une connexion est établie, le serveur principal envoie au client l'identité de son partenaire de basculement à utiliser en cas de basculement. Si une application a essayé d'établir une connexion après un échec du serveur principal, le client ne connaît pas l'identité du partenaire de basculement. Afin que les clients puissent faire face à ce scénario, une propriété d'initialisation et un mot clé de chaîne de connexion associé permettent au client de spécifier l'identité du partenaire de basculement. L'attribut client est utilisé uniquement dans ce scénario ; si le serveur principal est disponible, il n'est pas utilisé. Si le partenaire de basculement fourni par le client ne fait pas référence à un serveur agissant comme partenaire de basculement, la connexion est refusée par le serveur. Pour permettre aux applications de s'adapter aux modifications de configuration, l'identité du partenaire de basculement peut être déterminée en examinant l'attribut après que la connexion a été établie. Si possible, mettez en cache les informations sur le serveur partenaire pour mettre à jour la chaîne de connexion ou imaginer une stratégie de nouvelle tentative au cas où la première tentative d'établissement de la connexion échouerait.

System_CAPS_ICON_note.jpg Remarque


Vous devez spécifier explicitement la base de données utilisée par une connexion si vous souhaitez recourir à cette fonctionnalité dans un DSN, une chaîne de connexion ou une propriété (ou un attribut) de connexion. Si vous ne le faites pas, SQL Server Native Client ne tente pas de basculer sur la base de données du serveur partenaire.

La mise en miroir est une fonctionnalité de la base de données. Il se peut que les applications qui utilisent plusieurs bases de données ne puissent pas exploiter cette fonctionnalité.

De plus, les noms de serveur ne respectent pas la casse, contrairement aux noms de base de données. Par conséquent, vous devez vous assurer que vous utilisez la même casse dans les DSN et les chaînes de connexion.

Le SQL Server Client fournisseur OLE DB natif prend en charge la mise en miroir de base de données via la connexion et les attributs de chaîne de connexion. La propriété SSPROP_INIT_FAILOVERPARTNER a été ajoutée au jeu de propriétés DBPROPSET_SQLSERVERDBINIT et FailoverPartner (mot clé) est un nouvel attribut de chaîne de connexion de DBPROP_INIT_PROVIDERSTRING. Pour plus d’informations, consultez à l’aide de mots clés de chaîne de connexion avec SQL Server Native Client.

Le cache de basculement est conservé tant que le fournisseur est chargé, autrement dit jusqu'à ce que CoUninitialize est appelée ou tant que l’application a une référence à un objet géré par le SQL Server fournisseur OLE DB Native Client comme un objet de source de données.

Pour plus d’informations sur SQL Server prise en charge du fournisseur OLE DB du Client natif pour la mise en miroir de base de données, consultez propriétés d’initialisation et d’autorisation.

Le SQL Server pilote ODBC Native Client prend en charge la mise en miroir de base de données via la connexion et les attributs de chaîne de connexion. Plus précisément, l’attribut SQL_COPT_SS_FAILOVER_PARTNER a été ajouté pour une utilisation avec le SQLSetConnectAttr et SQLGetConnectAttr ; les fonctions et les Failover_Partner mot clé a été ajouté comme un nouvel attribut de chaîne de connexion.

Le cache de basculement est conservé tant que l'application possède au moins un handle d'environnement alloué. En revanche, il est perdu lorsque le dernier handle d'environnement est libéré.

System_CAPS_ICON_note.jpg Remarque


Le Gestionnaire de pilotes ODBC a été amélioré pour prendre en charge la spécification du nom du serveur de basculement.

Fonctionnalités SQL Server Native Client
Connecter des Clients à une base de données mise en miroir de la Session (SQL Server)
Base de données mise en miroir (SQL Server)

Ajouts de la communauté

Afficher: