Partager via

Mise en miroir de bases de données (SQL Server)

Remarque

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez Always On groupes de disponibilité à la place.

La mise en miroir de bases de données est une solution permettant d’augmenter la disponibilité d’une base de données SQL Server. 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.

Important

Pour plus d’informations sur la prise en charge de la mise en miroir de bases de données, des restrictions, des conditions préalables, des recommandations pour la configuration des serveurs partenaires et des recommandations pour le déploiement de la mise en miroir de bases de données, consultez Conditions préalables, restrictions et recommandations pour la mise en miroir de bases de données.

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 offre les avantages suivants :

  • Augmente la disponibilité d’une base de données.

    En cas de sinistre, en mode haute sécurité avec basculement automatique, le basculement apporte rapidement la copie de secours de la base de données en ligne (sans perte de données). Dans les autres modes d’exploitation, l’administrateur de base de données a l’alternative de forcer le service (avec perte de données possible) à la copie de secours de la base de données. Pour plus d’informations, consultez Changement de rôle, plus loin dans cette rubrique.

  • Augmente la protection des données.

    La mise en miroir de bases de données fournit une redondance complète ou presque complète des données, selon que le mode d’exploitation est haute sécurité ou hautes performances. Pour plus d’informations, consultez Modes d’exploitation, plus loin dans cette rubrique.

    Un partenaire de mise en miroir de bases de données s’exécutant sur SQL Server 2008 Enterprise ou version ultérieure tente automatiquement de résoudre certains types d’erreurs qui empêchent la lecture d’une page de données. Le partenaire qui ne parvient pas à lire une page demande une nouvelle copie de l’autre partenaire. Si cette demande aboutit, 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 La réparation automatique des pages (pour les groupes de disponibilité et la mise en miroir de bases de données)

  • Améliore la disponibilité de la base de données de production pendant les mises à niveau.

    Pour réduire le temps d’arrêt d’une base de données mise en miroir, vous pouvez mettre à niveau séquentiellement les instances de SQL Server qui hébergent les partenaires de basculement. Cela entraîne le temps d’arrêt d’un seul basculement. Cette forme de mise à niveau est appelée mise à niveau propagée. Pour plus d’informations, consultez Installer un Service Pack sur un système avec un temps d’arrêt minimal pour les bases de données mises en miroir.

Termes et définitions de mise en miroir de bases de données

basculement automatique
Processus par lequel, lorsque le serveur principal devient indisponible, le serveur miroir doit assumer le rôle du serveur principal et apporter sa copie de la base de données en ligne en tant que base de données principale.

partenaires de basculement
Les deux instances de serveur (le serveur principal ou le serveur miroir) qui agissent en tant que partenaires de basculement de rôle pour une base de données mise en miroir.

service forcé
Basculement initié par le propriétaire de la base de données lorsque le serveur principal échoue, transférant le service à la base de données miroir lorsqu'elle est dans un état inconnu.

Mode hautes performances
La session de mise en miroir de bases de données fonctionne de manière asynchrone et utilise uniquement le serveur principal et le serveur miroir. La seule forme de basculement de rôle est le service forcé (avec perte de données possible).

Mode haute sécurité
La session de mise en miroir de bases de données fonctionne de manière synchrone et, éventuellement, utilise un témoin, ainsi que le serveur principal et le serveur miroir.

basculement manuel
Basculement initié par le propriétaire de la base de données, alors que le serveur principal est toujours en cours d’exécution, qui transfère le service de la base de données principale à la base de données miroir pendant qu’il est dans un état synchronisé.

base de données miroir
Copie de la base de données qui est généralement entièrement synchronisée avec la base de données principale.

serveur miroir
Dans une configuration de mise en miroir de bases de données, l’instance de serveur sur laquelle réside la base de données miroir.

serveur miroir
Dans une configuration de mise en miroir de bases de données, l’instance de serveur sur laquelle réside la base de données miroir.

