Présentation de la mise en miroir de bases de données

Article
12/15/2008

Mis à jour : 5 décembre 2005

La mise en miroir de bases de données est essentiellement une solution logicielle permettant d'accroître la disponibilité d'une base de données. La mise en miroir est implémentée individuellement pour chaque base de données et fonctionne uniquement avec les bases de données qui utilisent le mode de restauration complète. Les modes de récupération simple et utilisant les journaux de transactions ne prennent pas en charge la mise en miroir. Par conséquent, toutes les opérations en bloc sont entièrement journalisées. La mise en miroir de bases de données fonctionne avec tout niveau de compatibilité de base de données pris en charge.

Remarque :
Vous ne pouvez pas mettre en miroir les bases de données master, msdb, tempdb et model.

La mise en miroir de bases de données conserve deux exemplaires d'une même base de données qui doivent résider sur des instances distinctes du moteur de base de données SQL Server (instances de serveur). En règle générale, ces instances de serveur résident sur des ordinateurs dans des emplacements distincts. Une instance de serveur sert la base de données aux clients (le serveur principal), tandis que l'autre instance de serveur agit comme serveur de secours automatique ou semi-automatique (le serveur miroir), selon la configuration et l'état de la session de mise en miroir. Lorsqu'une session de mise en miroir de bases de données est synchronisée, la mise en miroir de bases de données procure un serveur de secours automatique qui prend en charge le basculement rapide sans perte de données des transactions validées. Lorsque la session n'est pas synchronisée, le serveur miroir est généralement disponible en tant que serveur de secours semi-automatique (avec une perte de données possible).

Avantages de la mise en miroir de bases de données

La mise en miroir de bases de données est une stratégie simple qui présente les avantages suivants :

Elle augmente la protection des données.
La mise en miroir de bases de données procure une redondance des données complète ou presque complète, selon que le mode de fonctionnement est le mode haute sécurité ou hautes performances. Pour plus d'informations, consultez « Modes de fonctionnement », plus loin dans cette rubrique.
Elle augmente la disponibilité d'une base de données.
En cas de sinistre, en mode haute sécurité avec basculement automatique, le basculement met rapidement en ligne la copie de secours de la base de données (sans perte de données). Dans les autres modes de fonctionnement, l'administrateur de base de données peut opter pour le service forcé (avec perte de données possible) de la copie de secours de la base de données. Pour plus d'informations, consultez « Basculement de rôle », plus loin dans cette rubrique.
Elle augmente la disponibilité de la base de données de production au cours des mises à niveau.
Pour réduire au maximum le temps mort d'une base de données mise en miroir, vous pouvez mettre à niveau en séquence les instances de SQL Server qui participent à une session de mise en miroir de bases de données, ce qui permet de réduire le temps mort à un seul basculement. Cette forme de mise à niveau est appelée mise à niveau propagée. Pour plus d'informations, consultez Procédure : installer un Service Pack sur un système avec temps mort minimal pour les bases de données en miroir.

Fonctionnement de la mise en miroir de bases de données

Les serveurs principal et miroir communiquent et collaborent en tant que partenaires dans une session de mise en miroir de bases de données. Les deux partenaires remplissent des rôles complémentaires dans la session : le rôle principal et le rôle miroir. À tout moment, un partenaire détient le rôle principal, alors que l'autre partenaire détient le rôle miroir. Chaque partenaire est décrit comme étant propriétaire de son rôle actif. Le partenaire qui possède le rôle principal est appelé serveur principal, et sa copie de la base de données est la base de données principale active. Le partenaire qui possède le rôle miroir est appelé serveur miroir, et sa copie de la base de données est la base de données miroir active. Lors du déploiement de la mise en miroir de bases de données dans un environnement de production, la base de données principale correspond à la base de données de production.

La mise en miroir de bases de données implique la répétition de chaque opération d'insertion, de mise à jour et de suppression effectuée sur la base de données principale aussi rapidement que possible sur la base de données miroir. Cette répétition est accomplie en envoyant chaque enregistrement du journal des transactions actif vers le serveur miroir, ce qui applique les enregistrements du journal à la base de données miroir, dans l'ordre, aussi rapidement que possible. Contrairement à la réplication, qui fonctionne au niveau logique, la mise en miroir de bases de données fonctionne au niveau de l'enregistrement du journal physique.

Modes de fonctionnement

Une session de mise en miroir de bases de données s'exécute de manière synchrone ou asynchrone. En fonctionnement asynchrone, les transactions sont validées sans attendre que le serveur miroir enregistre le journal sur le disque, ce qui augmente au maximum les performances. En fonctionnement synchrone, une transaction validée est validée sur les deux partenaires, mais au prix d'une latence accrue des transactions.

Il existe deux modes de fonctionnement de la mise en miroir. L'un d'entre eux, le mode haute sécurité, prend en charge le fonctionnement synchrone. En mode haute sécurité, lorsqu'une session démarre, le serveur miroir synchronise la base de données miroir avec la base de données principale le plus rapidement possible. Une fois les bases de données synchronisées, une transaction validée est validée sur les deux partenaires, mais au prix d'une latence accrue des transactions.

Le deuxième mode de fonctionnement, le mode hautes performances, s'exécute de manière asynchrone. Le serveur miroir tente de rester à jour par rapport aux enregistrements de journal envoyés par le serveur principal. La base de données miroir peut rester quelque peu en arrière de la base de données principale, bien que l'écart entre les bases de données soit faible en général. Cependant, cet écart peut devenir important si le serveur principal est soumis à une charge de travail considérable ou si le système du serveur miroir est surchargé.

