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 de bases de données se déplace en tant qu’unité vers un autre nœud de réplica du groupe de disponibilité. Toutes les bases de données utilisateur restent synchronisées sur toutes les répliques du groupe de disponibilité, en mode synchrone ou asynchrone.

Cette architecture fonctionne bien pour les applications qui interagissent uniquement avec cet ensemble de bases de données utilisateur. Toutefois, les défis surviennent lorsque les applications s’appuient également sur des objets tels que des utilisateurs, des connexions, des autorisations, des travaux d’agent et d’autres objets stockés dans l’une des bases de données système (master ou msdb). Pour garantir 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éplicat du groupe de disponibilité. Si vous ajoutez une nouvelle instance au groupe de disponibilité, vous pouvez amorcer les bases de données automatiquement ou manuellement de manière simple. Toutefois, vous devez reconfigurer toutes les personnalisations de base de données système sur la nouvelle instance pour qu’elles correspondent 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 AG contenu inclut des paramètres qui affectent l'application qui en dépend. 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.

Ce concept diffère des bases de données autonomes, qui utilisent un mécanisme différent pour les comptes d’utilisateur, en stockant les informations utilisateur dans 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é isolé, vous créez des utilisateurs, des connexions, des autorisations, et ainsi de suite, au niveau du groupe de disponibilité. Ces objets sont automatiquement cohérents entre les réplicas du groupe de disponibilité, ainsi qu'entre les bases de données au sein de ce groupe de disponibilité contenu. Cette cohérence évite à l’administrateur de devoir 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

Lorsque vous travaillez avec des groupes de sécurité autonomes, tenez compte de quelques différences pratiques. Ces différences incluent la création de bases de données système contenues et forcer la connexion au niveau du groupe de disponibilité contenu au lieu de se connecter 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 répliquées automatiquement vers de nouveaux réplicas, et les mises à jour sont appliquées à ces bases de données comme pour n'importe quelle autre base de données dans des groupes de disponibilité. Lorsque vous ajoutez un objet tel qu’une connexion ou un travail d’agent lors de la connexion au groupe de disponibilité contenu, vous voyez toujours les travaux de l'agent et pouvez vous authentifier à l'aide de la connexion créée dans le groupe de disponibilité contenu lorsque celui-ci bascule 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 aucune limite qui empêche une connexion à un groupe de disponibilité autonome d’accéder aux 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 à partir de l’instance où vous exécutez la CREATE AVAILABILITY GROUP commande. Ils sont initialement vides sans aucune donnée. Immédiatement après sa création, le processus copie les comptes d’administrateur sur l'instance, créant ainsi le groupe de disponibilité contenu master. Ainsi, l'administrateur peut se connecter au groupe de disponibilité « contenu » et paramétrer le reste des réglages.

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 que la base de données utilisateur rejoint un groupe de disponibilité contenu, ces utilisateurs perdent immédiatement accès. 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 sysadmin dans l’instance parente sont copiées dans la nouvelle base de données spécifique au groupe de disponibilité master lors de la création d’un groupe de disponibilité contenu.

Remarque

Étant donné que la master base de données est distincte pour chaque groupe de disponibilité contenu, les activités à l'échelle du serveur effectuées dans le contexte du groupe de disponibilité contenu persistent uniquement dans la base de données système contenue. Cette règle 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 de données initiale

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

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 Nouvel groupe de disponibilité dans SQL Server Management Studio, incluez uniquement 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), attendez 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 et ajouter ultérieurement des bases de données utilisateur, 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 :

1. Supprimez le groupe de disponibilité autonome.

2. Restaurez les bases de données master et msdb contenues sur le réplica principal d'origine du groupe de disponibilité contenu.

3. Supprimez les bases de données contenues master et msdb des réplicas secondaires.

4. 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 vous spécifiez REUSE_SYSTEM_DATABASES. 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 est une base de données dans le groupe de disponibilité contenu avec lequel vous souhaitez interagir.

Vous devez créer un écouteur pour le groupe de disponibilité contenu afin d'utiliser efficacement ce dernier. 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. Vous êtes soumis au contenu (utilisateurs, autorisations, travaux, et ainsi de suite) 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 configurez le routage en lecture seule pour rediriger les connexions avec l’intention de lecture vers un réplica secondaire (consultez 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é contenue (AG), il existe d’autres considérations :

• Vous devez spécifier une base de données qui fait partie du groupe de disponibilité contenu 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, AdventureWorks est une base de données dans le groupe de disponibilité contenu qui a MyContainedListener, et MyUser est un utilisateur défini dans le groupe de disponibilité contenu et n'appartient à aucune des instances participantes :

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

