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

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.

Modifications de SQL Server 2025

SQL Server 2025 (17.x) introduit la prise en charge des groupes de disponibilité distribués pour les groupes de disponibilité autonomes.

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.

Importante

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 à cela est que toutes les connexions relevant du rôle sysadmin dans l’instance parente sont copiées dans la nouvelle base de données master spécifique au groupe de disponibilité lors de la création d’un groupe de disponibilité contenu.

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.

Synchronisation initiale des données

Les bases de données système contenues prennent uniquement en charge l’amorçage automatique comme méthode de synchronisation de données initiale.

Dans SQL Server 2022 (16.x) et les versions antérieures, les groupes de disponibilité autonomes doivent utiliser l’amorçage automatique lors de la création. Lorsque vous utilisez l'instruction CREATE AVAILABILITY GROUP ou l'Assistant Nouveau Groupe de Disponibilité dans SQL Server Management Studio, n'incluez que les bases de données utilisateur qui prennent en charge l'amorçage automatique. Pour ajouter des bases de données volumineuses à l’aide de l’amorçage manuel (JOIN ONLY), patientez jusqu’à ce que le groupe de disponibilité contenu soit créé.

Dans SQL Server 2025 (17.x), les bases de données système autonomes utilisent toujours l’amorçage automatique, même si l’instruction CREATE AVAILABILITY GROUP spécifie l’amorçage manuel. Vous pouvez définir le mode d'amorçage sur manuel pour créer un groupe de disponibilité contenu, puis ajouter ultérieurement des bases de données utilisateurs en utilisant des méthodes de synchronisation autres que l'amorçage automatique.

Restaurer une base de données système autonome

Pour restaurer des sauvegardes de bases de données système contenues, procédez comme suit :

Supprimez le groupe de disponibilité autonome.
Restaurez les bases de données master et msdb contenues sur le réplica principal d'origine du groupe de disponibilité contenu.
Supprimez les bases de données master et msdb contenues des réplicas secondaires.
Sur le réplica principal, recréez le groupe de disponibilité contenu en utilisant le nom et les nœuds d'origine, avec la syntaxe WITH (CONTAINED, REUSE_SYSTEM_DATABASES) et SEEDING_MODE = AUTOMATIC.

Lors de la recréation d’un groupe de disponibilité limité, n’incluez pas de bases de données système limitées dans l’instruction CREATE AVAILABILITY GROUP . SQL Server les détecte automatiquement lorsque REUSE_SYSTEM_DATABASES est spécifié. Dans SQL Server 2022 (16.x) et les versions antérieures, incluez uniquement de petites bases de données utilisateur qui prennent en charge l’amorçage automatique. Ajoutez des bases de données volumineuses séparément après la création du groupe de disponibilité contenu, à l’aide de JOIN ONLY.

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.

Groupes de disponibilité distribués

Un groupe de disponibilité distribué est un type spécial de groupe de disponibilité qui s’étend sur deux groupes de disponibilité sous-jacents. Lorsque vous configurez un groupe de disponibilité distribué, les modifications apportées sur le serveur principal global (qui est le réplica principal de votre premier groupe de disponibilité) sont ensuite répliquées vers le réplica principal de votre deuxième groupe de disponibilité, appelé redirecteur.

À compter de SQL Server 2025 (17.x), vous pouvez configurer un groupe de disponibilité distribué entre deux groupes de disponibilité autonomes. Étant donné qu'un groupe de disponibilité contenu s'appuie sur des bases de données système master et msdb contenues, pour créer un groupe de disponibilité distribué, le deuxième groupe de disponibilité (redirecteur) doit avoir la même base de données système de groupe de disponibilité contenu que le principal global.

Si vous envisagez d’utiliser un groupe de disponibilité contenu comme redirecteur dans un groupe de disponibilité distribué, vous devez créer le groupe de disponibilité contenu à l’aide de la clause AUTOSEEDING_SYSTEM_DATABASES pour l’option WITH | CONTAINED de l’instruction CREATE AVAILABILITY GROUP. La clause AUTOSEEDING_SYSTEM_DATABASES indique à SQL Server d’ignorer la création de ses propres bases de données système de groupe de disponibilité contenu, et d'initialiser les bases de données système de groupe de disponibilité contenu à partir du principal global.

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 :

Connectez-vous à l’écouteur du groupe de disponibilité autonome.
Configurez la copie des journaux de transaction comme vous le feriez normalement.
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.

Remarque

Le chiffrement de n’importe quelle base de données sur une instance SQL Server chiffre également la tempdb base de données système.

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.).
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 seules modifications DDL se trouvent dans le flux de travail CREATE AVAILABILITY GROUP. Il existe une WITH clause avec deux options :

<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]

CONTAINED

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

REUSE_SYSTEM_DATABASES

L’option REUSE_SYSTEM_DATABASES n’est valide que 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é contenu 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. Lorsque vous utilisez cette option, ne spécifiez pas de noms de base de données système. SQL Server les détecte automatiquement.

AUTOSEEDING_SYSTEM_DATABASES

S’applique à : SQL Server 2025 (17.x) et versions ultérieures

Si vous envisagez d’utiliser votre groupe de disponibilité autonome comme redirecteur dans un groupe de disponibilité distribué, vous devez utiliser l’option AUTOSEEDING_SYSTEM_DATABASES lorsque vous créez le groupe de disponibilité autonome. Cette option indique à SQL Server d’ignorer la création de ses propres bases de données système de groupe de disponibilité contenu, et d'initialiser les bases de données système de groupe de disponibilité contenu à partir du principal global.

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

CRÉER UN GROUPE DE DISPONIBILITÉ (Transact-SQL)

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2025-06-27