Partage via

Qu’est-ce qu’un groupe de disponibilité autonome ?

  • Article

S’applique à : SQL Server 2022 (16.x)

Un groupe de disponibilité contenu est un groupe de disponibilité Always On qui prend en charge :

  • Gestion des objets de métadonnées (utilisateurs, connexions, autorisations, travaux SQL Agent, etc.) au niveau du groupe de disponibilité, ainsi qu’au niveau de l’instance.

  • Bases de données système autonomes spécialisées au sein du groupe de disponibilité.

Cet article décrit en détail les similitudes, les différences et les fonctionnalités des groupes de disponibilité autonomes.

Vue d’ensemble

En général, les groupes de disponibilité se composent d'une ou de plusieurs bases de données utilisateur destinées à fonctionner en tant que groupe coordonné et qui sont répliquées sur un certain nombre de nœuds dans un cluster. En cas d’échec dans le nœud ou dans l’intégrité de SQL Server sur le nœud qui héberge la copie principale, le groupe des bases de données est déplacé comme une seule unité vers un autre nœud de réplica dans le groupe de disponibilité. Toutes les bases de données utilisateur restent synchronisées sur tous les réplicas du groupe de disponibilité, en mode synchrone ou asynchrone.

Cela fonctionne bien pour les applications qui interagissent uniquement avec cet ensemble de bases de données utilisateur, mais des difficultés surviennent lorsque les applications s’appuient également sur des objets tels que les utilisateurs, les connexions, les autorisations, les travaux de l’agent, etc., qui sont stockés dans l’une des bases de données système (master ou msdb). Pour que les applications fonctionnent de manière fluide et prévisible, l’administrateur doit s’assurer manuellement que toute modification apportée à ces objets est dupliquée sur toutes les instances de réplica du groupe de disponibilité. Si une nouvelle instance est introduite dans le groupe de disponibilité, les bases de données peuvent être attribuées automatiquement ou manuellement via un processus simple, mais dans ce cas, toutes les personnalisations de la base de données système doivent être reconfigurées sur la nouvelle instance pour qu’elle corresponde aux autres réplicas.

Les groupes de disponibilité autonomes étendent le concept du groupe de bases de données répliquées pour inclure des parties pertinentes des bases de données master et msdb. Considérez cela comme le contexte d’exécution pour les applications qui utilisent le groupe de disponibilité autonome. L’idée est que l’environnement du groupe de disponibilité autonome inclut des paramètres qui affecteraient l’application qui dépend d’eux. Par conséquent, l'environnement AG concerne toutes les bases de données avec lesquelles l'application interagit, l'authentification qu'elle utilise (connexions, utilisateurs, autorisations), les tâches planifiées devant être exécutées et d'autres paramètres de configuration qui ont un impact sur l'application.

Cela est différent des bases de données autonomes, qui utilisent un mécanisme différent pour les comptes utilisateur, stockant les informations utilisateur au sein de la base de données elle-même. Les bases de données autonomes répliquent uniquement les connexions et les utilisateurs, et l’étendue de la connexion ou de l’utilisateur répliqué est limitée à cette seule base de données (et à ses réplicas).

En revanche, dans un groupe de disponibilité autonome, vous pouvez créer des utilisateurs, des connexions, des autorisations, et ainsi de suite, au niveau du groupe de disponibilité, et ces éléments présentent automatiquement une cohérence avec les réplicas du groupe de disponibilité, ainsi qu’une cohérence avec les bases de données au sein de ce groupe de disponibilité autonome. Cela évite à l’administrateur d’effectuer manuellement ces modifications.

Différences

Il existe des différences pratiques à prendre en compte lors de l’utilisation de groupes de disponibilité contenus, comme la création de bases de données système contenues et le forçage de la connexion au niveau du groupe de disponibilité contenu, plutôt que d’utiliser la connexion au niveau de l’instance.

Bases de données système autonomes

