Mise en miroir asynchrone de bases de données (mode hautes performances)
[!REMARQUE]
La mise en miroir asynchrone de bases de données est prise en charge uniquement par SQL Server 2005 Enterprise Edition Service Pack 1 (SP1) et versions ultérieures.
Si la sécurité des transactions est désactivée (OFF), la session de mise en miroir de bases de données fonctionne de manière asynchrone. Le fonctionnement asynchrone ne prend en charge qu'un mode d'opération : le mode 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 survenant sur le serveur miroir n'ont jamais d'impact sur le serveur principal. En cas de perte du serveur principal, la base de données miroir est marquée comme DISCONNECTED, mais est disponible en état de secours semi-automatique.
Le mode hautes performances prend en charge une seule forme de basculement de rôle : le service forcé (avec perte de données possible), qui utilise le serveur miroir comme un serveur de secours semi-automatique. Le service forcé est l'une des réponses possibles à la défaillance du serveur principal. Comme une perte de données est possible, vous devez envisager d'autres alternatives avant de forcer le service sur le miroir. Pour plus d'informations, consultez « Réponse à la défaillance du serveur principal », plus loin dans cette rubrique.
La figure suivante illustre la configuration d'une session à l'aide du mode hautes performances.
.gif "Configuration de serveur partenaire uniquement d'une session")
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 d'accusé de réception du serveur miroir. Les transactions sont validées sans attendre que le serveur miroir enregistre le journal sur le disque. Le fonctionnement asynchrone permet au serveur principal de s'exécuter avec une latence de transaction minimale.
Le serveur miroir tente de rester à jour par rapport aux enregistrements de journal envoyés par le serveur principal. En revanche, 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, il 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é.
Quand le mode hautes performances est-il conseillé ?
Le mode hautes performances peut être utile dans un scénario de récupération après sinistre dans lequel les serveurs principal et miroir sont considérablement éloignés et où vous ne souhaitez pas que de petites erreurs affectent le serveur principal.
[!REMARQUE]
La copie des journaux de transaction peut être un supplément à la mise en miroir de base de données et constitue une alternative favorable à la mise en miroir de base de données asynchrone. Pour plus d'informations sur les avantages de la copie des journaux de transaction, consultez Vue d'ensemble des solutions à haute disponibilité. Pour plus d'informations sur l'utilisation de l'envoi de journaux avec la mise en miroir de bases de données, consultez Mise en miroir de base de données et copie des journaux de transaction.
Impact d'un témoin sur le mode hautes performances
Si vous utilisez Transact-SQL pour configurer le mode hautes performances, chaque fois que la propriété SAFETY est désactivée (OFF), nous vous conseillons vivement d'affecter également la valeur OFF à la propriété WITNESS. Un témoin peut coexister avec le mode hautes performances, mais le témoin ne fournit aucun avantage et introduit un risque.
Si le témoin est déconnecté de la session lorsqu'un des partenaires s'arrête, la base de données n'est plus disponible. Cela s'explique par le fait que même si le mode hautes performance s ne requiert pas de témoin, si un témoin est défini, la session requiert un quorum composé d'au moins deux instances de serveur. Si la session perd le quorum, elle ne peut pas servir la base de données.
Lorsqu'un témoin est défini 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 réintègre la session.
Si le serveur principal est perdu, forcer le service sur le serveur miroir exige que le serveur miroir soit connecté au témoin.
[!REMARQUE]
Pour plus d'informations sur les types de quorums, consultez Quorum : effets d'un témoin sur la disponibilité de la base de données.
Réponse à la défaillance du serveur principal
Si le serveur principal se bloque, le propriétaire de la base de données dispose des options suivantes :
Laisser la base de données indisponible jusqu'à ce que le serveur principal soit à nouveau disponible.
Si la base de données principale et son journal des transactions interagissent, cette option conserve l'ensemble des transactions validées aux dépens de la disponibilité.
Arrêter la session de mise en miroir de bases de données, mettre à jour manuellement la base de données, puis lancer une nouvelle session de mise en miroir de bases de données.
Si vous perdez la base de données principale alors que le serveur principal est toujours en cours d'exécution, tentez immédiatement de sauvegarder la fin du journal dans la base de données principale. Si cette opération de sauvegarde réussit, la suppression de la mise en miroir peut constituer la meilleure solution. Une fois la mise en miroir supprimée, vous pouvez restaurer le journal dans la base de données miroir précédente, ce qui vous permet de préserver l'ensemble des données.
[!REMARQUE]
Si l'opération de sauvegarde de fichier journal a échoué et vous ne pouvez pas attendre le rétablissement du serveur principal, envisagez de forcer le service, ce qui offre l'avantage de conserver l'état de la session.
Service forcé (avec perte de données potentielle) sur le serveur miroir.
Le service forcé est exclusivement une méthode de récupération en cas d'urgence qui doit être utilisée de manière limitée. Il n'est possible de forcer le service que si le serveur principal est hors service, si la session est asynchrone (sécurité des transactions désactivée) et si la session ne possède pas de témoin (la propriété WITNESS a la valeur OFF) ou si le témoin est connecté au serveur miroir (c'est-à-dire, qu'ils ont un quorum).
Si vous forcez le service, le serveur miroir est contraint de jouer le rôle de serveur principal et de servir sa propre copie de la base de données aux clients. En cas de service forcé, les journaux des transactions que le serveur principal n'a pas encore envoyés au serveur miroir sont perdus. Par conséquent, il est conseillé de limiter le service forcé aux situations où un risque de perte de données est acceptable et où la disponibilité immédiate des bases de données est essentielle. Pour plus d'informations sur le mode de fonctionnement du service forcé et sur les méthodes conseillées pour son utilisation, consultez Service forcé (avec possibilité de perte de données).