base de données principale
Dans la mise en miroir de bases de données, une base de données en lecture-écriture dont les enregistrements du journal des transactions sont appliqués à une copie en lecture seule de la base de données (une base de données miroir).

serveur principal
Dans la mise en miroir de bases de données, le partenaire dont la base de données est actuellement la base de données principale.

File d'attente de réexécution
Enregistrements du journal des transactions reçus qui attendent sur le disque d’un serveur miroir.

rôle
Le serveur principal et le serveur miroir effectuent des rôles de principal et de miroir complémentaires. Si vous le souhaitez, le rôle de témoin est effectué par une troisième instance de serveur.

changement de rôle
Prise en charge du rôle principal par le miroir.

envoyer une file d’attente
Enregistrements non envoyés du journal des transactions qui se sont accumulés sur le disque du journal du serveur principal.

séance
Relation qui se produit pendant la mise en miroir de bases de données entre le serveur principal, le serveur miroir et le serveur témoin (le cas échéant).

Une fois qu’une session de mise en miroir démarre ou reprend, le processus par lequel les enregistrements de journal de la base de données principale qui ont été accumulés sur le serveur principal sont envoyés au serveur miroir, qui écrit ces enregistrements de journal sur le disque le plus rapidement possible pour rattraper le serveur principal.

Sécurité des transactions
Propriété de base de données spécifique à la mise en miroir qui détermine si une session de mise en miroir de bases de données fonctionne de manière synchrone ou asynchrone. Il existe deux niveaux de sécurité : FULL et OFF.

Témoin
Utilisable uniquement avec le mode haute sécurité, une instance facultative de SQL Server permet au serveur miroir de déterminer quand initier un basculement automatique. Contrairement aux deux partenaires de basculement, le témoin ne sert pas la base de données. Le témoin n'a pour seul rôle que de soutenir le basculement automatique.

Vue d’ensemble de la mise en miroir de bases de données

La mise en miroir de bases de données conserve deux copies d’une base de données unique qui doit résider sur différentes instances de serveur du moteur de base de données SQL Server. En règle générale, ces instances de serveur résident sur des ordinateurs à différents emplacements. Le démarrage de la mise en miroir de bases de données sur une base de données lance une relation, appelée session de mise en miroir de bases de données, entre ces instances de serveur.

Une instance de serveur sert la base de données aux clients (le serveur principal). L’autre instance agit comme un serveur de secours chaud ou chaud (le serveur miroir), en fonction de la configuration et de 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 fournit un serveur de secours à chaud qui prend en charge le basculement rapide sans perte de données provenant de 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 chaud (avec perte de données possible).

Les serveurs principaux et miroirs communiquent et collaborent en tant que partenaires dans une session de mise en miroir de bases de données. Les deux partenaires effectuent des rôles complémentaires dans la session : le rôle principal et le rôle miroir. À tout moment, un partenaire joue le rôle principal et l’autre partenaire joue le rôle miroir. Chaque partenaire est décrit comme possédant son rôle actuel. Le partenaire propriétaire du rôle principal est appelé serveur principal, et sa copie de la base de données est la base de données principale actuelle. Le partenaire propriétaire du rôle miroir est appelé serveur miroir, et sa copie de la base de données est la base de données miroir actuelle. Lorsque la mise en miroir de bases de données est déployée dans un environnement de production, la base de données principale est la base de données de production.

La mise en miroir de bases de données implique de rétablir chaque opération d’insertion, de mise à jour et de suppression qui se produit sur la base de données principale dans la base de données miroir le plus rapidement possible. La réexécution est effectuée en envoyant un flux d’enregistrements de journal des transactions actifs au serveur miroir, qui applique les enregistrements de 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 de journal physique. À compter de SQL Server 2008, le serveur principal compresse le flux d’enregistrements du journal des transactions avant de l’envoyer au serveur miroir. Cette compression de journal se produit dans toutes les sessions de mise en miroir.

Remarque

