Partager via


Basculement automatique

Le basculement automatique est pris en charge uniquement dans les sessions de mise en miroir de bases de données s'exécutant avec un témoin et 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 non disponible, le basculement automatique se produit. Lors d'un basculement automatique, le serveur miroir assume le rôle de serveur principal et met en ligne sa copie de la base de données en tant que base de données principale. Exiger la synchronisation de la base de données empêche toute perte de données lors du basculement, car chaque transaction validée sur la base de données principale est également validée sur la base de données miroir.

Pour que le basculement automatique améliore la fiabilité, les bases de données miroir et principale doivent résider sur des ordinateurs distincts.

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 Mise en miroir synchrone de bases de données (mode Haute sécurité).

  • La base de données miroir doit déjà être synchronisée. Ceci garantit que la totalité du journal envoyé au serveur miroir a été écrit sur le disque.

  • Le serveur principal a perdu la communication avec le reste de la configuration de mise en miroir de base de données, tandis que le serveur miroir et le serveur témoin conservent le quorum. Toutefois, si toutes les instances de serveur perdent la communication et si le serveur témoin et le serveur miroir rétablissent ultérieurement la communication, le basculement automatique n'a pas lieu.

    [!REMARQUE]

    Pour plus d'informations, consultez Quorum : effets d'un témoin sur la disponibilité de la base de données.

  • Le serveur miroir a détecté la perte du serveur principal.

    La manière dont le serveur miroir détecte une défaillance du serveur principal est variable, selon qu'il s'agisse d'une défaillance matérielle ou logicielle. Pour plus d'informations, consultez Défaillances possibles pendant la mise en miroir d'une base de données.

Fonctionnement du basculement automatique

Sous les conditions précédentes, le basculement automatique initialise la séquence d'actions suivante :

  1. Si le serveur principal fonctionne toujours, il change l'état de la base de données principale en DISCONNECTED et déconnecte tous les clients de la base de données principale.

  2. Les serveurs témoin et miroir détectent que le serveur principal n'est pas disponible.

  3. Si un journal est en attente dans la file d'attente de restauration par progression, le serveur miroir termine la restauration par progression de la base de données miroir.

    [!REMARQUE]

    Le temps nécessaire pour appliquer le journal dépend de la vitesse du système, de la charge de travail récente et de la quantité de journal au sein de la file d'attente de restauration par progression.

  4. L'ancienne base de données miroir passe 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 restaurant le plus rapidement possible. Des verrous isolent ces transactions.

  5. Lorsque l'ancien serveur principal rejoint la session, il détecte que son partenaire de basculement possède maintenant le rôle principal. L'ancien serveur principal prend le rôle de miroir, faisant de sa base de données la base de données en 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 est de nouveau possible, mais dans le sens inverse.

La figure suivante illustre une instance unique de basculement automatique.

Basculement automatique

Au départ, les trois serveurs sont connectés (la session bénéficie d'un quorum complet). Partner_A est le serveur principal, Partner_B le serveur miroir. Partner_A (ou la base de données principale sur Partner_A) devient non disponible. Le témoin et Partner_B détectent tous les deux que le serveur principal n'est plus disponible et la session conserve 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. Au besoin, Partner_A se reconnecte à la session et découvre que Partner_B possède maintenant le rôle principal. Partner_A prend alors 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 Connexions de clients à une base de données mise en miroir.

[!REMARQUE]

Les transactions qui ont été préparées à l'aide du service MSDTC (Microsoft Distributed Transaction Coordinator) mais qui ne sont toujours pas validées au moment du basculement, sont considérées comme abandonnées après le basculement de la base de données.

Désactivation du basculement automatique à l'aide de SQL Server Management Studio

Pour désactiver le basculement automatique, ouvrez la page Propriétés de la base de donnéesMise en miroir, puis changez de mode en sélectionnant l'une des options suivantes :

Pour changer le mode de fonctionnement

Désactivation du basculement automatique à l'aide de Transact-SQL

À n'importe quel moment d'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