Cet exemple vous connecte à la base de données secondaire lisible qui fait partie de la configuration de routage en lecture seule et vous place dans le contexte du groupe de disponibilité conteneurisé.

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

Tenez compte d'autres facteurs lors de l'utilisation de certaines fonctionnalités avec des groupes de disponibilité contenus. Certaines fonctionnalités ne sont actuellement pas prises en charge.

Sauvegarder

Les procédures de sauvegarde des bases de données dans des groupes de disponibilité conteneurs (AG) sont identiques à celles des sauvegardes de bases de données utilisateur. Cette instruction est vraie pour les bases de données utilisateur du groupe de disponibilité contenue et les bases de données système du groupe de disponibilité contenue.

Si vous utilisez un emplacement de sauvegarde 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 vous utilisez une ressource réseau pour l’emplacement de sauvegarde, tous les serveurs qui hébergent des réplicas doivent accéder à cette ressource.

Activer la création ou la restauration de base de données dans des sessions de groupe de disponibilité autonomes

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

Dans SQL Server 2025 (17.x) Mise à jour cumulative (CU) 1, vous pouvez activer la création et la restauration de base de données directement dans une session de groupe de disponibilité autonome, via l’écouteur de groupe de disponibilité autonome. Cette amélioration simplifie les flux de travail pour les utilisateurs affectés aux rôles appropriés, ce qui permet des opérations transparentes dans les environnements AG conteneurisés.

Seuls les utilisateurs disposant du rôle dbcreator peuvent créer des bases de données dans une session de groupe de disponibilité autonome. Seuls les utilisateurs disposant du rôle db_owner ou sysadmin peuvent restaurer des bases de données.

L’exemple suivant active la fonctionnalité de votre session à l’aide de la clé allow_cag_create_db de contexte de session dans la sp_set_session_contex procédure stockée. Pour le désactiver, définissez @value sur 0.

EXECUTE sp_set_session_context
    @key = N'allow_cag_create_db',
    @value = 1;

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

S’applique à : SQL Server 2022 (16.x) CU 18 et versions ultérieures.

Dans SQL Server 2022 (16.x) avant la mise à jour cumulative (CU) 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.

Dans SQL Server 2022 (16.x) CU 18 et versions ultérieures, 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

Vous devez utiliser la même configuration du contrôleur de ressources 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 lors des basculements de groupes de disponibilité.

Pour plus d’informations, consultez Resource Governor et Tutoriel : Exemples de configuration resource governor et meilleures pratiques.

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

Vous pouvez configurer la copie des journaux de transaction 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, vous devez modifier la tâche de log shipping après avoir configuré le CDC.

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. Après avoir configuré le travail d'expédition de journaux, modifiez le travail pour vous connecter à l'écouteur de groupe de disponibilité contenu (AG) 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 dans l’un ou l’autre emplacement, SQL Server ne peut pas mettre la base de données en ligne.

Pour transférer le DMK de la base de données de l’instance master vers la base de données autonome master , consultez Déplacer une base de données protégée par TDE vers un autre serveur SQL Server, principalement en se concentrant sur les parties où le DMK est transféré 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 et plans de maintenance SSIS

L’utilisation de packages SSIS, y compris les plans de maintenance, n’est pas prise en charge avec des 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.

Prise en charge DDL

Dans le flux de travail CREATE AVAILABILITY GROUP , il existe une WITH clause avec plusieurs options :

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

CONTAINED

Cette option spécifie que le groupe de disponibilité que vous créez est un groupe de disponibilité contenu.

REUSE_SYSTEM_DATABASES

L’option REUSE_SYSTEM_DATABASES n’est valide que pour les groupes de disponibilité. Il spécifie que le nouveau groupe de disponibilité (AG) doit réutiliser les bases de données système contenues existantes d’un groupe de disponibilité antérieur portant le même nom. Par exemple, si vous aviez un groupe de disponibilité contenu nommé MyContainedAG et que vous souhaitiez le supprimer et le recréer, vous pouvez utiliser cette option afin de réutiliser le contenu des bases de données système initialement contenues. 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 souhaitez 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.

Prise en charge des objets système pour les groupes de disponibilité contenus

Deux vues système incluent des ajouts liés aux groupes de disponibilité contenus.

• La vue de gestion dynamique sys.dm_exec_sessions inclut une contained_availability_group_id colonne.
• L’affichage catalogue sys.availability_groups inclut la is_contained colonne.

Contenu connexe

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