Chaque groupe de disponibilité autonome possède ses propres bases de données système master et msdb nommées d’après le nom du groupe de disponibilité. Par exemple, dans le groupe de disponibilité autonome MyContainedAG, vous avez des bases de données nommées MyContainedAG_master et MyContainedAG_msdb. Ces bases de données système sont automatiquement déployées sur de nouveaux réplicas et les mises à jour sont répliquées sur ces bases de données comme toute autre base de données d'un groupe de disponibilité. Cela signifie que pour les objets tels qu’une connexion ou un travail d’agent, qui ont été ajoutés lorsque vous êtes connecté au groupe de disponibilité autonome, vous voyez toujours les travaux de l’agent et vous pouvez vous authentifier à l’aide de la connexion créée dans le groupe de disponibilité autonome en cas de basculement du groupe de disponibilité autonome vers une autre instance.

Important

Les groupes de disponibilité autonomes sont un mécanisme permettant de maintenir la cohérence des configurations d’environnement d’exécution entre les réplicas d’un groupe de disponibilité. Ils ne représentent pas une limite de sécurité. Par exemple, il n’existe pas de limite qui empêche une connexion à un groupe de disponibilité autonome d’accéder à des bases de données en dehors du groupe de disponibilité.

Les bases de données système d’un groupe de disponibilité autonome nouvellement créé ne sont pas des copies réalisées à partir de l’instance où la commande CREATE AVAILABILITY GROUP est exécutée. Ce sont initialement des modèles vides sans aucune donnée. Les comptes administrateur de l’instance qui crée le groupe de disponibilité autonome sont copiés dans le groupe de disponibilité autonome master immédiatement après la création de celui-ci. De cette façon, l’administrateur peut se connecter au groupe de disponibilité autonome et procéder au reste de la configuration.

Si vous créez des utilisateurs ou des configurations au niveau local dans votre instance, ces éléments n’apparaissent pas automatiquement lorsque vous créez vos bases de données système autonomes et ne sont pas visibles lorsque vous vous connectez au groupe de disponibilité autonome. Une fois la base de données utilisateur jointe à un groupe de disponibilité autonome, elle devient immédiatement inaccessible à ces utilisateurs. Vous devez les recréer manuellement dans les bases de données système autonomes dans le contexte du groupe de disponibilité autonome, en vous connectant directement à la base de données ou en utilisant le point de terminaison de l’écouteur. L’exception à cette règle est que toutes les connexions dans le rôle d’administrateur système de l’instance parente sont copiées dans la nouvelle base de données master spécifique au groupe de disponibilité.

Remarque

Étant donné que la base de données master est distincte pour chaque groupe de disponibilité conteneurisé, les activités à portée du serveur effectuées dans le contexte du groupe de disponibilité conteneurisé sont conservées uniquement dans la base de données système du groupe conteneurisé. Cela inclut l’audit. Si vous auditez l’activité au niveau du serveur avec l’audit SQL Server, vous devez créer les mêmes audits de serveur au sein de chaque groupe de disponibilité autonome.

Restaurer une base de données système autonome

Vous pouvez restaurer une base de données système contenue de deux façons différentes.

  • Restaurer une base de données contenue à l’aide d’une réplique secondaire :

    1. Restaurez les bases de données autonomes master et msdb sur une instance de serveur qui héberge le réplica secondaire, à l’aide de RESTORE WITH NORECOVERY pour chaque opération de restauration. Pour plus d’informations, consultez l’article Préparer une base de données secondaire pour un groupes de disponibilité Always On.

    2. Joignez chaque base de données autonome au groupe de disponibilité. Pour plus d’informations, consultez Joindre une base de données secondaire à un groupes de disponibilité Always On.

  • Restaurer une base de données autonome en supprimant le groupe de disponibilité autonome :

    1. Supprimez le groupe de disponibilité autonome.

    2. Restaurez les bases de données autonomes master et msdb dans chacune des instances participant au groupe de disponibilité autonome.

    3. Recréez le groupe de disponibilité autonome à l’aide des nœuds et du noms d’origine, à l’aide de la syntaxe WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Travaux de groupe de disponibilité autonome

