Témoin de mise en miroir de base de données

  • Article

Pour permettre la prise en charge du basculement automatique, une session de mise en miroir de base de données doit être configurée en mode haute sécurité et disposer d'une troisième instance de serveur, appelée témoin. Le témoin correspond à une instance facultative de SQL Server qui active le serveur miroir dans une session en mode haute sécurité pour déterminer s'il est nécessaire d'initier un basculement automatique. Contrairement aux deux partenaires, le témoin n'est pas au service de la base de données. La prise en charge du basculement automatique est le seul rôle rempli par le témoin.

ms175191.note(fr-fr,SQL.90).gifRemarque :
En mode haute sécurité, le témoin peut avoir une influence négative sur la disponibilité. Si un témoin est configuré pour une session de mise en miroir de base de données, le serveur principal doit être connecté à au moins une des autres instances de serveur, le serveur miroir ou le témoin, ou les deux. Sinon, la base de données n'est plus disponible et forcer le service (perte de données possible) est impossible. Par conséquent, en mode haute performance, il est fortement recommandé de toujours conserver le témoin défini sur OFF. Pour plus d'informations sur l'impact du témoin sur le mode hautes performances, consultez Mise en miroir asynchrone de bases de données (mode hautes performances).

La figure ci-dessous présente une session en mode haute sécurité avec témoin.

Session de mise en miroir avec un témoin

Utilisation d'un témoin dans plusieurs sessions

Une instance du serveur spécifique peut servir de témoin dans des sessions de mise en miroir de base de données simultanées, à raison d'une session par base de données différente. Différentes sessions ont lieu avec différents partenaires. L'illustration suivante montre une instance de serveur témoin qui participe à deux sessions de mise en miroir de base de données avec différents partenaires.

Instance de serveur témoin pour 2 bases de données

Une même instance de serveur peut également fonctionner simultanément en tant que témoin au sein de certaines sessions et en tant que partenaire au sein d'autres sessions. En pratique, cependant, une instance de serveur fonctionne typiquement soit en tant que témoin, soit en tant que partenaire. La raison en est que les partenaires imposent l'utilisation d'ordinateurs sophistiqués disposant d'un niveau de matériel suffisant pour prendre en charge une base de données de production, alors que le serveur témoin peut s'exécuter sur tout système Windows disponible prenant en charge SQL Server 2005.

Recommandations logicielles et matérielles

Nous vous recommandons vivement de placer le témoin sur un ordinateur distinct de celui des partenaires. Contrairement aux partenaires de mise en miroir de bases de données pris en charge uniquement par SQL Server 2005 Standard Edition et SQL Server 2005 Enterprise Edition, les témoins sont aussi pris en charge par SQL Server 2005 Workgroup Edition et SQL Server 2005 Express Edition. Un témoin peut être exécuté sur n'importe quel système informatique fiable prenant en charge SQL Server 2005 mais il est recommandé que chaque instance du serveur utilisée comme témoin respecte une configuration minimale requise pour SQL Server 2005 Standard Edition. Pour plus d'informations sur cette configuration requise, consultez Configuration matérielle et logicielle requise pour l'installation de SQL Server 2005.

Rôle du témoin en basculement automatique

Pendant tout le déroulement d'une session de mise en miroir d'une base de données, toutes les instances de serveur surveillent l'état de leur connexion. Si les partenaires se déconnectent, ils s'en remettent au témoin pour vérifier qu'un seul d'entre eux sert actuellement la base de données. Si un serveur miroir synchronisé perd sa connexion au serveur principal, mais reste connecté au témoin, le serveur miroir contacte le témoin pour déterminer si le témoin a perdu sa connexion au serveur principal :

  • Si le serveur principal est toujours connecté au témoin, le basculement automatique n'a pas lieu. Le serveur principal continue en fait à servir la base de données tout en accumulant les enregistrements du journal à envoyer au serveur miroir lorsque les partenaires se reconnectent.
  • Si le témoin est aussi déconnecté du serveur principal, le serveur miroir détecte que cette base de données principale n'est plus disponible. Dans ce cas, le serveur miroir initie immédiatement un basculement automatique.
  • Si le serveur miroir est déconnecté du témoin ainsi que du serveur principal, le basculement automatique n'est pas possible, indépendamment de l'état du serveur principal.

La condition selon laquelle au moins deux instances de serveur doivent être connectées s'appelle quorum. Le quorum garantit que la base de données ne peut être servie que par un seul partenaire à la fois. Pour des informations sur le fonctionnement du quorum et son impact sur une session, consultez Quorum : effets d'un témoin sur la disponibilité de la base de données.

Ajout ou suppression d'un témoin

Pour ajouter un témoin

Pour supprimer le témoin

Voir aussi

Concepts

Basculement automatique
Quorum : effets d'un témoin sur la disponibilité de la base de données
Défaillances possibles pendant la mise en miroir d'une base de données
États de la mise en miroir
Mise en miroir synchrone de bases de données (mode Haute sécurité)

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

17 juillet 2006
Contenu modifié :
  • Réorganisation de la rubrique pour faire ressortir la configuration matérielle et logicielle.
  • Développement de la description du rôle du témoin.

5 décembre 2005
Nouveau contenu :
  • Exécution du témoin sur tout système informatique fiable prenant en charge SQL Server.
Contenu modifié :
  • Suppression de la phrase établissant que le témoin ferme toutes les connexions à la base de données principale et la redémarre.