Une instance de serveur donnée peut participer à plusieurs sessions de mise en miroir de bases de données simultanées avec les mêmes partenaires ou différents. Une instance de serveur peut être un partenaire dans certaines sessions et un témoin dans d’autres sessions. L’instance de serveur miroir doit exécuter la même édition de SQL Server.

Modes de fonctionnement

Une session de mise en miroir de bases de données s’exécute avec une opération synchrone ou asynchrone. En mode asynchrone, les transactions sont validées sans attendre que le serveur miroir écrive le journal sur le disque, ce qui optimise les performances. En cas d’opération synchrone, une transaction est validée sur les deux partenaires, mais au coût d’une latence de transaction accrue.

[!REMARQUE] Il existe deux modes de fonctionnement de la mise en miroir. L’un d’eux, le mode haute sécurité prend en charge l’opération synchrone. En mode haute sécurité, quand 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 d’exploitation, 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 être un peu en retard par rapport à la base de données principale. Toutefois, l'écart entre les bases de données est faible en général. Toutefois, l’écart peut devenir significatif si le serveur principal est sous une charge de travail importante ou si le système du serveur miroir est surchargé.

En mode hautes performances, dès que le serveur principal envoie un enregistrement de journal au serveur miroir, le serveur principal envoie une confirmation au client. Il n’attend pas un accusé de réception du serveur miroir. Cela signifie que les transactions sont validées sans attendre que le serveur miroir écrive le journal sur le disque. Cette opération asynchrone permet au serveur principal de s’exécuter avec une latence de transaction minimale, au risque potentiel d’une perte de données.

Toutes les sessions de mise en miroir de bases de données ne prennent en charge qu’un seul serveur principal et un seul serveur miroir. Cette configuration est illustrée dans l’illustration suivante.

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

Le mode haute sécurité avec basculement automatique nécessite une troisième instance de serveur, appelée témoin. Contrairement aux deux partenaires, le témoin ne sert pas la base de données. Le témoin assure le basculement automatique en vérifiant si le serveur principal est en fonctionnement. Le serveur miroir lance le basculement automatique uniquement si le miroir et le témoin restent connectés les uns aux autres après avoir été déconnectés du serveur principal.

L’illustration suivante montre une configuration qui inclut un témoin.

Session de mise en miroir qui inclut un témoin

Pour plus d’informations, consultez Changement de rôle, plus loin dans cette rubrique.

Remarque

L’établissement d’une nouvelle session de mise en miroir ou l’ajout d’un témoin à une configuration de mise en miroir existante nécessite que toutes les instances de serveur impliquées exécutent la même version de SQL Server. Toutefois, lorsque vous effectuez une mise à niveau vers SQL Server 2008 ou une version ultérieure, les versions des instances impliquées peuvent varier. Pour plus d’informations, consultez Réduire les temps d’arrêt pour les bases de données mises en miroir lors de la mise à niveau des instances de serveur.

Sécurité des transactions et modes d’exploitation

Si un mode d’exploitation est asynchrone ou synchrone 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 d’opération.

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 en cours de mise en miroir, la configuration de sécurité est soit complète soit désactivée.

  • Si l’option SAFETY est définie sur 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 est configuré en mode de sécurité élevée, la session prend en charge le basculement automatique.

  • Si l’option SAFETY est définie sur 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 être DÉSACTIVÉE.

Pour plus d’informations, consultez Modes d’exploitation 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, les rôles principal et miroir sont généralement interchangeables dans un processus appelé basculement de rôle. Le basculement de rôle implique le transfert du rôle principal vers le serveur miroir. Dans le changement de rôle, le serveur miroir agit comme partenaire de basculement pour le serveur principal. Lorsqu’un changement de rôle se produit, le serveur miroir assume 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, assume le rôle miroir et sa base de données devient la nouvelle base de données miroir. Potentiellement, les rôles peuvent basculer à plusieurs reprises.

