Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique décrit les modes d’exploitation synchrones et asynchrones pour les sessions de mise en miroir de bases de données.
Remarque
Pour une présentation de la mise en miroir de bases de données, consultez La mise en miroir de bases de données (SQL Server)
Termes et définitions
Cette section présente quelques termes qui sont centraux à cette rubrique.
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.
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
Pour être utilisé uniquement avec le mode haute sécurité, une instance optionnelle de SQL Server qui permet au serveur miroir de déterminer s’il doit 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.
Mise en miroir de bases de données asynchrones (modeHigh-Performance)
Cette section décrit le fonctionnement de la mise en miroir de bases de données asynchrones, lorsqu’il est approprié d’utiliser le mode hautes performances et comment répondre en cas d’échec du serveur principal.
Remarque
La plupart des éditions de SQL Server 2014 prennent uniquement en charge la mise en miroir de bases de données synchrones (« Safety Full Only »). Pour plus d’informations sur les éditions qui prennent entièrement en charge la mise en miroir de bases de données, consultez « Haute disponibilité (AlwaysOn) » dans les fonctionnalités prises en charge par les éditions de SQL Server 2014.
Lorsque la sécurité des transactions est définie sur OFF, la session de mise en miroir de bases de données fonctionne de manière asynchrone. L’opération asynchrone ne prend en charge qu’un seul mode d’exploitation à hautes performances. Ce mode améliore les performances au détriment de la haute disponibilité. Le mode hautes performances utilise uniquement le serveur principal et le serveur miroir. Les problèmes sur le serveur miroir n’ont jamais d’impact sur le serveur principal. Lors de la perte du serveur principal, la base de données miroir est marquée comme désactivée, mais elle reste disponible en tant que serveur de secours à chaud.
Le mode hautes performances ne prend en charge qu’une seule forme de basculement de rôle : service forcé (avec perte de données possible), qui utilise le serveur miroir comme serveur de secours chaud. Le service forcé est l’une des réponses possibles à l’échec du serveur principal. Étant donné que la perte de données est possible, vous devez envisager des alternatives avant de forcer le service au miroir. Pour plus d’informations, consultez Répondre à l’échec du principal, plus loin dans cette rubrique.
La figure suivante montre la configuration d’une session à l’aide du mode hautes performances.
En mode hautes performances, dès que le serveur principal envoie le journal d’une transaction au serveur miroir, le serveur principal envoie une confirmation au client, sans attendre un accusé de réception du serveur miroir. Les transactions sont confirmées sans attendre que le serveur miroir écrive le fichier journal sur le disque. L’opération asynchrone permet au serveur principal de s’exécuter avec une latence de transaction minimale.
Le serveur miroir tente de suivre les enregistrements de journal envoyés par le serveur principal. Toutefois, la base de données miroir peut se trouver un peu derrière la base de données principale, bien que l’écart entre les bases de données soit généralement faible. Toutefois, l’écart peut devenir important si le serveur principal est sous une charge de travail importante ou si le système du serveur miroir est surchargé.
Quand le mode High-Performance est-il approprié ?
Le mode hautes performances peut être utile dans un scénario de récupération d’urgence dans lequel les serveurs principal et miroir sont séparés par une distance significative et où vous ne souhaitez pas que de petites erreurs affectent le serveur principal.
Remarque
La copie de journal de transactions peut compléter la mise en miroir des bases de données et constitue une alternative favorable à la mise en miroir de bases de données asynchrone. Pour plus d’informations sur les avantages de la copie des journaux de transaction, consultez solutions de haute disponibilité (SQL Server). Pour plus d’informations sur l’utilisation de l’expédition des journaux avec la mise en miroir de la base de données, consultez La mise en miroir de la base de données et l’expédition des journaux (SQL Server).
L'impact d'un témoin sur le mode High-Performance
Si vous utilisez Transact-SQL pour configurer le mode hautes performances, chaque fois que la propriété SAFETY est définie sur OFF, nous vous recommandons vivement de définir la propriété WITNESS sur OFF. Un témoin peut coexister avec le mode hautes performances, mais le témoin n’offre aucun avantage et présente des risques.
Si le témoin est déconnecté de la session lorsque l’un des partenaires tombe en panne, la base de données devient indisponible. Cela est dû au fait que, même si le mode hautes performances ne nécessite pas de témoin, si un témoin est défini, la session nécessite un quorum composé de deux instances de serveur ou plus. Si la session perd le quorum, elle ne peut pas servir la base de données.
Lorsqu’un témoin est configuré dans une session en mode hautes performances, l’application du quorum signifie que :
Si le serveur miroir est perdu, le serveur principal doit être connecté au témoin. Sinon, le serveur principal met sa base de données hors connexion jusqu’à ce que le témoin ou le serveur miroir rejoigne la session.
Si le serveur principal est perdu, forcer le service au serveur miroir nécessite que le serveur miroir soit connecté au témoin.
Remarque
Pour plus d’informations sur les types de quorums, consultez Quorum : Comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données)
Réponse à l’échec du principal
Lorsque le principal échoue, le propriétaire de la base de données a plusieurs choix, comme suit :
Laissez la base de données indisponible jusqu'à ce que le principal soit de nouveau disponible.
Si la base de données principale et son journal des transactions sont intactes, ce choix conserve toutes les transactions validées au détriment de la disponibilité.
Arrêtez la session de mise en miroir de bases de données, mettez à jour manuellement la base de données, puis commencez une nouvelle session de mise en miroir de bases de données.
Si la base de données principale est perdue, mais que le serveur principal est toujours actif, essayez immédiatement de sauvegarder le dernier segment du journal sur la base de données principale. Si la sauvegarde de la fin du journal réussit, envisager de supprimer la mise en miroir pourrait être votre meilleure option. Après avoir supprimé la fonction de mise en miroir, vous pouvez restaurer le journal sur l'ancienne base de données utilisée pour la mise en miroir, ce qui préserve toutes les données.
Remarque
Si la sauvegarde de la fin du journal a échoué et que vous ne pouvez pas attendre la récupération du serveur principal, envisagez de forcer le service, ce qui présente l’avantage de maintenir l’état de la session.
Forcer le service sur le serveur miroir (avec possibilité de perte de données).
Le service forcé est strictement une méthode de récupération d’urgence et doit être utilisé avec modération. Le service forcé est possible uniquement si le serveur principal est arrêté, la session est asynchrone (la sécurité des transactions est définie sur OFF) et la session n’a pas de témoin (la propriété WITNESS est définie sur OFF) ou le témoin est connecté au serveur miroir (autrement dit, ils ont un quorum).
Forcer le service entraîne le serveur miroir à assumer le rôle de principal pour servir sa propre copie de la base de données aux clients. Lorsque le service est forcé, les journaux des transactions que le principal n’a pas encore envoyés au serveur miroir sont perdus. Par conséquent, vous devez limiter le service forcé aux situations où la perte de données possible est acceptable et la disponibilité immédiate de la base de données est critique. Pour plus d’informations sur le fonctionnement du service forcé et sur les meilleures pratiques pour l’utiliser, consultez Changement de rôle pendant une session de mise en miroir de bases de données (SQL Server).
Mise en miroir de bases de données synchrone (modeHigh-Safety)
Cette section décrit le fonctionnement de la mise en miroir de bases de données synchrone, y compris les modes de haute sécurité alternatifs (avec basculement automatique et sans basculement automatique) et contient des informations sur le rôle du témoin dans le basculement automatique.
Lorsque la sécurité des transactions est définie sur FULL, la session de mise en miroir de bases de données s’exécute en mode haute sécurité et fonctionne de manière synchrone après une phase de synchronisation initiale. Cette section décrit les détails des sessions de mise en miroir de bases de données configurées pour une opération synchrone.
Pour effectuer une opération synchrone pour une session, le serveur miroir doit synchroniser la base de données miroir avec la base de données principale. Lorsque la session commence, le serveur principal commence à envoyer son journal actif au serveur miroir. Le serveur miroir écrit tous les enregistrements de journal entrants sur le disque le plus rapidement possible. Dès que tous les enregistrements de journal reçus ont été écrits sur disque, les bases de données sont synchronisées. Tant que les partenaires restent en communication, les bases de données restent synchronisées.
Remarque
Pour surveiller les modifications d’état dans une session de mise en miroir de bases de données, utilisez la classe d’événements Database Mirroring State Change . Pour plus d’informations, consultez la classe d’événement de changement d’état de mise en miroir de bases de données.
Une fois la synchronisation terminée, chaque transaction validée sur la base de données principale est également validée sur le serveur miroir, garantissant ainsi la protection des données. Pour ce faire, attendez de valider une transaction sur la base de données principale, jusqu’à ce que le serveur principal reçoive un message du serveur miroir indiquant qu’il a renforcé le journal de la transaction sur le disque. Notez que l’attente de ce message augmente la latence de la transaction.
Le temps nécessaire à la synchronisation dépend essentiellement de la distance entre la base de données miroir et la base de données principale au début de la session (mesurée par le nombre d’enregistrements de journal initialement reçus du serveur principal), de la charge de travail sur la base de données principale et de la vitesse du système miroir. Une fois qu’une session est synchronisée, le journal renforcé qui n’a pas encore été restauré sur la base de données miroir reste dans la file d’attente de restauration automatique.
Dès que la base de données miroir est synchronisée, l’état des deux copies de la base de données passe à SYNCHRONIZED.
L'opération se déroule de la manière suivante :
Lors de la réception d’une transaction à partir d’un client, le serveur principal écrit le journal de la transaction dans le journal des transactions.
Le serveur principal écrit la transaction dans la base de données et envoie simultanément l’enregistrement du journal au serveur miroir. Le serveur principal attend un accusé de réception du serveur miroir avant de confirmer l’une des opérations suivantes au client : une validation de transaction ou une restauration.
Le serveur miroir inscrit le journal sur le disque et retourne un accusé de réception au serveur principal.
Lors de la réception de l’accusé de réception du serveur miroir, le serveur principal envoie un message de confirmation au client.
Le mode haute sécurité protège vos données en exigeant la synchronisation des données entre deux emplacements. Toutes les transactions validées sont garanties d’être écrites sur le disque sur le serveur miroir.
Le mode High-Safety sans basculement automatique
La figure suivante montre la configuration du mode haute sécurité sans basculement automatique. La configuration se compose uniquement des deux partenaires.
Lorsque les partenaires sont connectés et que la base de données est déjà synchronisée, le basculement manuel est supporté. Si l’instance de serveur miroir tombe en panne, l’instance de serveur principal n’est pas affectée et fonctionne sans protection, autrement dit sans mettre en miroir les données. Si le serveur principal est perdu, le miroir est suspendu, mais le service peut être forcé vers le serveur miroir (avec perte de données possible). Pour plus d’informations, consultez Changement de rôle pendant une session de mise en miroir de bases de données (SQL Server).
mode High-Safety avec basculement automatique
Le basculement automatique offre une haute disponibilité en veillant à ce que la base de données soit toujours disponible après la perte d’un serveur. Le basculement automatique nécessite que la session possède une troisième instance de serveur, le témoin, qui réside idéalement sur un troisième ordinateur. La figure suivante montre la configuration d’une session en mode haute sécurité qui prend en charge le basculement automatique.
Contrairement aux deux partenaires, le témoin ne sert pas la base de données. Le témoin prend simplement en charge le basculement automatique en vérifiant si le serveur principal est opérationnel. 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.
Lorsqu’un témoin est défini, la session nécessite un quorum – une relation entre au moins deux instances de serveur qui permet à la base de données de devenir disponible. Pour plus d’informations, consultez Témoin de mise en miroir de base de données et Quorum : comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données).
Le basculement automatique nécessite les conditions suivantes :
La base de données est déjà synchronisée.
L’échec se produit alors que les trois instances de serveur sont connectées et que le témoin et le serveur miroir restent connectés.
La perte d’un partenaire a l’effet suivant :
Si le serveur principal devient indisponible dans les conditions ci-dessus, le basculement automatique se produit. Le serveur miroir bascule vers le rôle du principal et offre sa base de données comme base de données principale.
Si le serveur principal devient indisponible lorsque ces conditions ne sont pas remplies, le service forcé (avec perte de données possible) peut être possible. Pour plus d’informations, consultez Changement de rôle pendant une session de mise en miroir de bases de données (SQL Server).
Si le seul serveur miroir devient indisponible, le principal et le témoin continuent.
Si la session perd son témoin, le quorum nécessite les deux partenaires. Si l’un ou l’autre partenaire perd le quorum, les deux partenaires perdent le quorum et la base de données devient indisponible tant que le quorum n’est pas rétabli. Cette exigence de quorum garantit que, en l’absence d’un témoin, la base de données ne s’exécute jamais exposée, c’est-à-dire sans être mise en miroir.
Remarque
Si vous prévoyez que le témoin reste déconnecté pendant une période importante, nous vous recommandons de supprimer le témoin de la session jusqu’à ce qu’il soit disponible.
Transact-SQL Paramètres et modes de fonctionnement du miroir de bases de données
Cette section décrit une session de mise en miroir de bases de données en termes de paramètres et d’états ALTER DATABASE de la base de données et du témoin mis en miroir, le cas échéant. La section vise les utilisateurs qui gèrent la mise en miroir de bases de données principalement ou exclusivement à l’aide de Transact-SQL, plutôt que d’utiliser SQL Server Management Studio.
Conseil / Astuce
En guise d’alternative à l’utilisation de Transact-SQL, vous pouvez contrôler le mode d’exploitation d’une session dans l’Explorateur d’objets à l’aide de la page Mise en miroir de la boîte de dialogue Propriétés de la base de données . Pour plus d’informations, consultez Établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (SQL Server Management Studio).
Comment la sécurité des transactions et l’état témoin affectent le mode d’exploitation
Le mode d’exploitation d’une session est déterminé par la combinaison de son paramètre de sécurité des transactions et de l’état du témoin. À tout moment, le propriétaire de la base de données peut modifier le niveau de sécurité des transactions et peut ajouter ou supprimer le témoin.
Sécurité des transactions
La sécurité des transactions est une 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.
SÉCURITÉ COMPLÈTE
La sécurité complète des transactions entraîne le fonctionnement synchrone de la session en mode haute sécurité. Si un témoin est présent, une session prend en charge le basculement automatique.
Lorsque vous établissez une session à l’aide d’instructions ALTER DATABASE, la session commence par la propriété SAFETY définie sur FULL ; autrement dit, la session commence en mode haute sécurité. Une fois la session commencée, vous pouvez ajouter un témoin.
Pour plus d’informations, consultez La mise en miroir de bases de données synchrone (modeHigh-Safety), plus haut dans cette rubrique.
SÉCURITÉ OFF
La désactivation de la sécurité des transactions entraîne le fonctionnement asynchrone de la session en mode hautes performances. Si la propriété SAFETY est définie sur OFF, la propriété WITNESS doit également être définie sur OFF (valeur par défaut). Pour plus d’informations sur l’impact du témoin en mode hautes performances, consultez l’état du témoin, plus loin dans cette rubrique. Pour plus d’informations sur l’exécution avec la sécurité des transactions désactivée, consultez La mise en miroir de bases de données asynchrone (modeHigh-Performance), plus haut dans cette rubrique.
Le paramètre de sécurité des transactions de la base de données est enregistré pour chaque serveur partenaire dans la vue de catalogue sys.database_mirroring des colonnes mirroring_safety_level et mirroring_safety_level_desc. Pour plus d’informations, consultez sys.database_mirroring (Transact-SQL).
Le propriétaire de la base de données peut modifier le niveau de sécurité des transactions à tout moment.
État du témoin
Si un témoin a été défini, le quorum est requis, de sorte que l’état du témoin est toujours significatif.
S’il existe, le témoin a l’un des deux états suivants :
Lorsque le témoin est connecté à un partenaire, le témoin est dans l’état CONNECTÉ par rapport à ce partenaire et a le quorum avec ce partenaire. Dans ce cas, la base de données peut être mise à disposition, même si l’un des partenaires n’est pas disponible.
Lorsqu’il existe un témoin mais qu’il n’est pas connecté à un partenaire, il se trouve dans l’état UNKOWN ou DISCONNECTED par rapport à ce partenaire. Dans ce cas, le témoin n’a pas de quorum avec ce partenaire et, si les partenaires ne sont pas connectés les uns aux autres, la base de données devient indisponible.
Pour plus d’informations sur le quorum, consultez Quorum : Comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données).
L’état de chaque témoin sur une instance de serveur est enregistré dans l’affichage catalogue sys.database_mirroring dans les colonnes mirroring_witness_state et mirroring_witness_state_desc . Pour plus d’informations, consultez sys.database_mirroring (Transact-SQL).
Le tableau suivant résume la façon dont le mode d’exploitation d’une session dépend de son paramètre de sécurité des transactions et de l’état du témoin.
| Mode d’exploitation | Sécurité des transactions | État du témoin |
|---|---|---|
| Mode hautes performances | ÉTEINT | NULL (aucun témoin)2 |
| Mode haute sécurité sans basculement automatique | PLEIN | NULL (aucun témoin) |
| Mode haute sécurité avec basculement automatique1 | PLEIN | RELIÉ |
1 Si le témoin devient déconnecté, nous vous recommandons de définir WITNESS OFF jusqu’à ce que l’instance du serveur témoin devienne disponible.
2 Si un témoin est présent en mode hautes performances, le témoin ne participe pas à la session. Toutefois, pour rendre la base de données disponible, au moins deux des instances de serveur doivent rester connectées. Par conséquent, nous vous recommandons de conserver la propriété WITNESS définie sur OFF dans les sessions en mode hautes performances. Pour plus d’informations, consultez Quorum : Comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données).
Affichage du paramètre de sécurité et de l’état du témoin
Pour afficher le paramètre de sécurité et l’état du témoin pour une base de données, utilisez l’affichage catalogue sys.database_mirroring . Les colonnes pertinentes sont les suivantes :
| Facteur | Colonnes | Descriptif |
|---|---|---|
| Sécurité des transactions | niveau_de_sécurité_du_miroir ou description_niveau_de_sécurité_du_miroir | Paramètre de sécurité des transactions pour les mises à jour sur la base de données miroir, l’un des éléments suivants : INCONNU ÉTEINT PLEIN NULL= la base de données n’est pas en ligne. |
| Existe-t-il un témoin ? | nom_témoin_de_miroir | Nom du serveur témoin de mise en miroir de la base de données ou NULL, ce qui indique qu’aucun témoin n’existe. |
| État du témoin | mirroring_witness_state ou mirroring_witness_state_desc | État du témoin dans la base de données sur un partenaire donné : INCONNU RELIÉ DÉCONNECTÉ NULL = aucun témoin n’existe ou la base de données n’est pas en ligne. |
Par exemple, sur le serveur principal ou miroir, entrez :
SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring
Pour plus d’informations sur cet affichage catalogue, consultez sys.database_mirroring (Transact-SQL).
Facteurs influençant le comportement en cas de défaillance du serveur principal
Le tableau suivant résume l’effet combiné du paramètre de sécurité des transactions, de l’état de la base de données et de l’état du témoin sur le comportement d’une session de mise en miroir sur la perte du serveur principal.
| Sécurité des transactions | État de mise en miroir de la base de données miroir | État du témoin | Comportement lorsque le principal est perdu |
|---|---|---|---|
| PLEIN | SYNCHRONISÉ | RELIÉ | Le basculement automatique se produit. |
| PLEIN | SYNCHRONISÉ | DÉCONNECTÉ | Le serveur miroir s’arrête ; le basculement n’est pas possible et la base de données ne peut pas être mise à disposition. |
| ÉTEINT | SUSPENDU OU DÉCONNECTÉ | NULL (aucun témoin) | Le service peut être forcé vers le serveur miroir (avec perte de données possible). |
| PLEIN | SYNCHRONISATION OU SUSPENSION | NULL (aucun témoin) | Le service peut être forcé vers le serveur miroir (avec perte de données possible). |
Tâches associées
Ajouter ou remplacer un témoin de mise en miroir de base de données (SQL Server Management Studio)
Supprimer le témoin d’une session de mise en miroir de bases de données (SQL Server)
Voir aussi
Surveillance de la mise en miroir de bases de données (SQL Server)
Témoin de la mise en miroir de bases de données