Les travaux appartenant à un groupe de disponibilité conteneurisé s'exécutent uniquement sur la réplique principale. Ils ne s’exécutent pas sur des répliques secondaires.

Connecter (environnement autonome)

Il est important de faire la différence entre la connexion à l’instance et la connexion au groupe de disponibilité autonome. La seule façon d’accéder à l’environnement du groupe de disponibilité autonome consiste à se connecter à l’écouteur du groupe de disponibilité autonome ou à se connecter à une base de données qui se trouve dans le groupe de disponibilité autonome.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Où MyContainedDatabase consiste en une base de données dans le groupe de disponibilité autonome avec lequel vous souhaitez interagir.

Cela signifie que vous devez créer un écouteur pour que le groupe de disponibilité autonome utilise efficacement un groupe de disponibilité autonome. Si vous vous connectez à l’une des instances hébergeant le groupe de disponibilité autonome plutôt que directement au groupe de disponibilité autonome via l’écouteur, vous êtes dans l’environnement de l’instance et pas dans le groupe de disponibilité autonome.

Par exemple, si votre groupe de disponibilité MyContainedAG est hébergé sur le serveur SERVER\MSSQLSERVER et que, au lieu de vous connecter à l’écouteur MyContainedAG_Listener, vous vous connectez à l’instance à l’aide de SERVER\MSSQLSERVER, vous êtes dans l’environnement de l’instance et pas dans l’environnement de MyContainedAG. Cela signifie que vous êtes soumis au contenu (utilisateurs, autorisations, travaux, etc.) qui se trouvent dans les bases de données système de l’instance. Pour accéder aux contenus disponibles dans les bases de données système autonomes du groupe de disponibilité autonome, connectez-vous à l’écouteur du groupe de disponibilité autonome (MyContainedAG_Listener par exemple). Lorsque vous êtes connecté à l’instance via l’écouteur du groupe de disponibilité autonome et que vous interagissez avec master, vous êtes en fait redirigé vers la base de données autonome master (par exemple, MyContainedAG_master).

Routage en lecture seule et groupes de disponibilité autonomes

Si vous avez configuré le routage en lecture seule pour rediriger les connexions dans une intention de lecture sur un réplica secondaire (voir Configurer le routage en lecture seule pour un groupe de disponibilité Always On) et que vous souhaitez vous connecter à l’aide d’une connexion créée uniquement dans le groupe de disponibilité autonome, quelques considérations supplémentaires doivent être prises en considération :

  • Vous devez préciser une base de données qui fait partie du groupe de disponibilité autonome dans la chaîne de connexion
  • L’utilisateur renseigné dans la chaîne de connexion doit avoir l’autorisation d’accéder aux bases de données du groupe de disponibilité autonome.

Par exemple, dans la chaîne de connexion suivante, où AdventureWorks est une base de données dans le groupe de disponibilité autonome avec MyContainedListener, et où MyUser est un utilisateur défini dans le groupe de disponibilité autonome et non dans aucune des instances participantes :

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

Cette chaîne de connexion doit vous permettre de vous connecter à la base de données secondaire accessible en lecture qui fait partie de la configuration du routage en lecture seule, et de vous trouver dans le contexte du groupe de disponibilité autonome.