Les trois formes suivantes de changement de rôle existent.

  • Basculement automatique

    Cela nécessite un 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 est de vérifier si un serveur partenaire donné est opérationnel. 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 bases de données.

  • Basculement manuel

    Cela nécessite un mode haute sécurité. Les partenaires doivent être connectés les uns aux autres, 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é sans basculement automatique, le service forcé est possible si le serveur principal a échoué et que le serveur miroir est disponible.

    Important

    Le mode hautes performances est destiné à 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 n’importe quel scénario de basculement de rôle, dès que la nouvelle base de données principale est en ligne, les applications clientes peuvent récupérer rapidement en se reconnectant à la base de données.

Sessions simultanées

Une instance de serveur donnée peut participer à plusieurs sessions de mise en miroir de bases de données simultanées (une fois par base de données mise en miroir) avec les mêmes instances de serveur ou différentes. Souvent, une instance de serveur sert exclusivement de partenaire ou de témoin dans toutes ses sessions de mise en miroir de bases de données. Toutefois, étant donné que chaque session est indépendante des autres sessions, une instance de serveur peut agir en tant que partenaire dans certaines sessions et en tant que témoin dans d’autres sessions. Par exemple, tenez compte des quatre sessions suivantes parmi trois instances de serveur (SSInstance_1, SSInstance_2et SSInstance_3). Chaque instance de serveur sert de partenaire dans certaines sessions et en tant que témoin dans d’autres :

Instance de serveur Session pour la base de données A Session pour la base de données B Session pour la base de données C Session pour la base de données D
SSInstance_1 Témoin Partenaire Partenaire Partenaire
SSInstance_2 Partenaire Témoin Partenaire Partenaire
SSInstance_3 Partenaire Partenaire Témoin Témoin

La figure suivante illustre deux instances de serveur qui participent en tant que partenaires ensemble dans deux sessions de mise en miroir. Une session concerne une base de données nommée Db_1, et l’autre session concerne une base de données nommée Db_2.

Deux instances de serveur dans deux sessions simultanées

Chacune des bases de données est indépendante des autres. Par exemple, une instance de serveur peut être initialement le serveur miroir pour deux bases de données. Si l’une de ces bases de données bascule, l’instance de serveur devient le serveur principal de la base de données basculée tout en restant le serveur miroir de l’autre base de données.

Comme autre exemple, considérez une instance de serveur qui est le serveur principal pour deux bases de données ou plus exécutées en mode haute sécurité avec basculement automatique, si l’instance de serveur échoue, toutes les bases de données basculent automatiquement vers leurs bases de données miroir respectives.

Lors de la configuration d’une instance de serveur pour fonctionner à la fois en tant que partenaire et témoin, assurez-vous que le point de terminaison de mise en miroir de bases de données prend en charge les deux rôles (pour plus d’informations, consultez Le point de terminaison de mise en miroir de bases de données (SQL Server)). Vérifiez également que le système dispose de ressources suffisantes pour réduire la contention des ressources.

Remarque

Étant donné que les bases de données mises en miroir sont indépendantes les unes des autres, elles ne peuvent pas basculer en tant que groupe.

Connexions clientes

La prise en charge de la connexion client pour les sessions de mise en miroir de bases de données est fournie par le fournisseur de données Microsoft .NET pour SQL Server. Pour plus d’informations, consultez Connecter des clients à une session de mise en miroir de bases de données (SQL Server).

Impact de la suspension d’une session sur le journal des transactions du principal

À tout moment, le propriétaire de la base de données peut suspendre une session. La pause conserve l’état de session tout en supprimant la mise en miroir. Lorsqu’une session est suspendue, le serveur principal n’envoie aucun nouvel enregistrement de journal au serveur miroir. Tous ces enregistrements restent actifs et s’accumulent dans le journal des transactions de la base de données principale. Tant qu’une session de mise en miroir de bases de données reste suspendue, le journal des transactions ne peut pas être tronqué. Par conséquent, si la session de mise en miroir de bases de données est suspendue pendant trop longtemps, le journal peut se remplir.

Pour plus d’informations, consultez Suspension et reprise de la mise en miroir de bases de données (SQL Server).

Configuration de la session de mise en miroir de bases de données

