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.
Notes
Cette rubrique suppose que vous connaissez bien les modes de fonctionnement de la mise en miroir de base de données. Pour plus d'informations, consultez Mise en miroir asynchrone de bases de données (mode hautes performances) et Mise en miroir synchrone de bases de données (mode Haute sécurité).
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.
Important
Après un basculement de rôle, les travaux qui s'exécutaient sur l'ancienne base de données principale doivent être recréés sur le nouveau serveur principal pour y être exécutés. Pour plus d'informations, consultez Gestion des connexions et des travaux après un basculement de rôle.
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.
Notes
Si vous ne connaissez pas bien ces modes de fonctionnement, consultez Sessions de mise en miroir de bases de données.
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).
Notes
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.
Hautes performances |
Mode haute performance sans témoin |
Mode haute performance avec témoin |
|
---|---|---|---|
Basculement automatique |
Non |
Non |
Oui |
Basculement manuel |
Non |
Oui |
Oui |
Service forcé |
Oui |
Oui |
Non |
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.
Voir aussi