Partager via

Gérer les connexions pour les travaux qui utilisent des bases de données dans un groupe de disponibilité Always On

  • Article

S'applique à : SQL Server

Vous devez maintenir régulièrement le même ensemble de connexions utilisateur et de travaux de SQL Server Agent sur chaque base de données primaire d’un groupe de disponibilité (AG) Always On et les bases de données secondaires correspondantes. Les connexions et les travaux doivent être reproduits sur chaque instance de SQL Server qui héberge un réplica de disponibilité pour le groupe de disponibilité.

  • SQL Server Travaux de l'Agent

    Vous devez copier manuellement les travaux appropriés de l'instance de serveur qui héberge le réplica principal d'origine vers les instances de serveur qui hébergent les réplicas secondaires d'origine. Pour toutes les bases de données, vous devez ajouter la logique au début de chaque travail approprié de façon à ce que le travail s'exécute uniquement sur la base de données primaire, c.-à-d., uniquement lorsque le réplica local est le réplica principal pour la base de données.

    Les instances de serveur qui hébergent les réplicas de disponibilité d'un groupe de disponibilité peuvent être configurées différemment, avec des lettres de lecteurs différentes, par exemple. Les travaux de chaque réplica de disponibilité doivent autoriser de telles différences.

    Les travaux de sauvegarde peuvent utiliser la fonction sys.fn_hadr_backup_is_preferred_replica pour déterminer si le réplica local est celui qui est utilisé par défaut pour les sauvegardes, selon les préférences de sauvegarde du groupe de disponibilité. Les travaux de sauvegarde créés à l'aide de l'Assistant Utiliser le plan de maintenance utilisent cette fonction en mode natif. Pour d'autres travaux de sauvegarde, nous vous recommandons d'utiliser cette fonction comme condition dans vos travaux de sauvegarde, de façon à ce qu'ils s'exécutent uniquement sur le réplica par défaut. Pour plus d’informations, consultez Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité.

  • Connexions

    Si vous utilisez des bases de données autonomes, vous pouvez configurer les utilisateurs contenus dans les bases de données, et pour ces utilisateurs, vous n'avez pas besoin de créer des connexions sur des instances de serveur qui hébergent un réplica secondaire. Pour une base de données de disponibilité sans relation contenant-contenu, vous devez créer les utilisateurs pour les connexions sur les instances de serveur qui hébergent les réplicas de disponibilité. Pour plus d’informations, consultez CREATE USER.

    Si l’une de vos applications utilise l’authentification SQL Server ou une connexion locale Windows, consultez Connexions des applications qui utilisent l’authentification SQL Server ou une connexion locale Windows, plus loin dans cet article.

    Remarque

    Un utilisateur de base de données pour lequel la connexion SQL Server n'est pas définie sur une instance de serveur, ou l'est de façon incorrecte, ne peut pas se connecter à cette instance. L'utilisateur devient donc un utilisateur orphelin de la base de données sur cette instance du serveur. Si un utilisateur est orphelin sur une instance de serveur donnée, vous pouvez configurer les connexions utilisateur à tout moment. Pour plus d’informations, consultez Résoudre les problèmes d’utilisateurs orphelins (SQL Server).

  • Métadonnées supplémentaires

    Les connexions et les travaux ne sont pas les seules informations qui doivent être recréées sur chaque instance de serveur qui héberge un réplica secondaire d'un groupe de disponibilité donné. Par exemple, vous devrez peut-être recréer les paramètres de configuration du serveur, les informations d'identification, les données chiffrées, les autorisations, les paramètres de réplication, les applications de Service Broker, les déclencheurs (au niveau du serveur), etc. Pour plus d’informations, consultez Gérer les métadonnées lors de la mise à disposition d’une base de données sur un autre serveur.

Authentification SQL Server ou connexion locale Windows

Si une application utilise l'authentification SQL Server ou une connexion locale Windows, des identificateurs de sécurité (SID) incompatibles peuvent empêcher la résolution de la connexion de l'application sur une instance distante de SQL Server. En cas de SID incompatibles, la connexion peut se solder par un utilisateur orphelin sur l'instance de serveur distante. Ce problème peut se produire lorsqu'une application se connecte à une base de données de copie des journaux de transaction ou une base de données mise en miroir suite à un basculement ou à une base de données d'abonné de réplication qui a été initialisée à partir d'une sauvegarde.

Vous devez prendre des mesures préventives lorsque vous configurez une application de manière à utiliser une base de données hébergée par une instance distante de SQL Server. La prévention implique de transférer des connexions et des mots de passe de l'instance locale de SQL Server à l'instance distante de SQL Server. Pour plus d’informations sur la manière d’éviter ce problème, consultez l’article 918992 de la Base de connaissances : Transférer des noms d’accès et des mots de passe entre instances de SQL Server.

Remarque

Ce problème affecte les comptes Windows locaux sur différents ordinateurs. Toutefois, ce problème ne se pose pas pour les comptes de domaine car le SID est identique sur chacun des ordinateurs.

Pour plus d’informations, consultez Orphaned Users with Database Mirroring and Log Shipping (Utilisateurs orphelins avec mise en miroir de bases de données et copie des journaux de transaction) (blog du moteur de base de données).

Contenu connexe