Différences entre la connexion à l’instance et la connexion au groupe de disponibilité autonome

  • Lorsqu’ils sont connectés à un groupe de disponibilité autonome, les utilisateurs ne voient que les bases de données dans le groupe de disponibilité autonome, ainsi que tempdb.
  • Au niveau de l’instance, les noms des groupes de disponibilité master et msdbsont [contained AG]_master et [contained AG]_msdb. Dans le groupe de disponibilité autonome, leurs noms sont master et msdb.
  • L’identifiant de la base de données pour le groupe de disponibilité autonome master est 1 dans le contexte du groupe de disponibilité autonome, mais il est différent en cas de connexion à l’instance.
  • Bien que les utilisateurs ne voient pas les bases de données en dehors du groupe de disponibilité autonome dans sys.databases dans le cadre d’une connexion à un groupe de disponibilité autonome, ils peuvent accéder à ces bases de données par nom en trois parties ou via la commande USE.
  • La configuration du serveur via sp_configure peut être lue à partir de la connexion AG contenue, mais ne peut être écrite qu'au niveau de l'instance.
  • À partir des connexions AG contenues, le sysadmin peut effectuer des opérations au niveau de l’instance, comme l’arrêt de SQL Server.
  • La plupart des opérations au niveau de la base de données, du point de terminaison ou du groupe de disponibilité ne peuvent être effectuées qu’à partir de connexions à l’instance, et non de connexions au groupe de disponibilité autonome.

Interactions avec d’autres fonctionnalités

D’autres considérations doivent être prises en compte lors de l’utilisation de certaines fonctionnalités impliquant des groupes de disponibilité autonomes, et certaines fonctionnalités ne sont actuellement pas prises en charge.

Sauvegarder

Les procédures de sauvegarde des bases de données dans un groupe de disponibilité contenu sont les mêmes que les procédures de sauvegarde des bases de données utilisateur. Cela est vrai pour les bases de données utilisateur du groupe de disponibilité autonome et les bases de données système du groupe de disponibilité autonome.

Si l’emplacement de sauvegarde est local, les fichiers de sauvegarde sont placés sur le serveur qui exécute le travail de sauvegarde. Cela signifie que vos fichiers de sauvegarde peuvent se trouver à différents emplacements.

Si l’emplacement de sauvegarde se trouve sur une ressource réseau, tous les serveurs qui hébergent des réplicas doivent accéder à cette ressource.

Gouverneur de ressources

Dans SQL Server 2022 (16.x) avant la mise à jour cumulative 18 et dans les versions antérieures de SQL Server, la configuration ou l’utilisation de Resource Governor sur les connexions de groupe de disponibilité autonome n’est pas prise en charge.

À compter de SQL Server 2022 (16.x) Mise à jour cumulative 18, si vous configurez Resource Governor sur une connexion d’instance, la consommation de ressources sur les connexions d’instance ou les connexions de groupe de disponibilité autonome est régie comme prévu. Si vous tentez de configurer Resource Governor sur une connexion de groupe de disponibilité autonome, un message d’erreur s’affichera.

Resource Governor fonctionne au niveau de l’instance du moteur de base de données. La configuration de Resource Governor au niveau de l’instance ne se propage pas aux réplicas de disponibilité. Vous devez configurer Resource Governor sur chaque instance hébergeant un réplica de disponibilité.

Conseil / Astuce

Nous vous recommandons d’utiliser la même configuration de Resource Governor pour toutes les instances du moteur de base de données hébergeant des réplicas de disponibilité afin de garantir un comportement cohérent au fur et à mesure des basculements de groupe de disponibilité.

Pour plus d’informations, voir le Resource Governor et les exemples de configuration et meilleures pratiques de Resource Governor.

Capture des changements de données

La capture des changements de données (CDC) est implémentée en tant que travaux SQL Agent, de sorte que SQL Agent doit être en cours d’exécution sur toutes les instances avec des réplicas dans le groupe de disponibilité autonome.

Pour utiliser la capture des changements de données avec un groupe de disponibilité autonome, connectez-vous à l’écouteur du groupe de disponibilité lorsque vous configurez la capture des changements de données afin que les métadonnées de la capture des changements de données soient configurées à l’aide des bases de données système autonomes.

Copie des journaux de transaction

