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.
Chaque fois qu’un témoin est défini pour une session de mise en miroir de bases de données, le quorum est requis. Le quorum est une relation qui existe quand deux instances de serveur ou plus dans une session de mise en miroir de bases de données sont connectées les unes aux autres. En règle générale, le quorum implique trois instances de serveur interconnectées. Lorsqu’un témoin est défini, le quorum est requis pour rendre la base de données disponible. Conçu pour le mode haute sécurité avec basculement automatique, le quorum garantit qu’une base de données est détenue par un seul partenaire à la fois.
Si une instance de serveur particulière devient déconnectée d’une session de mise en miroir, cette instance perd le quorum. Si aucune instance de serveur n’est connectée, la session perd le quorum et la base de données devient indisponible. Trois types de quorum sont possibles :
Un quorum complet comprend à la fois les partenaires et le témoin.
Un quorum de témoin à partenaire se compose du témoin et de l’un ou l’autre partenaire.
Un quorum partenaire-à-partenaire se compose des deux partenaires.
La figure suivante montre ces types de quorum.
Tant que le serveur principal actuel a le quorum, ce serveur possède le rôle du principal et continue à servir la base de données, sauf si le propriétaire de la base de données effectue un basculement manuel. Si le serveur principal perd le quorum, il cesse de servir la base de données. Le basculement automatique ne peut se produire que si la base de données principale a perdu le quorum, ce qui garantit qu’elle ne sert plus la base de données.
Une instance de serveur déconnectée enregistre son rôle le plus récent dans la session. En règle générale, une instance de serveur déconnectée se reconnecte à la session lorsqu’elle redémarre et récupère le quorum.
Important
Le témoin doit être configuré uniquement lorsque vous avez l'intention d'utiliser le mode à haute sécurité avec basculement automatique. En mode hautes performances, pour lequel un témoin n’est jamais nécessaire, nous vous recommandons vivement de définir la propriété WITNESS sur OFF. Pour plus d’informations sur l’impact d’un témoin sur le mode hautes performances, consultez Modes d’exploitation de mise en miroir de bases de données.
Quorum en sessions en mode High-Safety
En mode haute sécurité, le quorum autorise le basculement automatique en fournissant un contexte dans lequel les instances de serveur ayant le quorum arbitrent pour décider quel partenaire possède le rôle de principal. Le serveur principal sert la base de données si elle a un quorum. Si le serveur principal perd le quorum lorsque le serveur miroir synchronisé et le témoin conservent le quorum, le basculement automatique se produit.
Les scénarios de quorum pour le mode haute sécurité sont les suivants :
Quorum complet constitué des deux partenaires et du témoin.
En règle générale, les trois instances de serveur participent à un quorum tridirectionnel, appelé quorum complet. Avec un quorum total, les serveurs principal et miroir continuent de remplir leurs fonctions respectives (sauf en cas de basculement manuel).
Quorum témoin à partenaire qui se compose du témoin et de l’un ou l’autre partenaire.
Si la connexion réseau entre les partenaires est perdue, car l’un des partenaires a été perdu, les cas suivants sont possibles :
Le serveur miroir est perdu, et le serveur principal et le témoin conservent le quorum.
Dans ce cas, le serveur principal configure sa base de données sur DISCONNECTED et fonctionne avec la mise en miroir dans un état SUSPENDED. (Il s’agit de fonctionnement à découvert, car la base de données n’est actuellement pas mise en miroir.) Lorsque le serveur miroir rejoint la session, le serveur retrouve le quorum en tant que serveur miroir et démarre la resynchronisation de sa copie de la base de données.
Le serveur principal est perdu, et le témoin et le serveur miroir conservent le quorum.
Dans ce cas, le basculement automatique se produit. Pour plus d’informations, consultez Modes d’exploitation de mise en miroir de bases de données.
Toutes les instances de serveur perdent le quorum, mais par la suite, le miroir et le témoin se reconnectent. La base de données ne sera pas traitée dans ce cas.
Rarement, la connexion réseau entre les partenaires de basculement est perdue alors que les deux partenaires restent connectés au témoin. Dans ce cas, deux quorums distincts de témoin à partenaire existent, avec le témoin comme liaison. Le témoin informe le serveur miroir que le serveur principal est toujours connecté. Par conséquent, le basculement automatique ne se produit pas. Au lieu de cela, le serveur miroir conserve le rôle miroir et attend de se reconnecter au principal. Si la file d’attente de rétablissement contient des enregistrements de journal à ce stade, le serveur miroir continue de transférer la base de données miroir. Lors de la reconnexion, le serveur miroir resynchronise la base de données miroir.
Quorum partenaire à partenaire constitué des deux partenaires.
Tant que les partenaires conservent le quorum, la base de données reste dans un état SYNCHRONISÉ et le basculement manuel reste possible. Sans le témoin, le basculement automatique n’est pas possible ; mais lorsque le témoin récupère le quorum, la session reprend l’opération régulière et le basculement automatique est à nouveau pris en charge.
La session perd le quorum.
Si toutes les instances de serveur deviennent déconnectées les unes des autres, la session est dite avoir perdu le quorum. Lorsque les instances de serveur se reconnectent les unes aux autres, elles récupèrent le quorum entre elles.
Si le serveur principal se reconnecte à l’une des autres instances de serveur, la base de données devient disponible.
Si le serveur principal reste déconnecté, mais que le miroir et le témoin se reconnectent les uns aux autres, le basculement automatique ne peut pas se produire, car la perte de données peut se produire. Par conséquent, la base de données reste indisponible jusqu’à ce que le serveur principal rejoigne la session.
Lorsque les trois instances de serveur se reconnectent, le quorum complet est récupéré et la session reprend son opération régulière.
Important
Lorsqu’une session a un quorum partenaire à partenaire, si l’un des partenaires perd le quorum, la session perd le quorum. Par conséquent, si vous attendez que le témoin reste déconnecté pendant beaucoup de temps, nous vous recommandons de supprimer temporairement le témoin de la session. La suppression du témoin supprime la condition requise pour le quorum. Ensuite, si le serveur miroir devient déconnecté, le serveur principal peut continuer à servir la base de données. Pour plus d’informations sur l’ajout ou la suppression d’un témoin, consultez Témoin de mise en miroir de bases de données.
Impact du quorum sur la disponibilité de la base de données
L’illustration suivante montre comment le témoin et les partenaires collaborent pour s’assurer qu’à un moment donné, seul un partenaire possède le rôle de principal et seul le serveur principal actuel peut mettre en ligne sa base de données. Les deux scénarios commencent par le quorum complet et Partner_A dans le rôle principal et Partner_B dans le rôle miroir.
Le scénario 1 montre comment, après l’échec du serveur principal d’origine (Partner_A), le témoin et le miroir conviennent que le principal, Partner_A, n’est plus disponible et forment un quorum. Le miroir, Partner_B assume ensuite le rôle principal. Le basculement automatique se produit et Partner_B met en ligne sa copie de la base de données. Ensuite , Partner_B tombe en panne, et la base de données est hors connexion. Plus tard, l’ancien serveur principal, Partner_A, se reconnecte au témoin qui récupère le quorum, mais lorsqu’il communique avec le témoin, Partner_A apprend qu’il ne peut pas apporter sa copie de la base de données en ligne, car Partner_B possède désormais le rôle principal. Lorsque Partner_B rejoint la session, elle rétablit la base de données en ligne.
Dans le scénario 2, le témoin perd le quorum, tandis que les partenaires, Partner_A et Partner_B, conservent le quorum entre eux, et la base de données reste en ligne. Ensuite, les partenaires perdent leur quorum, et la base de données est hors connexion. Plus tard, le serveur principal, Partner_A, se reconnecte au témoin qui récupère le quorum. Le témoin confirme que Partner_A possède toujours le rôle principal et Partner_A ramène la base de données en ligne.
Voir aussi
Modes de fonctionnement de la mise en miroir de bases de données
Basculement de rôle durant une session de mise en miroir de bases de données (SQL Server)
Témoin de la mise en miroir de bases de données
Échecs possibles pendant la mise en miroir de bases de données
États de mise en miroir (SQL Server)