Partager via

  • Article

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

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 ou 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 de serveur distinctes du moteur de base de données Moteur de base de données SQL Server. 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). L'autre instance agit comme un serveur de secours (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 haute sécurité ou hautes performances. Pour plus d'informations, consultez « Modes de fonctionnement », plus loin dans cette rubrique.

    Un serveur partenaire de mise en miroir de bases de données qui s'exécute sur SQL Server 2008 Enterprise ou versions ultérieures tente de résoudre automatiquement certains types d'erreurs qui empêchent la lecture d'une page de données. Un partenaire qui ne peut pas lire une page demande une copie actualisée à un autre partenaire. Si cette demande réussit, la page illisible est remplacée par la copie, ce qui permet généralement de résoudre l'erreur. Pour plus d'informations, consultez Réparation de page automatique pendant une session de mise en miroir de bases de données.

  • 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 le temps mort pour une base de données mise en miroir, vous pouvez mettre à niveau séquentiellement les instances de SQL Server qui participent à une session de mise en miroir de bases de données. Elle n'implique le temps mort que d'un basculement unique. Cette forme de mise à niveau s'appelle une mise à niveau propagée. Pour plus d'informations, consultez Procédure : installer un Service Pack sur un système avec un temps mort minimal pour les bases de données mises en miroir.

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

Le serveur principal et le serveur miroir communiquent et collaborent en tant que serveurs partenaires dans une session de mise en miroir de bases de données. Les deux serveurs partenaires jouent des rôles complémentaires dans la session : le rôle principal et le rôle de miroir. À tout moment, un partenaire détient le rôle principal, alors que l'autre partenaire détient le rôle miroir. Chaque serveur partenaire est décrit comme étant propriétaire de son rôle actif. Le serveur 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 serveur 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 un flux des enregistrements du journal de transactions actif vers le serveur miroir, ce qui applique les enregistrements du journal à la base de données miroir, en séquence, 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. À compter de SQL Server 2008, le serveur principal compresse le flux des enregistrements du journal de transactions avant de l'envoyer vers le serveur miroir. Cette compression de journal se produit dans toutes les sessions de mise en miroir.

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 est validée sur les deux serveurs 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. Dès que les bases de données sont synchronisées, une transaction est validée sur les deux serveurs 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. Toutefois, l'écart entre les bases de données est 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. Il n'attend pas 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. Cette configuration est illustrée dans la figure ci-dessous.

Serveurs 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 en charge le basculement automatique en vérifiant que le serveur principal est activé 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.

L'illustration 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.

[!REMARQUE]

L'établissement d'une nouvelle session de mise en miroir requiert que toutes les instances de serveur concernées exécutent la même version de SQL Server. Cependant, lorsque vous mettez à niveau vers SQL Server 2008, les versions des instances concernées peuvent varier. Pour plus d'informations, consultez Procédure : réduire le temps d'indisponibilité des bases de données mises en miroir lors de la mise à niveau d'instances de serveur.

Sécurité des transactions et modes de fonctionnement

Le fait qu'un mode de fonctionnement soit synchrone ou asynchrone dépend du paramétrage de la 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 serveurs 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, dès 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.

Interopérabilité et coexistence avec d'autres fonctionnalités de moteur de base de données

Vous pouvez utiliser la mise en miroir de bases de données avec les fonctionnalités ou les composants suivants de SQL Server.

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

Depuis SQL Server 2005 Service Pack 1 (SP1), les serveurs partenaires de mise en miroir de bases de données et les témoins sont pris en charge dans SQL Server Standard et SQL Server Enterprise. Toutefois, les serveurs partenaires doivent utiliser la même édition ; par ailleurs, la mise en miroir de bases de données asynchrone (mode hautes performances) est prise en charge uniquement dans SQL Server Enterprise. Les témoins sont également pris en charge dans SQL Server Workgroup et SQL Server Express.