La copie des journaux de transaction peut être configurée si la base de données source se trouve dans le groupe de disponibilité autonome. Toutefois, les cibles de la copie des journaux de transaction ne sont pas prises en charge dans un groupe de disponibilité autonome. En outre, il y a une étape supplémentaire pour modifier le travail de copie des journaux de transaction une fois la capture des changements de données configurée.

Pour configurer la copie des journaux de transaction pour un groupe de disponibilité autonome, procédez comme suit :

  1. Connectez-vous à l’écouteur du groupe de disponibilité autonome.
  2. Configurez la copie des journaux de transaction comme vous le feriez normalement.
  3. Une fois le travail de copie des journaux de transaction configuré, modifiez le travail pour vous connecter à l’écouteur du groupe de disponibilité autonome avant d’effectuer une sauvegarde.

Chiffrement transparent des données (TDE)

Pour utiliser le chiffrement transparent des données (TDE) avec des bases de données dans un groupe de disponibilité contenu, installez manuellement la clé maîtresse de base de données (DMK) dans la base de données master contenue au sein du groupe de disponibilité contenu.

Les bases de données qui utilisent TDE s'appuient sur des certificats dans la base de données master pour déchiffrer la clé de chiffrement de la base de données (DEK). Sans ce certificat, SQL Server ne peut pas déchiffrer les bases de données chiffrées avec TDE ni les mettre en ligne. Dans un groupe de disponibilité contenu, SQL Server vérifie à la fois les bases de données master pour la DMK, la base de données master pour l'instance, et la base de données contenue master au sein du groupe de disponibilité contenu pour déchiffrer la base de données. S’il ne trouve pas le certificat à l’un ou l’autre emplacement, SQL Server ne peut pas mettre la base de données en ligne.

Pour transférer la clé principale de base de données (DMK) de la base de données master de l’instance vers la base de données master autonome, consultez Déplacer une base de données protégée par le chiffrement transparent des données (TDE) vers un autre serveur SQL Server, en vous concentrant principalement sur les parties où la clé principale de base de données (DMK) est transférée de l’ancien serveur vers le nouveau.

Packages SSIS et plans de maintenance

L’utilisation des packages SSIS, y compris les plans de maintenance, n’est pas prise en charge avec les groupes de disponibilité autonomes.

Non pris en charge

Actuellement, les fonctionnalités SQL Server suivantes ne sont pas prises en charge pour un groupe de disponibilité autonome :

  • Réplication SQL Server de n’importe quel type (transactionnelle, par fusion, via instantané, etc.).
  • Groupes de disponibilité distribués.
  • Copie des journaux de transaction où se trouve la base de données cible dans le groupe de disponibilité autonome. La copie des journaux de transaction pour la base de données source dans le groupe de disponibilité autonome est prise en charge.

Modifications du langage de définition de données (DDL)

Les modifications DDL concernent uniquement le flux de travail CREATE AVAILABILITY GROUP. Il existe deux nouvelles clauses WITH :

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

CONTAINED

Cela spécifie que le groupe de disponibilité en cours de création doit être autonome.

REUSE_SYSTEM_DATABASES

Cette option est valide uniquement pour les groupes de disponibilité autonomes et spécifie que le groupe de disponibilité nouvellement créé doit réutiliser les bases de données système autonomes existantes pour un groupe de disponibilité autonome précédent du même nom. Par exemple, si vous aviez un groupe de disponibilité autonome portant le nom MyContainedAG et que vous souhaitez le supprimer et le recréer, vous pouvez utiliser cette option pour réutiliser le contenu des bases de données système autonomes d’origine.

Modifications de la vue de gestion dynamique

Il existe deux ajouts aux vues de la gestion dynamique liés aux groupes de sécurité autonomes :

  • Le sys.dm_exec_sessions DMV a une nouvelle colonne ajoutée : contained_availability_group_id
  • Une colonne sys.availability_groups a été ajoutée à la vue catalogue : is_contained

Contenu connexe