En mode hautes performances, dès que le serveur principal envoie un enregistrement du journal au serveur miroir, le serveur principal envoie une confirmation au client, sans attendre d'accusé de réception du serveur miroir. Cela signifie que les transactions sont validées sans attendre que le serveur miroir enregistre le journal sur le disque. Ce fonctionnement asynchrone permet au serveur principal de s'exécuter avec une latence de transaction minimale, au risque de perdre des données.

Toutes les sessions de mise en miroir de bases de données prennent en charge un seul serveur principal et un seul serveur miroir. La figure ci-dessous illustre cette configuration.

Partenaires dans une session de mise en miroir de bases de données

Le mode haute sécurité avec basculement automatique requiert une troisième instance de serveur, appelée témoin. Contrairement aux deux autres, le témoin ne dessert pas la base de données. Le témoin prend simplement en charge le basculement automatique en vérifiant que le serveur principal a été démarré et qu'il fonctionne. Le serveur miroir déclenche le basculement automatique uniquement si le miroir et le témoin demeurent connectés l'un à l'autre après que tous deux ont été déconnectés du serveur principal.

La figure ci-dessous montre une configuration incluant un témoin.

Session de mise en miroir incluant un témoin

Pour plus d'informations, consultez « Basculement de rôle », plus loin dans cette rubrique.

Sécurité des transactions et modes d'opération

Le fait qu'un mode d'opération soit synchrone ou asynchrone dépend du paramètre de sécurité des transactions. Si vous utilisez exclusivement SQL Server Management Studio pour configurer la mise en miroir de bases de données, les paramètres de sécurité des transactions sont configurés automatiquement lorsque vous sélectionnez le mode de fonctionnement.

Si vous utilisez Transact-SQL pour configurer la mise en miroir de bases de données, vous devez comprendre comment définir la sécurité des transactions. La sécurité des transactions est contrôlée par la propriété SAFETY de l'instruction ALTER DATABASE. Sur une base de données dont la mise en miroir est en cours, SAFETY a la valeur FULL ou OFF.

Si l'option SAFETY a la valeur FULL, l'opération de mise en miroir de bases de données est synchrone après la phase de synchronisation initiale. Si un témoin fonctionne en mode haute sécurité, la session prend en charge le basculement automatique.
Si l'option SAFETY a la valeur OFF, l'opération de mise en miroir de bases de données est asynchrone. La session s'exécute en mode hautes performances et l'option WITNESS doit également avoir la valeur OFF.

Pour plus d'informations, consultez Paramètres Transact-SQL et modes d'opération de mise en miroir de bases de données.

Basculement de rôle

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. Le basculement de rôle implique le transfert du rôle principal au serveur miroir. Lors du basculement de rôle, le serveur miroir agit en tant que partenaire de basculement pour le serveur principal. Lorsqu'un basculement automatique se produit, le serveur miroir adopte le rôle principal et met en ligne sa copie de la base de données en tant que nouvelle base de données principale. L'ancien serveur principal, s'il est disponible, adopte le rôle de serveur miroir, et sa base de données devient la nouvelle base de données miroir. Il est possible de procéder à plusieurs basculements de rôles.

Il existe trois types de basculement de rôle :

Basculement automatique
Ce type requiert le mode haute sécurité et la présence du serveur miroir et d'un témoin. La base de données doit déjà être synchronisée et le témoin doit être connecté au serveur miroir.
Le rôle du témoin consiste à vérifier si un serveur partenaire donné fonctionne correctement. Si le serveur miroir perd sa connexion au serveur principal, mais que le témoin est toujours connecté au serveur principal, le serveur miroir ne lance pas de basculement. Pour plus d'informations, consultez Témoin de mise en miroir de base de données.
Basculement manuel
Ce type requiert le mode haute sécurité. Les partenaires doivent être connectés entre eux et la base de données doit déjà être synchronisée.

Service forcé (avec perte de données possible)
En mode hautes performances et en mode haute sécurité avec basculement automatique, le service forcé est possible si le serveur principal connaît une défaillance et que le serveur miroir est disponible.

Important :
Le mode hautes performances a été conçu pour s'exécuter sans témoin. Toutefois, si un témoin existe, le service forcé exige que le témoin soit connecté au serveur miroir.

Dans tout scénario de basculement de rôle, une fois que la nouvelle base de données principale est en ligne, les applications clientes peuvent être récupérées rapidement en se reconnectant à la base de données.

Prise en charge de la mise en miroir de bases de données

Les serveurs partenaires de mise en miroir de bases de données et les serveurs témoins sont pris en charge par SQL Server 2005 Standard Edition SP1 et versions ultérieures et par SQL Server 2005 Enterprise Edition SP1 et versions ultérieures. En revanche, les partenaires doivent utiliser la même édition et la mise en miroir asynchrone de bases de données (mode hautes performances) est prise en charge uniquement par SQL Server 2005 Enterprise Edition et versions ultérieures. Les témoins sont également pris en charge par SQL Server 2005 Workgroup Edition SP1 et versions ultérieures et par SQL Server 2005 Express Edition SP1 et versions ultérieures.

Rubriques associées à la mise en miroir de bases de données

Voir aussi

Autres ressources

Connexions de clients à une base de données mise en miroir
Mise en miroir de bases de données et autres fonctionnalités et composants
sp_dbcmptlevel (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005

Partager via