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.
Pour prendre en charge le basculement automatique, une session de mise en miroir de bases de données doit être configurée en mode haute sécurité et posséder également une troisième instance de serveur, appelée témoin. Le témoin est une instance facultative de SQL Server qui permet au serveur miroir d’une session en mode haute sécurité de reconnaître s’il faut lancer un basculement automatique. Contrairement aux deux partenaires, 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.
Remarque
En mode hautes performances, le témoin peut avoir un impact négatif sur la disponibilité. Si un témoin est configuré pour une session de mise en miroir de bases de données, le serveur principal doit être connecté au moins à l’une des autres instances de serveur, au serveur miroir ou au témoin, ou les deux. Sinon, la base de données devient indisponible et forcer le service (avec une perte de données possible) est impossible. Par conséquent, pour le mode hautes performances, nous vous recommandons vivement de conserver le témoin défini 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.
L’illustration suivante montre une session en mode haute sécurité avec un témoin.
Dans cette rubrique :
Utilisation d’un témoin dans plusieurs sessions
Une instance de serveur spécifique peut servir de témoin dans les sessions de mise en miroir de bases de données simultanées, chacune pour une base de données différente. Différentes sessions peuvent être avec différents partenaires. L’illustration suivante montre une instance de serveur témoin dans deux sessions de mise en miroir de bases de données avec différents partenaires.
Une instance à serveur unique peut également fonctionner en même temps qu’un témoin dans certaines sessions et un partenaire dans d’autres sessions. Toutefois, dans la pratique, une instance de serveur fonctionne généralement en tant que témoin ou partenaire. Cela est dû au fait que les partenaires nécessitent des ordinateurs sophistiqués qui ont suffisamment de matériel pour prendre en charge une base de données de production, tandis que le témoin peut s’exécuter sur n’importe quel système Windows disponible qui prend en charge SQL Server 2014.
Recommandations logicielles et matérielles
Nous recommandons vivement que le témoin réside sur un ordinateur distinct des partenaires. Les partenaires de mise en miroir de bases de données sont pris en charge uniquement par l’édition SQL Server Standard et par l’édition SQL Server Enterprise. Les témoins, en revanche, sont également pris en charge par le groupe de travail SQL Server et par SQL Server Express. À l’exception d’une mise à niveau à partir d’une version antérieure de SQL Server, les instances de serveur d’une session de mise en miroir doivent toutes exécuter la même version de SQL Server. Par exemple, un témoin SQL Server 2008 est pris en charge lorsque vous effectuez une mise à niveau à partir d’une configuration de mise en miroir SQL Server 2008, mais ne peut pas être ajouté à une configuration de mise en miroir SQL Server 2008 R2 ou ultérieure.
Un témoin peut s’exécuter sur n’importe quel système informatique fiable qui prend en charge l’une de ces éditions de SQL Server. Toutefois, nous vous recommandons que chaque instance de serveur utilisée en tant que témoin corresponde à la configuration minimale requise pour la version SQL Server Standard que vous exécutez. Pour plus d’informations sur ces exigences, consultez Configuration matérielle et logicielle requise pour l’installation de SQL Server 2014.
Rôle du témoin dans le basculement automatique
Tout au long d’une session de mise en miroir de bases de données, toutes les instances de serveur surveillent leur état de connexion. Si les partenaires deviennent déconnectés les uns des autres, ils s’appuient sur le témoin pour s’assurer qu’un seul d’entre eux sert actuellement la base de données. Si un serveur miroir synchronisé perd sa connexion au serveur principal, mais reste connecté au témoin, le serveur miroir contacte le témoin pour déterminer si le témoin a perdu sa connexion au serveur principal :
Si le serveur principal est toujours connecté au témoin, le basculement automatique ne se produit pas. Au lieu de cela, le serveur principal continue à serveurr la base de données lors de l’accumulation d’enregistrements de journal pour envoyer le serveur miroir lorsque les partenaires se reconnectent.
Si le témoin est également déconnecté du serveur principal, le serveur miroir sait que la base de données principale n’est plus disponible. Dans ce cas, le serveur miroir lance immédiatement un basculement automatique.
Si le serveur miroir est déconnecté du témoin et également du serveur principal, le basculement automatique n’est pas possible, quel que soit l’état du serveur principal.
L’exigence de connexion d’au moins deux des instances de serveur est appelée quorum. Le quorum garantit que la base de données ne peut être servie que par un seul partenaire à la fois. Pour plus d’informations sur le fonctionnement du quorum et son impact sur une session, consultez Quorum : Comment un témoin affecte la disponibilité de la base de données (mise en miroir de bases de données).
Pour ajouter ou supprimer un témoin
Pour ajouter un témoin
Pour supprimer le témoin
Voir aussi
Basculement de rôle durant une session de mise en miroir de bases de données (SQL Server)
Modes de fonctionnement de la mise en miroir de bases de données
Quorum : Impact d’un témoin sur la disponibilité de la base de données (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)