Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans le contexte d’une session de mise en miroir de bases de données, les rôles principal et miroir sont généralement interchangeables dans un processus appelé basculement de rôle. Dans le changement de rôle, le serveur miroir agit comme partenaire de basculement pour le serveur principal, en prenant le rôle principal, en récupérant sa copie de la base de données et en le mettant en ligne en tant que nouvelle base de données principale. L’ancien serveur principal, lorsqu’il est disponible, assume le rôle miroir et sa base de données devient la nouvelle base de données miroir. Potentiellement, les rôles peuvent basculer en arrière en réponse à plusieurs défaillances ou à des fins administratives.
Remarque
Cette rubrique part du principe que vous êtes familiarisé avec les modes d’exploitation de mise en miroir de bases de données. Pour plus d’informations, consultez Modes d’exploitation de mise en miroir de bases de données.
L’illustration suivante montre les partenaires de mise en miroir Partner_A et Partner_B qui échangent leurs rôles principal et miroir au cours d'une série de basculements automatiques ou manuels.
Important
Après une commutation de rôle, les tâches exécutées sur l’ancienne base de données principale doivent être recréées sur le nouveau serveur principal pour les exécuter. Pour plus d’informations, consultez Gestion des connexions et des travaux après le basculement de rôle (SQL Server).
Trois types de basculement de rôle existent : basculement automatique, basculement manuel et service forcé (avec perte de données possible). La prise en charge de chaque formulaire dépend du mode d’exploitation de la session.
Remarque
Si vous n’êtes pas familiarisé avec ces modes d’exploitation, consultez Les modes de fonctionnement de la 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 lancer un basculement manuel.
Le basculement manuel est proposé à titre administratif. Pour plus d’informations, consultez Basculement manuel, plus loin dans cette rubrique.
Basculement automatique
En présence d’un témoin, le mode haute sécurité prend en charge le basculement automatique. Le basculement automatique se produit uniquement lors de la perte du serveur principal lorsque le témoin et le serveur 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, plus loin dans cette rubrique.
Service forcé (avec perte de données possible)
Le service forcé est pris en charge en mode haute sécurité lorsqu’aucun témoin n’est défini et en mode hautes performances. En cas de 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 au serveur miroir (avec perte de données possible).
Remarque
Nous vous recommandons de définir la propriété WITNESS sur OFF en mode hautes performances. Sinon, pour mettre la base de données en ligne, le serveur miroir doit se connecter au témoin.
Pour plus d’informations, consultez Service forcé (avec perte de données possible) plus loin dans cette rubrique.
Le tableau suivant résume les formes de basculement prises en charge sous chacun des modes d’exploitation.
| Hautes performances | Mode haute sécurité sans témoin | Mode haute sécurité avec un témoin | |
|---|---|---|---|
| Basculement automatique | Non | Non | Oui |
| Basculement manuel | Non | Oui | Oui |
| Service forcé | Oui | Oui | Non |
Après un changement de rôle, certaines métadonnées doivent exister sur les deux partenaires pour s’assurer que tous les utilisateurs de la base de données peuvent accéder à la nouvelle base de données principale. En outre, les travaux de sauvegarde doivent être créés sur le nouveau serveur principal pour s’assurer que la base de données continue d’être sauvegardée selon sa planification régulière. Pour plus d’informations, consultez Gestion des connexions et des travaux après le basculement de rôle (SQL Server).
Pendant un changement de rôle, la durée pendant laquelle la mise en miroir des bases de données est interrompue dépend du type de changement de rôle et de la cause. Pour plus d’informations, consultez Estimer l’interruption du service pendant le basculement de rôle (mise en miroir de bases de données).
Basculement manuel
Le basculement manuel déconnecte les clients de la base de données et inverse les rôles des partenaires. Seul le mode haute sécurité prend en charge le basculement manuel.
Maintien de la disponibilité lors des mises à niveau
L’administrateur de base de données peut utiliser le basculement manuel pour mettre à niveau du matériel ou des logiciels sans sacrifier la disponibilité. Pour utiliser la mise en miroir de bases de données pour les mises à niveau logicielles, le serveur miroir et/ou le système doivent déjà avoir reçu les mises à niveau.
Remarque
La mise en miroir de bases de données doit être en mesure d’effectuer une mise à niveau propagée, mais cela n’est pas garanti, car les modifications futures sont inconnues. Pour plus d’informations, consultez Réduire les temps d’arrêt pour les bases de données mises en miroir lors de la mise à niveau des instances de serveur.
La figure suivante illustre un exemple d'utilisation d'un basculement manuel pour maintenir la disponibilité de la base de données pendant la mise à jour d'une instance de serveur de base de données. Une fois la mise à niveau terminée, un administrateur peut éventuellement basculer vers l’instance de serveur d’origine. Cela est utile lorsque l’administrateur souhaite arrêter la session de mise en miroir et utiliser le serveur miroir ailleurs. De cette façon, une seule instance de serveur peut être utilisée à plusieurs reprises lors de la mise à jour d’une série d’instances de serveur de base de données.
Conditions requises pour un basculement manuel
Le basculement manuel nécessite que la sécurité des transactions soit définie sur FULL (c’est-à-dire en mode haute sécurité). Lorsque les partenaires sont connectés et que la base de données est déjà synchronisée, le basculement manuel est supporté.
Fonctionnement du basculement manuel
Le basculement manuel lance la séquence d’actions suivante :
Le serveur principal déconnecte les clients de la base de données principale, envoie la fin du journal au serveur miroir et, en vue de passer au rôle miroir, définit l’état de mise en miroir sur SYNCHRONIZING.
Le serveur miroir enregistre le numéro de séquence de journal (LSN) du dernier enregistrement du journal reçu du principal en tant que LSN de basculement.
Remarque
Pour afficher ce numéro LSN, sélectionnez la colonne mirroring_failover_lsn dans sys.database_mirroring (Transact-SQL).
Si un journal attend dans la file d’attente de restauration automatique, le serveur miroir termine la progression de la base de données miroir. La durée requise dépend de la vitesse du système, de la charge de travail récente et de la quantité de journalisation dans la file d’attente de redo. Pour un mode d’exploitation synchrone, le temps de basculement peut être réglementé en limitant la taille de la file d’attente de rétablissement. Toutefois, cela peut entraîner le ralentissement du serveur principal pour permettre au serveur miroir de rester à jour.
Remarque
Pour en savoir plus sur la taille actuelle de la file d’attente de rétablissement, utilisez le compteur de performances de la file d’attente de rétablissement dans l’objet de performances de mise en miroir de bases de données (pour plus d’informations, consultez Surveillance de la mise en miroir de bases de données (SQL Server)).
Le serveur miroir devient le nouveau serveur principal et l’ancien serveur principal devient le nouveau serveur miroir.
Le nouveau serveur principal restaure toutes les transactions non validées et apporte sa copie de la base de données en ligne en tant que base de données principale.
L’ancien principal prend le rôle miroir, et l’ancienne base de données principale devient la base de données miroir. Le nouveau serveur miroir resynchronise rapidement la nouvelle base de données miroir avec la nouvelle base de données principale.
Remarque
Dès que le nouveau serveur miroir a resynchronisé les bases de données, le basculement est à nouveau possible, mais dans le sens inverse.
Après le basculement, les clients doivent se reconnecter à la base de données principale actuelle. Pour plus d’informations, consultez Connecter des clients à une session de mise en miroir de bases de données (SQL Server).
Pour lancer le basculement manuel
Basculement manuel d'une session de miroir de bases de données (SQL Server Management Studio)
Basculez manuellement une session de mise en miroir de bases de données (Transact-SQL).
Basculement automatique
Le basculement automatique est pris en charge uniquement dans les sessions de mise en miroir de bases de données exécutées avec un témoin en mode haute sécurité (mode haute sécurité avec basculement automatique). En mode haute sécurité avec basculement automatique, une fois la base de données synchronisée, si la base de données principale devient indisponible, un basculement automatique se produit. Un basculement automatique fait en sorte que le serveur miroir prenne le rôle du serveur principal et mette sa copie de la base de données en ligne comme base de données principale. Exiger que la base de données soit synchronisée empêche la perte de données pendant le basculement, car chaque transaction validée sur la base de données principale est également validée sur la base de données miroir.
Important
Pour que le basculement automatique améliore la fiabilité, la base de données miroir et la base de données principale doivent résider sur différents ordinateurs.
Conditions requises pour un basculement automatique
Le basculement automatique nécessite les conditions suivantes :
La session de mise en miroir de bases de données doit s’exécuter en mode haute sécurité et doit posséder un témoin. Pour plus d’informations, consultez Modes d’exploitation de mise en miroir de bases de données.
La base de données miroir doit déjà être synchronisée. Cela garantit que tous les logs envoyés au serveur miroir ont été écrits sur le disque.
Le serveur principal a perdu la communication avec le reste de la configuration miroir de la base de données, tandis que le miroir et le témoin conservent le quorum. Toutefois, si toutes les instances de serveur perdent la communication et que le témoin et le serveur miroir récupèrent ultérieurement la communication, le basculement automatique ne se produit pas.
Remarque
Pour plus d’informations, consultez Quorum : Comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données).
Le serveur miroir a détecté la perte du serveur principal.
La façon dont le serveur miroir détecte une défaillance du serveur principal dépend du fait qu’il s’agit d’une défaillance matérielle ou réversible. Pour plus d’informations, consultez Échecs possibles pendant la mise en miroir de bases de données.
Fonctionnement du basculement automatique
Dans les conditions précédentes, le basculement automatique lance la séquence d’actions suivante :
Si le serveur principal est toujours en cours d’exécution, il modifie l’état de la base de données principale en DISCONNECTED et déconnecte tous les clients de la base de données principale.
Les serveurs témoin et miroir inscrivent que le serveur principal n’est pas disponible.
Si un journal attend dans la file d'attente de redo, le serveur miroir complète l'avancement de la base de données miroir.
Remarque
La durée nécessaire à l'application du log dépend de la vitesse du système, de la charge de travail récente et de la quantité de log dans la file d'attente de réexécution.
L’ancienne base de données miroir se déplace en ligne en tant que nouvelle base de données principale et la récupération nettoie toutes les transactions non validées en les supprimant aussi rapidement que possible. Les verrous isolent ces transactions.
Lorsque l’ancien serveur principal rejoint la session, il reconnaît que son partenaire de basculement possède désormais le rôle principal. L’ancien serveur principal prend le rôle de miroir, ce qui fait de sa base de données la base de données miroir. Le nouveau serveur miroir synchronise la nouvelle base de données miroir avec la base de données principale le plus rapidement possible. Dès que le nouveau serveur miroir a resynchronisé les bases de données, le basculement devient à nouveau possible, mais cette fois-ci dans l'autre sens.
L’illustration suivante montre une instance unique de basculement automatique.
Initialement, les trois serveurs sont connectés (la session a un quorum complet). Partner_A est le serveur principal et Partner_B est le serveur miroir. Partner_A (ou la base de données principale sur Partner_A) devient indisponible. Le témoin et Partner_B reconnaissent tous les deux que le principal n’est plus disponible, mais que la session conserve néanmoins le quorum. Partner_B devient le serveur principal et rend sa copie de la base de données disponible en tant que nouvelle base de données principale. Finalement, Partner_A se reconnecte à la session et découvre que Partner_B possède désormais le rôle principal. Partner_A prend ensuite le rôle miroir.
Après le basculement, les clients doivent se reconnecter à la base de données principale actuelle. Pour plus d’informations, consultez Connecter des clients à une session de mise en miroir de bases de données (SQL Server).
Remarque
Les transactions qui ont été préparées à l’aide de Microsoft Distributed Transaction Coordinator, mais qui ne sont toujours pas validées lorsqu’un basculement se produit, sont considérées comme abandonnées après le basculement de la base de données.
Pour désactiver le basculement automatique (SQL Server Management Studio)
Ouvrez la page Database PropertiesMirroring et modifiez le mode d’exploitation en sélectionnant l’une des options suivantes :
Haute sécurité sans basculement automatique (synchrone)
Dans ce mode, la base de données continue d’être synchronisée et le basculement manuel reste possible.
Hautes performances (asynchrones)
Dans ce mode, la base de données miroir peut prendre du retard par rapport à la base de données principale, et le basculement manuel n'est plus du tout possible.
Pour désactiver le basculement automatique (à l’aide de Transact-SQL)
À tout moment dans une session de mise en miroir de bases de données, le propriétaire de la base de données peut désactiver le basculement automatique en désactivant le témoin.
Pour désactiver le témoin
Supprimer le témoin d’une session de mise en miroir de bases de données (SQL Server)
Remarque
La désactivation du témoin tout en conservant la sécurité complète des transactions place la session en mode haute sécurité sans basculement automatique.
Service forcé (avec perte de données possible)
La mise en miroir de bases de données fournit un service forcé (avec perte de données possible) comme méthode de récupération d’urgence pour vous permettre d’utiliser un serveur miroir comme serveur de secours chaud. Le service forcé est possible uniquement si le serveur principal est déconnecté du serveur miroir dans une session de mise en miroir. Étant donné que forcer le service risque de perte de données possible, il doit être utilisé avec prudence et avec parcimonie.
La prise en charge du service forcé dépend du mode d’exploitation et de l’état de la session, comme suit :
En règle générale, le mode hautes performances prend en charge le service forcé chaque fois que le serveur principal est déconnecté. Toutefois, bien qu’il soit inutile, un témoin peut exister pour une session en mode hautes performances. L'activation forcée du service nécessite que le serveur miroir et le témoin soient connectés l'un à l'autre.
Le mode haute sécurité sans basculement automatique prend en charge le service forcé chaque fois que le serveur principal est déconnecté.
Le mode haute sécurité avec basculement automatique prend en charge le service forcé chaque fois que le serveur miroir et le témoin sont connectés les uns aux autres et qu’aucun des deux n’est connecté au serveur principal (tant que le serveur miroir n’a pas été en cours de restauration de la base de données miroir lors de sa dernière connexion au principal).
Nous vous recommandons de forcer le service uniquement si vous devez restaurer le service sur la base de données immédiatement et que vous êtes prêt à risquer de perdre des données. L’effet du service forcé est similaire à la suppression de la mise en miroir, sauf que le service forcé facilite la resynchronisation des bases de données lors de la reprise de la mise en miroir, au risque de perte de données possible. Le déclenchement du service initie une transition fluide du rôle principal vers la base de données miroir. Le serveur miroir assume le rôle du serveur principal et sert immédiatement sa copie de la base de données aux clients. La nouvelle base de données principale s’exécute sans miroir (autrement dit, elle s’exécute exposée).
Important
Si le serveur principal était simplement déconnecté de la session de mise en miroir de bases de données et qu’il est toujours en cours d’exécution, certains clients peuvent continuer à accéder à la base de données principale d’origine. Avant de forcer le service, il est important d’empêcher les clients d’accéder au serveur principal d’origine. Sinon, une fois le service forcé, la base de données principale d'origine et la base de données principale actuelle peuvent être mises à jour chacune indépendamment l'une de l'autre.
Cas typique du service forcé
La figure suivante illustre un cas classique de service forcé (avec perte de données possible).
Dans la figure, le serveur principal d’origine, Partner_A, devient indisponible pour le serveur miroir, Partner_B, ce qui entraîne la déconnexion de la base de données miroir. Après avoir vérifié que Partner_A n’est pas disponible pour les clients, l’administrateur de base de données force le service, avec une perte de données possible, sur Partner_B. Partner_B devient le serveur principal et s'exécute avec la base de données exposée (autrement dit, non mis en miroir). À ce stade, les clients peuvent se reconnecter à Partner_B.
Lorsque Partner_A devient disponible, il se reconnecte au nouveau serveur principal, rejoint la session et suppose le rôle miroir. La session de mise en miroir est suspendue immédiatement, sans avoir synchronisé la nouvelle base de données miroir. La suspension de la session permet à l’administrateur de base de données de décider s’il faut reprendre la session ou, dans des cas extrêmes, supprimer la mise en miroir et tenter de récupérer les données de l’ancienne base de données principale. Dans ce cas, l’administrateur de base de données choisit de reprendre la mise en miroir. À ce stade, Partner_A prend le rôle du serveur miroir et restaure l’ancienne base de données principale jusqu’au moment de la dernière transaction synchronisée avec succès ; si des transactions validées n’ont pas été écrites sur le disque sur le serveur miroir avant que le service ne soit forcé, elles sont perdues. Partner_A avance ensuite la nouvelle base de données miroir en appliquant les modifications faites sur la nouvelle base de données principale depuis que l'ancien serveur miroir est devenu le nouveau serveur principal.
Remarque
Bien que le mode hautes performances ne nécessite pas de témoin, s’il est configuré, le service forcé est possible uniquement si le témoin est actuellement connecté au serveur miroir.
Risques liés au service forcé
Il est essentiel de comprendre que le service forcé peut entraîner une perte de données. La perte de données est possible, car le serveur miroir ne peut pas communiquer avec le serveur principal et, par conséquent, ne peut pas garantir que les deux bases de données sont synchronisées. Forcer le démarrage du service crée une nouvelle bifurcation de restauration. Étant donné que la base de données principale d’origine et la base de données miroir se trouvent sur des forks de récupération différents, chaque base de données contient désormais des données que l’autre base de données ne contient pas : la base de données principale d’origine contient les modifications qui n’ont pas encore été envoyées de sa file d’attente d’envoi à l’ancienne base de données miroir (le journal non envoyé) ; l’ancienne base de données miroir contient les modifications qui se produisent après que le service a été forcé.
Si le service est forcé parce que le serveur principal a échoué, la perte de données potentielle dépend du fait que les journaux des transactions n’ont pas été envoyés au serveur miroir avant l’échec. En mode haute sécurité, cela n’est possible que jusqu’à ce que la base de données miroir soit synchronisée. En mode hautes performances, le journal non envoyé accumulé reste toujours une éventualité.
Les implications du service forcé dépendent en partie du fait que la session dispose d’un témoin :
En l’absence d’un témoin, le service peut être forcé si les partenaires se retrouvent déconnectés, par exemple en raison d'une interruption de leur connexion réseau. Si le serveur principal d’origine est toujours en cours d’exécution, les deux partenaires possèdent le rôle principal. Les clients qui se connectent au nouveau serveur principal accèdent à la version actuelle de la base de données, tandis que les clients qui se connectent au serveur principal d’origine accèdent à la base de données principale d’origine. Cette situation augmente le risque de perte de données. Si les partenaires sont autorisés à se reconnecter, le serveur principal d’origine assume le rôle miroir et modifie l’état de sa base de données en « récupération », avant la suspension de la mise en miroir. Si la session est reprise, les transactions sur la base de données principale d’origine dont le journal était dans la file d’attente d’envoi lors de la récente déconnexion sont perdues. En outre, toutes les transactions qui se sont produites après que le service a été forcé sont également perdues.
En présence d’un témoin, si le serveur miroir est déconnecté à la fois du serveur principal et du témoin, tant que le serveur principal et le témoin restent connectés entre eux, le serveur principal continue à fonctionner de façon exposée. Si le serveur principal devient alors déconnecté du témoin, il cesse de servir la base de données. Par la suite, si le serveur miroir se reconnecte au témoin, le service forcé devient possible. Si le service est forcé, toutes les modifications apportées pendant l’exécution du serveur principal d’origine sont perdues si le serveur principal d’origine se reconnecte.
Pour plus d’informations, consultez Gestion de la perte de données potentielle, plus loin dans cette rubrique.
Gestion de la perte de données potentielle
Une fois le service forcé, une fois que l’ancien serveur principal est disponible, en supposant que sa base de données n’est pas endommagée, vous pouvez tenter de gérer la perte de données potentielle. L’approche disponible pour la gestion de la perte de données potentielle dépend du fait que le serveur principal d’origine s’est reconnecté à son partenaire et rejoint la session de mise en miroir. En supposant que le serveur principal d’origine peut accéder à la nouvelle instance de principal, la reconnexion se produit automatiquement et de manière transparente.
Le serveur principal d’origine a reconnecté
En règle générale, après une défaillance, lorsque le serveur principal d’origine redémarre, il se reconnecte rapidement à son partenaire. Lors de la reconnexion, le serveur principal d’origine devient le serveur miroir. Sa base de données devient la base de données miroir et entre dans l’état de récupération avant la suspension de la session. La base de données miroir ne sera pas restaurée, sauf si vous reprenez la mise en miroir.
Toutefois, la base de données de récupération est inaccessible ; par conséquent, vous ne pouvez pas l’inspecter pour évaluer les données qui seraient perdues si vous deviez reprendre la mise en miroir. Par conséquent, la décision de reprendre ou de supprimer la mise en miroir dépend de la volonté d’accepter toute perte de données.
Si perdre une quelconque donnée serait inacceptable, vous devriez supprimer la mise en miroir pour les préserver.
La suppression de la mise en miroir permettrait à l’administrateur de base de données de récupérer la base de données principale d’origine et de tenter de récupérer les données qui auraient été perdues. Toutefois, lorsque l’ancienne base de données miroir est mise en ligne, les anciens partenaires servent des bases de données divergentes portant le même nom. L’administrateur de base de données doit rendre l’une des bases de données inaccessibles aux clients afin d’éviter une autre divergence de la base de données et d’éviter les problèmes de basculement du client.
Si la perte de certaines données est acceptable, vous pouvez reprendre la mise en miroir.
La reprise de la mise en miroir entraîne l'annulation de la nouvelle base de données miroir lors de la première étape de la synchronisation de la base de données. Si des enregistrements de journal se trouvaient dans la file d'attente d'envoi au moment de la défaillance, les transactions correspondantes sont perdues, même si elles ont été validées.
Le serveur principal d’origine n’a pas été reconnecté
Si vous pouvez empêcher temporairement le serveur principal d’origine de se reconnecter sur le réseau au nouveau serveur principal, vous pouvez inspecter la base de données principale d’origine pour évaluer les données qui seraient perdues si la mise en miroir a été reprise.
Si la perte de données potentielle est acceptable
Autoriser le serveur principal d’origine à se reconnecter à son partenaire. La reconnexion entraîne la suspension de la mise en miroir. Pour poursuivre la mise en miroir, reprenez simplement la session. L’ancien serveur principal assume le rôle miroir. Le nouveau serveur miroir supprime le fork de récupération d’origine, ce qui perd toutes les transactions qui n’ont jamais été envoyées ou reçues par l’ancien serveur miroir.
Si la perte de données est inacceptable
Si la base de données principale d’origine contient des données critiques qui seraient perdues si vous avez repris la session, vous pouvez conserver les données sur le serveur principal d’origine en supprimant la mise en miroir. Nous vous recommandons de tenter de créer une sauvegarde de la fin du journal du principal à ce stade. Ensuite, vous pouvez mettre à jour le principal actuel (l’ancienne base de données miroir) en exportant les données que vous souhaitez récupérer à partir de la base de données principale d’origine et en l’important dans la base de données principale actuelle. Nous vous recommandons d’effectuer une sauvegarde complète de la base de données mise à jour le plus rapidement possible.
Pour rétablir la mise en miroir avec la base de données mise à jour en tant que base de données principale initiale, utilisez cette sauvegarde (et au moins une sauvegarde de journal ultérieure) pour créer une base de données miroir. Chaque sauvegarde de journal effectuée après la suppression de la mise en miroir doit être appliquée. Par conséquent, nous vous recommandons de différer les sauvegardes de journaux supplémentaires de la base de données principale jusqu’à ce que la nouvelle session de mise en miroir démarre.
Tâches liées à la gestion d’un basculement forcé
Pour forcer le service
Pour reprendre la mise en miroir de bases de données
Pour créer une base de données miroir
Préparer une base de données miroir pour la mise en miroir (SQL Server)
Pour démarrer la mise en miroir de bases de données
Voir aussi
Estimer l'interruption de service au cours d'un basculement de rôle (mise en miroir de bases de données)
Échecs possibles pendant la mise en miroir de bases de données
Connecter des clients à une session de mise en miroir de bases de données (SQL Server)
Témoin de la mise en miroir de bases de données
Restaurations complètes de bases de données (mode de récupération complète)
Modes de fonctionnement de la mise en miroir de bases de données
États de mise en miroir (SQL Server)