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

Mis à jour : 14 avril 2006

La mise en miroir de bases de données fournit un service forcé (avec possibilité de perte de données) en guise de méthode de récupération d'urgence afin de vous permettre d'utiliser un serveur miroir en tant que serveur de secours semi-automatique. Le service forcé est possible uniquement si le serveur principal est déconnecté du serveur miroir lors d'une session de mise en miroir. Le service forcé entraînant un risque de perte de données, il convient de l'utiliser avec prudence et parcimonie.

La prise en charge du service forcé dépend du mode de fonctionnement et de l'état de la session, comme suit :

• En général, le mode hautes performances prend en charge le service forcé lorsque le serveur principal est déconnecté. Cependant, et bien que cela ne soit pas obligatoire, un témoin peut exister pour une session en mode hautes performances. Dans ce cas, le service forcé exige que le serveur miroir et le témoin soient interconnectés.
• Le mode haute sécurité avec basculement automatique prend en charge le service forcé lorsque le serveur principal est déconnecté.
• Le mode haute sécurité avec basculement automatique prend en charge le service forcé lorsque le serveur miroir et le témoin sont interconnectés et que ni l'un ni l'autre n'est connecté au serveur principal (tant que le serveur miroir n'était pas en train de restaurer la base de données miroir lorsqu'il était encore connecté au serveur principal).

Nous recommandons de forcer le service uniquement si vous devez restaurer immédiatement le service sur la base de données et que vous êtes prêt à courir le risque de perdre des données. Le service forcé a un effet semblable à la suppression de la mise en miroir, hormis le fait qu'il facilite la resynchronisation des bases de données lors du rétablissement de la mise en miroir, au risque de perdre des données. Le service forcé effectue une transition régulière du rôle principal vers la base de données miroir. Le serveur miroir joue le rôle de serveur principal et met immédiatement à la disposition des clients sa copie de la base de données. La nouvelle base de données principale s'exécute sans miroir (autrement dit, elle est exposée).

Important :

Si le serveur principal a simplement été déconnecté de la session de mise en miroir de bases de données et qu'il est encore en cours d'exécution, certains clients peuvent continuer d'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. Autrement, une fois le service forcé, la base de données principale d'origine et la base de données principale actuelle risquent d'être mises à jour indépendamment l'une de l'autre.

Cas ordinaire de service forcé

L'illustration suivante présente un cas ordinaire de service forcé (avec possibilité de perte de données).

Comme l'indique l'illustration, 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 s'être assuré que Partner_A était inaccessible aux clients, l'administrateur de la base de données force le service, avec possibilité de perte de données, sur Partner_B. Partner_B devient le serveur principal et s'exécute avec la base de données exposée (c'est-à-dire, non mise en miroir). À ce stade, les clients peuvent se reconnecter à Partner_B.

Lorsque Partner_A devient disponible, il se reconnecte au serveur principal, rejoint la session et assume le rôle de miroir. La session de mise en miroir est suspendue immédiatement, sans que la nouvelle base de données miroir ait été synchronisée. 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 des 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 assume le rôle de serveur miroir et restaure l'ancienne base de données principale au point dans le temps correspondant à la dernière transaction synchronisée avec succès ; si des transactions validées n'ont pas été écrites sur disque sur le serveur miroir avant que le forçage du service, elles sont perdues. Partner_A restaure ensuite par progression la nouvelle base de données miroir en appliquant les modifications apportées à 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 n'ait pas besoin de témoin, si un témoin est configuré, il est possible de forcer le service seulement si le témoin est connecté au serveur miroir.

Risques posés par le 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 la synchronisation des deux bases de données. Le service forcé démarre un nouveau point de branchement de récupération. Étant donné que la base de données principale et la base de données miroir d'origine sont situées sur différents branchements de récupération, chaque base de données contient maintenant des données qui ne figurent pas dans l'autre base de données : la base de données principale d'origine contient toutes les modifications qui n'avaient 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 toutes les modifications qui surviennent une fois le service forcé.

Remarque :
Pour plus d'informations sur les branchements de récupération, consultez Chemins de récupération.

Si le service est forcé suite à une défaillance du serveur principal, le risque de perte de données dépend du fait que les journaux de transactions ont été envoyés ou non au serveur miroir avant la défaillance. En mode haute sécurité, cela est possible uniquement jusqu'à ce que la base de données miroir soit synchronisée. En mode hautes performances, une accumulation du journal non envoyé est toujours une possibilité.

Les implications du service forcé dépendent en partie de la présence d'un témoin dans la session :