Avant qu’une session de mise en miroir puisse commencer, le propriétaire de la base de données ou l’administrateur système doit créer la base de données miroir, configurer des points de terminaison et des connexions, et, dans certains cas, créer et configurer des certificats. Pour plus d’informations, consultez Configuration de la mise en miroir de bases de données (SQL Server).

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

La mise en miroir de bases de données peut être utilisée avec les fonctionnalités ou composants suivants de SQL Server.

Dans cette section

Conditions préalables, restrictions et recommandations pour la mise en miroir de bases de données
Décrit les conditions préalables et les recommandations pour la configuration de la mise en miroir de bases de données.

Modes de fonctionnement de la mise en miroir de bases de données
Contient des informations sur les modes d’exploitation synchrones et asynchrones des sessions de mise en miroir de bases de données et sur le changement de rôles de partenaire pendant une session de mise en miroir de bases de données.

Témoin de la mise en miroir de bases de données
Décrit le rôle d’un témoin dans la mise en miroir de bases de données, comment utiliser un témoin unique dans plusieurs sessions de mise en miroir, des recommandations logicielles et matérielles pour les témoins et le rôle du témoin dans le basculement automatique. Il contient également des informations sur l’ajout ou la suppression d’un témoin.

Basculement de rôle durant une session de mise en miroir de bases de données (SQL Server)
Contient des informations sur le changement des rôles de partenaire pendant une session de mise en miroir de bases de données, notamment le basculement automatique, le basculement manuel et le service forcé (avec éventuelle perte de données). Contient également des informations sur l’estimation de l’interruption du service pendant le changement de rôle.

Échecs possibles pendant la mise en miroir de bases de données
Décrit les problèmes physiques, de système d’exploitation et SQL Server, notamment les erreurs difficiles et les erreurs mineures, qui peuvent entraîner une défaillance dans une session de mise en miroir de bases de données. Explique comment le mécanisme de délai d'expiration de mise en miroir répond aux erreurs non permanentes.

Point de terminaison de mise en miroir de bases de données (SQL Server)
Explique comment fonctionne le point de terminaison de mise en miroir de bases de données.

Configuration de la mise en miroir de bases de données (SQL Server)
Contient des rubriques sur les prérequis, les recommandations et les étapes de configuration de la mise en miroir de bases de données.

Connecter des clients à une session de mise en miroir de bases de données (SQL Server)
Contient des rubriques couvrant les attributs de chaîne de connexion client et les algorithmes de connexion et de reconnexion d’un client à une base de données mise en miroir.

Suspension et reprise de la mise en miroir de bases de données (SQL Server)
Décrit ce qui se passe pendant que la mise en miroir de bases de données est suspendue, y compris l’impact sur la troncation du journal des transactions et contient des descriptions sur la façon de suspendre et de reprendre la mise en miroir de bases de données.

Suppression de la mise en miroir de bases de données (SQL Server)
Décrit l’impact de la suppression de la mise en miroir et contient des descriptions sur la façon de mettre fin à une session

Surveillance de la mise en miroir de bases de données (SQL Server)
Contient des informations sur l’utilisation du moniteur de mise en miroir de bases de données ou des procédures stockées dbmmonitor pour surveiller la mise en miroir de bases de données ou les sessions.

Tâches associées

Tâches de configuration

Utilisation de SQL Server Management Studio

Utilisation de Transact-SQL

Utilisation de Transact-SQL ou de SQL Server Management Studio

Tâches administratives

Transact-SQL

SQL Server Management Studio

Voir aussi

Point de terminaison de mise en miroir de bases de données (SQL Server)
Réparation automatique des pages (pour les groupes de disponibilité et la mise en miroir de bases de données)
Résoudre les problèmes de configuration de mise en miroir de bases de données (SQL Server)
Mise en miroir de bases de données : interopérabilité et coexistence (SQL Server)
Conditions préalables, restrictions et recommandations pour la mise en miroir de bases de données
Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server)
À propos de la copie des journaux de transaction (SQL Server)

  • Last updated on