Basculement manuel

Maintien de la disponibilité lors des mises à niveau

L'administrateur de base de données peut recourir au basculement manuel pour mettre du matériel ou des logiciels à niveau sans sacrifier la disponibilité. Pour utiliser la mise en miroir de base de données dans le cadre de mises à niveau logicielles, le serveur miroir et/ou le système doivent déjà avoir été mis à niveau.

L'illustration suivante montre une instance qui utilise le basculement manuel pour maintenir la disponibilité d'une base de données pendant la mise à niveau d'une instance serveur de base de données. Lorsque la mise à niveau est terminée, un administrateur peut éventuellement basculer à nouveau vers l'instance serveur d'origine. Ceci est utile lorsque l'administrateur veut arrêter la session de mise en miroir et utiliser le serveur de miroir ailleurs. De cette façon, une instance serveur donnée peut être utilisée à plusieurs reprises lors de la mise à jour d'une série d'instances serveur de base de données.

Conditions requises pour un basculement manuel

Le basculement manuel nécessite que la sécurité de transaction soit définie sur FULL (c'est-à-dire, mode haute sécurité). Lorsque les serveurs partenaires sont connectés et que la base de données est déjà synchronisée, le basculement manuel est pris en charge.

Fonctionnement du basculement manuel

Le basculement manuel initialise la série d'actions suivante :

1. Le serveur principal déconnecte les clients de la base de données principale, envoie la fin du journal au serveur miroir, puis définit l'état de la mise en miroir à SYNCHRONIZING pour se préparer à prendre le rôle miroir.

2. Le serveur miroir enregistre le numéro séquentiel dans le journal du dernier enregistrement journal reçu du serveur principal en tant que numéro séquentiel de basculement.

   [!REMARQUE]

   Pour afficher ce NSE, sélectionnez la colonne mirroring_failover_lsn de sys.database_mirroring (Transact-SQL).

3. Si un journal est en attente dans la file d'attente de restauration par progression, le serveur miroir achève la restauration par progression de la base de données miroir. Le temps requis pour cette opération 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. Dans le cadre d'un mode de fonctionnement synchrone, le temps de basculement peut être régulé en limitant la taille de la file d'attente de restauration par progression. Cependant, cela peut entraîner le serveur principal à ralentir pour permettre au serveur miroir de suivre.

   [!REMARQUE]

   Pour connaître la taille actuelle de la file d'attente de restauration par progression, utilisez le compteur de performance File d'attente de restauration par progression de l'objet de performance 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).

4. Le serveur miroir devient le nouveau serveur principal, et l'ancien serveur principal devient le nouveau serveur miroir.

5. Le nouveau serveur principal restaure toute transaction non validée et met la copie de sa base de données en ligne, en tant que base de données principale.

6. L'ancien serveur principal prend le rôle de 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 en sens inverse.

Après le basculement, les clients doivent se reconnecter à la base de données principale en cours. Pour plus d'informations, consultez Connexions de clients à une base de données mise en miroir.

Voir aussi

Concepts