Basculement de rôle durant une session de mise en miroir de bases de données

Dans le contexte d'une session de mise en miroir de bases de données, le rôle principal et le rôle miroir sont généralement interchangeables lors d'un processus appelé basculement de rôle. Dans une situation de basculement de rôle, le serveur miroir est le partenaire de basculement du serveur principal ; il adopte le rôle principal, récupérant sa copie de la base de données et la mettant en ligne en tant que nouvelle base de données principale. L'ancien serveur principal (s'il est disponible) joue le rôle de serveur miroir, et sa base de données devient la nouvelle base de données miroir. Les rôles peuvent éventuellement basculer plusieurs fois, soit en réponse à plusieurs défaillances, soit pour des raisons administratives.

L'illustration suivante représente des serveurs partenaires de mise en miroir, Partner_A et Partner_B, qui s'échangent les rôles de serveur principal et serveur miroir lors d'une série de basculements automatiques ou manuels.

Il existe trois types de basculement de rôle : le basculement automatique, le basculement manuel et le service forcé (avec perte de données possible). La prise en charge de chaque type de basculement dépend du mode de fonctionnement d'une session.

• Basculement manuel

  Le mode haute sécurité prend en charge le basculement manuel. Chaque fois que la base de données est synchronisée, le propriétaire de la base de données peut entreprendre un basculement manuel.

  Le basculement manuel est adopté pour des raisons administratives. Pour plus d'informations, consultez Basculement manuel.

• Basculement automatique

  En présence d'un témoin, le mode haute sécurité prend en charge le basculement automatique. Celui-ci intervient suite à la perte du serveur principal, si les serveurs témoin et miroir sont toujours connectés entre eux et que la base de données est déjà synchronisée. Pour plus d'informations, consultez Basculement automatique.

• Service forcé (avec possibilité de perte de données)

  Un service forcé est pris en charge en mode haute sécurité lorsqu'aucun témoin n'est défini en mode haute performance. Suite à la perte du serveur principal, le propriétaire de la base de données peut rendre la base de données disponible en forçant le service sur le serveur miroir (avec possibilité de perte de données).

  [!REMARQUE]

  Nous vous recommandons de définir la propriété WITNESS sur OFF en mode haute performance. Sinon, pour mettre la base de données en ligne, le serveur miroir doit être connecté au témoin. Pour plus d'informations, consultez Service forcé (avec possibilité de perte de données).

Le tableau ci-dessous résume les types de basculement pris en charge dans chaque mode de fonctionnement.

Après un basculement de rôle, certaines métadonnées doivent exister sur les deux partenaires pour garantir que tous les utilisateurs de base de données peuvent accéder à la nouvelle base de données principale. De plus, des travaux de sauvegarde doivent être créés sur le nouveau serveur principal pour garantir que la base de données continue d'être sauvegardée régulièrement. Pour plus d'informations, consultez Gestion des connexions et des travaux après un basculement de rôle.

Au cours d'un basculement de rôle, la durée pendant laquelle la mise en miroir de base de données sera hors service dépend du type de basculement de rôle et de sa raison. Pour plus d'informations, consultez Estimation de l'interruption de service au cours d'un basculement de rôle.