• En l'absence de témoin, le service peut être forcé si les partenaires sont déconnectés, par exemple en raison d'une rupture de leur connexion réseau. Si le serveur principal d'origine est encore en cours d'exécution, les deux partenaires détiennent le rôle principal. Les clients qui se connectent au nouveau serveur principal accèderont à la version actuelle de la base de données, alors que les clients qui se connectent au serveur principal d'origine accèderont à la base de données principale d'origine. Cette situation accroît le risque de perte de données. Si les partenaires sont autorisés à se reconnecter, le serveur principal d'origine assume le rôle de miroir et modifie l'état de sa base de données en « récupération » avant que la mise en miroir soit suspendue. Si la session reprend, les transactions de la base de données principale d'origine dont le journal se trouvait dans la file d'attente d'envoi lors de la déconnexion la plus récente sont perdues. En outre, toutes les transactions qui ont eu lieu après le forçage du service sont également perdues.
• En présence d'un témoin, si le serveur miroir est déconnecté du serveur principal et du témoin, le serveur principal demeure exposé tant qu'il est connecté au témoin. Si le serveur principal est ensuite déconnecté du témoin, il ne sert plus 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 que le serveur principal d'origine s'exécutait en situation exposée seront 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

Après le forçage du service, une fois l'ancien serveur principal disponible, en supposant que sa base de données ne soit pas endommagée, vous pouvez tenter de gérer la perte de données potentielle. La méthode disponible pour gérer la perte de données potentielle dépend selon que le serveur principal d'origine s'est reconnecté à son partenaire et a rejoint la session de mise en miroir. En supposant que le serveur principal d'origine puisse accéder à la nouvelle instance principale, la reconnexion se produit automatiquement et de manière transparente.

Le serveur principal d'origine s'est reconnecté

En général, 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 passe à l'état de récupération avant que la session soit suspendue. La base de données miroir ne sera restaurée que si vous rétablissez 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 afin d'évaluer les données qui seraient perdues si vous rétablissiez la mise en miroir. La décision relative à la reprise ou à la suppression de la mise en miroir dépend donc selon que vous souhaitez accepter ou non le risque de perte de données.

• Si la perte de données est inacceptable, vous devez supprimer la mise en miroir afin de récupérer les données.
  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 passera en ligne, les anciens partenaires serviront 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 inaccessible aux clients afin d'éviter toute divergence supplémentaire de la base de données et tout problème de basculement de client.
• Si la perte de données est acceptable, vous pouvez reprendre la mise en miroir.
  La reprise de la mise en miroir entraîne la restauration de la nouvelle base de données miroir en guise de première étape vers 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 ne s'est pas reconnecté

Si vous pouvez empêcher momentanément le serveur principal d'origine de se reconnecter par le biais du réseau au nouveau serveur principal, vous pouvez inspecter la base de données principale d'origine afin d'évaluer les données qui seraient perdues si vous rétablissiez la mise en miroir.

• Si la perte de données potentielle est acceptable
  Laissez le serveur principal d'origine se reconnecter à son partenaire. La reconnexion provoque la suspension de la mise en miroir. Pour rétablir la mise en miroir, il vous suffit de reprendre la session. L'ancien serveur principal assume le rôle de miroir. Le nouveau serveur miroir supprime le branchement de récupération d'origine, ce qui entraîne la perte des transactions qui n'ont été ni reçues ni envoyées 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 essentielles qui seront perdues si vous reprenez la session, vous pouvez préserver les données sur le serveur principal d'origine en supprimant la mise en miroir. Nous vous recommandons d'essayer de sauvegarder la fin du journal du serveur principal à ce stade. Ensuite, vous pouvez mettre à jour la base de données principale actuelle (l'ancienne base de données miroir) en exportant les données que vous souhaitez sauvegarder à partir de la base de données principale d'origine et en les important dans la base de données principale actuelle. Nous vous recommandons d'effectuer aussi rapidement que possible une sauvegarde complète de base de données de la base de données mise à jour.
  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 du journal ultérieure) pour créer une nouvelle 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 recommandons de différer les sauvegardes de journal supplémentaires de la base de données principale jusqu'à ce que la nouvelle session de mise en miroir démarre.

Pour forcer le service

• Procédure : basculement forcé dans une session de mise en miroir de bases de données (Transact-SQL).

Pour reprendre la mise en miroir de bases de données

• Procédure : Suspendre ou reprendre une session de mise en miroir de bases de données (SQL Server Management Studio)
• Procédure : reprendre une session de mise en miroir de bases de données (Transact-SQL)

Pour créer une nouvelle base de données miroir

Procédure : préparer une base de données miroir pour la mise en miroir (Transact-SQL)

Pour démarrer la mise en miroir de bases de données

• Configuration de la mise en miroir d'une base de données
• Procédure : configurer une session de mise en miroir de base de données (SQL Server Management Studio)

Voir aussi

Concepts

Mise en miroir asynchrone de bases de données (mode hautes performances)
Estimation de l'interruption de service au cours d'un basculement de rôle
États de la mise en miroir
Exécution d'une restauration de base de données complète (mode de restauration complète)
Défaillances possibles pendant la mise en miroir d'une base de données
Chemins de récupération
Mise en miroir synchrone de bases de données (mode Haute sécurité)

Autres ressources

Connexions de clients à une base de données mise en miroir

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version	Historique
14 avril 2006	Nouveau contenu : Développement de l'explication relative au risque de perte de données. Ajout d'informations concernant le risque lié au forçage du service alors que le serveur principal d'origine a perdu sa connexion à la session mais est encore en cours d'exécution.