MODIFIER LE GROUPE DE DISPONIBILITÉ (Transact-SQL)

S'applique à :SQL Server

Modifie un groupe de disponibilité Always On existant dans SQL Server. La plupart des arguments ALTER AVAILABILITY GROUP ne sont pris en charge que par le réplica principal actuel. Toutefois, les arguments JOIN, FAILOVER et FORCE_FAILOVER_ALLOW_DATA_LOSS, ne sont pris en charge que sur les réplicas secondaires.

Conventions de la syntaxe Transact-SQL

Syntaxe

  
ALTER AVAILABILITY GROUP group_name   
  {  
     SET ( <set_option_spec> )   
   | ADD DATABASE database_name   
   | REMOVE DATABASE database_name  
   | ADD REPLICA ON <add_replica_spec>   
   | MODIFY REPLICA ON <modify_replica_spec>  
   | REMOVE REPLICA ON <server_instance>  
   | JOIN  
   | JOIN AVAILABILITY GROUP ON <add_availability_group_spec> [ ,...2 ]  
   | MODIFY AVAILABILITY GROUP ON <modify_availability_group_spec> [ ,...2 ]  
   | GRANT CREATE ANY DATABASE  
   | DENY CREATE ANY DATABASE  
   | FAILOVER  
   | FORCE_FAILOVER_ALLOW_DATA_LOSS   
   | ADD LISTENER 'dns_name' ( <add_listener_option> )  
   | MODIFY LISTENER 'dns_name' ( <modify_listener_option> )  
   | RESTART LISTENER 'dns_name'  
   | REMOVE LISTENER 'dns_name'  
   | OFFLINE  
  }  
[ ; ]  
  
<set_option_spec> ::=   
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }  
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 }   
  | HEALTH_CHECK_TIMEOUT = milliseconds  
  | DB_FAILOVER  = { ON | OFF }   
  | DTC_SUPPORT  = { PER_DB | NONE }  
  | REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = { integer }
  | ROLE = SECONDARY
  | CLUSTER_CONNECTION_OPTIONS = 'key_value_pairs>[;...]'
  
<server_instance> ::=   
 { 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }  
  
<add_replica_spec>::=  
  <server_instance> WITH  
    (  
       ENDPOINT_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },  
       FAILOVER_MODE = { AUTOMATIC | MANUAL }   
       [ , <add_replica_option> [ ,...n ] ]  
    )   
  
  <add_replica_option>::=  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
     | BACKUP_PRIORITY = n  
     | SECONDARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ]   
        [,] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]  
     } )  
     | PRIMARY_ROLE ( {   
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ]   
        [,] [ READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE } ]  
        [,] [ READ_WRITE_ROUTING_URL = 'TCP://system-address:port' ]
     } )  
     | SESSION_TIMEOUT = integer
  
<modify_replica_spec>::=  
  <server_instance> WITH  
    (    
       ENDPOINT_URL = 'TCP://system-address:port'   
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }   
     | FAILOVER_MODE = { AUTOMATIC | MANUAL }   
     | SEEDING_MODE = { AUTOMATIC | MANUAL }   
     | BACKUP_PRIORITY = n  
     | SECONDARY_ROLE ( {   
          [ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }  ] 
        | [READ_ONLY_ROUTING_URL = {'TCP://system-address:port' | NONE} ]  
          } )  
     | PRIMARY_ROLE ( {   
          [ALLOW_CONNECTIONS = { READ_WRITE | ALL }   ]
        | [READ_ONLY_ROUTING_LIST = { ( '<server_instance>' [ ,...n ] ) | NONE } ] 
        | [READ_WRITE_ROUTING_URL = { 'TCP://system-address:port' | NONE }  ]
          } )  
     | SESSION_TIMEOUT = seconds  
    )   
  
<add_availability_group_spec>::=  
 <ag_name> WITH  
    (  
       LISTENER_URL = 'TCP://system-address:port',  
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },  
       FAILOVER_MODE = MANUAL,  
       SEEDING_MODE = { AUTOMATIC | MANUAL }  
    )  
  
<modify_availability_group_spec>::=  
 <ag_name> WITH  
    (  
       LISTENER = 'TCP://system-address:port'  
       | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }  
       | SEEDING_MODE = { AUTOMATIC | MANUAL }  
    )  
  
<add_listener_option> ::=  
   {  
      WITH DHCP [ ON ( <network_subnet_option> ) ]  
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]  
   }  
  
  <network_subnet_option> ::=  
     'ipv4_address', 'ipv4_mask'    
  
  <ip_address_option> ::=  
     {   
        'four_part_ipv4_address', 'four_part_ipv4_mask'  
      | 'ipv6_address'  
     }  
  
<modify_listener_option>::=  
    {  
       ADD IP ( <ip_address_option> )   
     | PORT = listener_port  
     | REMOVE IP ( 'ipv4_address' | 'ipv6_address')
    }

Les arguments

group_name

Spécifie le nom du nouveau groupe de disponibilité. group_name doit être un identificateur SQL Server valide et doit être unique parmi tous les groupes de disponibilité du cluster WSFC.

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDAIRE | NONE }

Spécifie une préférence sur la manière dont un travail de sauvegarde doit évaluer le réplica principal lorsqu'on choisit où effectuer des sauvegardes. Vous pouvez écrire un travail de sauvegarde donné pour prendre en compte la préférence de sauvegarde automatisée. Il est important de comprendre que la préférence n’est pas appliquée par SQL Server. Elle n’a donc aucun impact sur les sauvegardes ad hoc.

Pris en charge uniquement sur le réplica principal.

Les valeurs sont les suivantes :

PRIMAIRE

Spécifie que les sauvegardes doivent toujours avoir lieu sur le réplica principal. Cette option est utile si vous avez besoin de fonctionnalités de sauvegarde, telles que la création de sauvegardes différentielles, qui ne sont pas prises en charge lors de l’exécution de la sauvegarde sur un réplica secondaire.

Important

Si vous envisagez d’utiliser la copie de journaux de transaction pour préparer des bases de données secondaires pour un groupe de disponibilité, définissez la préférence de sauvegarde automatisée sur Principal jusqu’à ce que toutes les bases de données secondaires aient été préparées et attachées au groupe de disponibilité.

SECONDARY_ONLY

Spécifie que les sauvegardes ne doivent jamais être effectuées sur le réplica principal. Si la réplique principale est la seule réplique en ligne, la sauvegarde ne devrait pas avoir lieu.

SECONDAIRE

Spécifie que les sauvegardes doivent se produire sur un réplica secondaire sauf lorsque le réplica principal est le seul réplica en ligne. Dans ce cas, la sauvegarde doit se produire sur le réplica principal. Il s'agit du comportement par défaut.

Aucune

Spécifie que vous préférez que les travaux de sauvegarde ignorent le rôle des réplicas de disponibilité lorsque vous choisissez le réplica pour effectuer les sauvegardes. Notez que les travaux de sauvegarde peuvent évaluer d'autres facteurs tels que la priorité de sauvegarde de chaque réplica de disponibilité en association avec son état opérationnel et son état connecté.

Important

Il n’existe aucune application du paramètre AUTOMATED_BACKUP_PREFERENCE. La traduction de cette préférence dépend de la logique, le cas échéant, que vous avez écrite dans les travaux de sauvegarde pour les bases de données dans un groupe de disponibilité donné. Le paramètre de préférence de sauvegarde automatisée n’a aucun impact sur les sauvegardes ad-hoc. Pour plus d’informations, consultez Configurer la sauvegarde sur des réplicas de disponibilité (SQL Server).

Notes

Pour voir la préférence de sauvegarde automatisée d’un groupe de disponibilité existant, sélectionnez la colonne automated_backup_preference ou automated_backup_preference_desc de la vue de catalogue sys.availability_groups. De plus, vous pouvez utiliser sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) pour déterminer le réplica de sauvegarde par défaut. Cette fonction renverra toujours 1 pour au moins l'un des réplicas, même avec AUTOMATED_BACKUP_PREFERENCE = NONE.

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

Spécifie les conditions d'échec qui déclencheront un basculement automatique pour ce groupe de disponibilité. FAILURE_CONDITION_LEVEL est défini au niveau du groupe, mais s’applique uniquement aux réplicas de disponibilité configurés pour le mode de disponibilité de validation synchrone (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). En outre, les conditions d’échec ne peuvent déclencher un basculement automatique que si les réplicas principaux et secondaires sont configurés pour le mode de basculement automatique (FAILOVER_MODE = AUTOMATIC), et si le réplica secondaire est actuellement synchronisé avec le réplica principal.

Pris en charge uniquement sur le réplica principal.

Les niveaux de condition d’échec (1-5) s’étendent du moins restrictif, le niveau 1, au plus restrictif, le niveau 5. Un niveau de condition donné comprend tous les niveaux moins restrictifs. Par conséquent, le niveau de condition le plus strict, le niveau 5, inclut les quatre niveaux de condition moins restrictifs (1 à 4), le niveau 4 inclut les niveaux 1 à 3, et ainsi de suite. Le tableau suivant décrit la condition d'échec qui correspond à chaque niveau.

Niveau	Condition d'échec
1	Spécifie qu'un basculement automatique doit être initialisé lorsque l'une des conditions suivantes se produit : Le service SQL Server est fermé. Le bail du groupe de disponibilité pour la connexion au cluster WSFC expire car aucun accusé de réception n'est reçu de l'instance de serveur. Pour plus d’informations, consultez How It Works: SQL Server Always On Lease Timeout.
2	Spécifie qu'un basculement automatique doit être initialisé lorsque l'une des conditions suivantes se produit : L’instance de SQL Server ne se connecte pas au cluster et le seuil de HEALTH_CHECK_TIMEOUT spécifié par l’utilisateur du groupe de disponibilité est dépassé. Le réplica de disponibilité est dans un état d'échec.
3	Spécifie qu'un basculement automatique doit être initialisé sur les erreurs internes critiques SQL Server, telles que les verrouillages spinlock orphelins, les violations graves d'accès en écriture, ou en cas de vidages trop importants. Il s'agit du comportement par défaut.
4	Spécifie qu'un basculement automatique doit être initialisé sur les erreurs internes modérées SQL Server, telles qu'une condition persistante de mémoire insuffisante dans le pool de ressources interne SQL Server.
5	Spécifie qu'un basculement automatique doit être initialisé sur tous les états d'échec qualifiés, notamment : Insuffisance des threads de travail du moteur SQL. Détection d'un blocage insoluble.

Notes

L’absence de réponse par une instance de SQL Server aux demandes clientes n’est pas pertinente pour les groupes de disponibilité.

Les valeurs de FAILURE_CONDITION_LEVEL et de HEALTH_CHECK_TIMEOUT définissent une stratégie de basculement souple pour un groupe donné. Cette stratégie de basculement souple vous offre un contrôle granulaire sur les conditions qui doivent entraîner un basculement automatique. Pour plus d’informations, consultez Stratégie de basculement flexible pour le basculement automatique d’un groupe de disponibilité (SQL Server).

HEALTH_CHECK_TIMEOUT = millisecondes

Spécifie le temps d’attente (en millisecondes) nécessaire pour que la procédure stockée système sp_server_diagnostics retourne les informations d’intégrité du serveur avant que le cluster WSFC ne suppose que l’instance de serveur est lente ou ne répond pas. HEALTH_CHECK_TIMEOUT est défini au niveau du groupe, mais s’applique uniquement aux réplicas de disponibilité configurés pour le mode de disponibilité de validation synchrone avec basculement automatique (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). De plus, l’expiration d’un délai de contrôle d’intégrité peut déclencher un basculement automatique uniquement si les réplicas principaux et secondaires sont configurés pour le mode de basculement automatique (FAILOVER_MODE = AUTOMATIC) et si le réplica secondaire est synchronisé avec le réplica principal.

La valeur par défaut de HEALTH_CHECK_TIMEOUT est de 30 000 millisecondes (30 secondes). La valeur minimale est de 15 000 millisecondes (15 secondes) et la valeur maximale est de 4 294 967 295 millisecondes.

Pris en charge uniquement sur le réplica principal.

Important

sp_server_diagnostics n’effectue pas de vérifications d’intégrité au niveau de la base de données.

DB_FAILOVER = { LE | DÉSACTIVÉ }

Spécifie la réponse à prendre lorsqu’une base de données sur le réplica principal est hors connexion. Quand cette option est définie sur ON, n’importe quel état autre qu’ONLINE d’une base de données du groupe de disponibilité déclenche un basculement automatique. Quand cette option est définie sur OFF, seule l’intégrité de l’instance est utilisée pour déclencher un basculement automatique.

Pour plus d’informations sur ce paramètre, consultez Option de détection de l’état d’intégrité au niveau base de données

= DTC_SUPPORT { PER_DB | AUCUN }

Spécifie si les transactions distribuées sont activées pour ce groupe de disponibilité. Les transactions distribuées sont uniquement prises en charge pour les bases de données de groupe de disponibilité à compter de SQL Server 2016 (13.x), et les transactions entre bases de données sont uniquement prises en charge dans SQL Server 2016 (13.x) SP2. PER_DB crée le groupe de disponibilité avec prise en charge de ces transactions et promeut automatiquement les transactions inter-bases de données impliquant des bases de données dans le groupe de disponibilité en transactions distribuées. NONE empêche la promotion automatique des transactions entre bases de données vers des transactions distribuées et n’inscrit pas la base de données avec un RMID stable dans DTC. Les transactions distribuées ne sont pas empêchées lorsque le NONE paramètre est utilisé, mais le basculement de base de données et la récupération automatique peuvent ne pas réussir dans certaines circonstances. Pour plus d’informations, consultez Transactions entre bases de données et transactions distribuées pour des groupes de disponibilité Always On et la mise en miroir de bases de données (SQL Server).

Notes

La prise en charge de la modification du paramètre DTC_SUPPORT d’un groupe de disponibilité a été introduite dans SQL Server 2016 (13.x) Service Pack 2. Cette option ne peut pas être utilisée avec les versions antérieures. Pour modifier ce paramètre dans les versions antérieures de SQL Server, vous devez supprimer puis recréer le groupe de disponibilité.

Important

DTC a une limite de 32 pour les inscriptions par transaction distribuée. Étant donné que chaque base de données au sein d’un groupe de disponibilité s’inscrit auprès du DTC séparément, si votre transaction implique plus de 32 bases de données, vous pouvez obtenir l’erreur suivante lorsque SQL Server tente d’inscrire la 33e base de données :

Enlist operation failed: 0x8004d101(XACT_E_TOOMANY_ENLISTMENTS). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Pour plus d’informations sur les transactions distribuées dans SQL Server, consultez Transactions distribuées.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Introduit dans SQL Server 2017 (14.x). Définit un nombre minimal de réplicas secondaires synchrones nécessaires à la validation avant que le réplica principal valide une transaction. Garantit que les transactions SQL Server attendent jusqu’à ce que les journaux des transactions soient mis à jour avec le nombre minimal de réplicas secondaires.

Valeur par défaut : 0. Fournit le même comportement que SQL Server 2016 (13.x).
Minimum : 0.
Maximum : nombre de réplicas moins 1.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT est lié aux réplicas en mode de validation synchrone. Quand les réplicas sont en mode de validation synchrone, les écritures sur le réplica principal attendent jusqu’à ce que les écritures sur les réplicas synchrones soient validées dans le journal des transactions de la base de données de réplica. Si un SQL Server qui héberge un réplica synchrone secondaire cesse de répondre, le SQL Server qui héberge le réplica principal marque ce réplica secondaire comme NOT SYNCHRONIZED et poursuit l’opération. Quand la base de données qui ne répond pas est de nouveau en ligne, elle est dans un état « non synchronisé » et le réplica est marqué comme non sain jusqu’à ce que le réplica principal puisse le synchroniser à nouveau. Ce paramètre garantit que le réplica principal ne se poursuit pas tant que le nombre minimal de réplicas n’a pas validé chaque transaction. Si le nombre minimal de réplicas n’est pas disponible, les validations sur le réplica principal échouent. Pour le type de cluster EXTERNAL, le paramètre est modifié quand le groupe de disponibilité est ajouté à une ressource de cluster. Consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.

À compter de SQL Server 2022 (16.x), vous pouvez définir le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT sur un groupe de disponibilité distribué. Ce paramètre n’est pas pris en charge pour CREATE AVAILABILITY GROUP. Vous pouvez utiliser ALTER AVAILABILITY GROUP pour définir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Par exemple :

ALTER AVAILABILITY GROUP [<name>] 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = <integer>);

RÔLE

Le seul paramètre valide est « SECONDARY ». Cette option SET est valide uniquement dans les groupes de disponibilité distribués. Il est utilisé pour basculer un groupe de disponibilité distribué comme indiqué ici : ALTER AVAILABILITY GROUP

CLUSTER_CONNECTION_OPTIONS

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

Utilisez la clause pour appliquer le CLUSTER_CONNECTION_OPTIONS chiffrement TLS 1.3 pour la communication entre le cluster de basculement Windows Server et vos réplicas de groupe de disponibilité. Les options sont spécifiées sous la forme d’une liste de paires clé-valeur, séparées par des points-virgules. Les paires clé-valeur sont utilisées pour configurer le chiffrement de chaîne de connexion pour le groupe de disponibilité.

Pour revenir au chiffrement par défaut, définissez la CLUSTER_CONNECTION_OPTIONS clause sur une chaîne vide. SQL Server 2025 (17.x) Préversion par Encrypt=Mandatorydéfaut et TrustServerCertificate=Yes pour les connexions aux réplicas et écouteurs du groupe de disponibilité.

Pour plus d’informations, consultez la connexion à un groupe de disponibilité avec un chiffrement strict et TDS 8.0.

Le tableau suivant décrit les paires clé-valeur que vous pouvez utiliser dans la CLUSTER_CONNECTION_OPTIONS clause :

Key	Valeurs prises en charge	Descriptif
`Encrypt`	`Mandatory` `Strict` `Optional`	Spécifie comment le chiffrement du groupe de disponibilité est appliqué. Si le serveur ne prend pas en charge le chiffrement, la connexion échoue. Si le chiffrement est défini `Mandatory`sur , il `TrustServerCertificate` doit être défini sur oui. Si le chiffrement est défini `Strict` sur ce `TrustServerCertificate` paramètre, il est ignoré. Cette paire de valeurs de clé est requise.
`HostNameInCertificate`	Nom du réplica ou nom de l’écouteur du groupe de disponibilité	Spécifie le nom du réplica ou le nom de l’écouteur du groupe de disponibilité dans le certificat utilisé pour le chiffrement. Cette valeur doit correspondre à la valeur dans l’autre nom de l’objet du certificat. Si le nom du serveur est répertorié dans le certificat, vous pouvez omettre la `HostNameInCertificate` paire clé-valeur. Si le nom du serveur n’est pas répertorié dans le certificat, vous devez spécifier la `HostNameInCertificate` paire clé-valeur avec le nom du serveur. Cette paire de valeurs de clé est facultative.*
`TrustServerCertificate`	`Yes`, `No`	Défini pour `yes` spécifier que le pilote ne valide pas le certificat TLS/SSL du serveur. Si `no`, le pilote valide le certificat. Pour plus d’informations, consultez TDS 8.0. Cette paire de valeurs de clé est facultative.*
`ServerCertificate`	Chemin d’accès à votre certificat	Si vous ne souhaitez pas utiliser `HostNameInCertificate`, vous pouvez passer le chemin d’accès à votre certificat. Le compte de service de cluster doit avoir l’autorisation de lire le certificat à partir de l’emplacement donné. Cette paire de valeurs de clé est facultative.
`CLUSTER_CONNECTION_OPTIONS`	Chaîne vide (`''`)	Efface la configuration existante et rétablit les paramètres de chiffrement par défaut de `Encrypt=Mandatory` et `TrustServerCertificate=Yes`.

Consultez les exemples pour apprendre à utiliser la CLUSTER_CONNECTION_OPTIONS clause.

AJOUTER UNE BASE DE DONNÉES database_name

Spécifie une liste d'une ou de plusieurs bases de données utilisateur que vous souhaitez ajouter au groupe de disponibilité. Ces bases de données doivent résider sur l'instance de SQL Server qui héberge le réplica principal actuel. Vous pouvez spécifier plusieurs bases de données pour un groupe de disponibilité, mais chaque base de données ne peut appartenir qu'à un seul groupe de disponibilité. Pour plus d’informations sur le type de bases de données que les groupes de disponibilité peuvent prendre en charge, consultez Prérequis, restrictions et recommandations pour les groupes de disponibilité Always On (SQL Server). Pour connaître les bases de données locales qui appartiennent déjà à un groupe de disponibilité, consultez la colonne replica_id dans l’affichage catalogue sys.databases.

Pris en charge uniquement sur le réplica principal.

Notes

Une fois que vous avez créé le groupe de disponibilité, vous devez vous connecter à chaque instance de serveur qui héberge un réplica secondaire, puis préparer chaque base de données secondaire et la joindre au groupe de disponibilité. Pour plus d’informations, consultez Démarrer un déplacement de données sur une base de données secondaire Always On (SQL Server).

SUPPRIMER LA BASE DE DONNÉES database_name

Supprime la base de données primaire spécifiée et les bases de données secondaires correspondantes du groupe de disponibilité. Pris en charge uniquement sur le réplica principal.

Pour plus d’informations sur les étapes recommandées après la suppression d’une base de données de disponibilité d’un groupe de disponibilité, consultez Supprimer une base de données primaire d’un groupe de disponibilité (SQL Server).

AJOUTER UNE RÉPLIQUE SUR

Spécifie entre une et huit instances SQL Server pour l'hébergement des réplicas secondaires dans un groupe de disponibilité. Chaque réplica est spécifié par l’adresse de son instance de serveur suivie d’une clause WITH (...).

Pris en charge uniquement sur le réplica principal.

Vous devez joindre chaque nouveau réplica secondaire au groupe de disponibilité. Pour plus d'informations, consultez la description de l'option JOIN ultérieurement dans cette section.

<server_instance>

Spécifie l'adresse de l'instance de SQL Server qui est l'hôte d'un réplica. Le format d’adresse varie selon que l’instance est l’instance par défaut ou une instance nommée et s’il s’agit d’une instance autonome ou d’une instance de cluster de basculement (FCI). La syntaxe est la suivante :

{ 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

Les composants de cette adresse sont les suivants :

nom_système

Nom NetBIOS du système informatique sur lequel réside l’instance cible de SQL Server. Cet ordinateur doit être un nœud WSFC.

nom_réseau_FCI

Nom réseau utilisé pour accéder à un cluster de basculement SQL Server. Utilisez ce nom si l'instance de serveur participe en tant que serveur partenaire de basculement SQL Server. L’exécution de SELECT @@SERVERNAME sur une instance de serveur FCI retourne l’intégralité de sa chaîne 'FCI_network_name[\instance_name]' (laquelle correspond au nom complet du réplica).

instance_name

Nom d’une instance d’un serveur SQL Server hébergé par system_name ou FCI_network_name et sur lequel Always On est activé. Pour une instance de serveur par défaut, nom_instance est facultatif. Les noms d'instance ne respectent pas la casse. Sur une instance de serveur autonome, ce nom de valeur est le même que la valeur retournée en exécutant SELECT @@SERVERNAME.

\

Séparateur utilisé uniquement lors de la spécification de instance_name, afin de le séparer de system_name ou de FCI_network_name.

Pour plus d’informations sur les prérequis pour les nœuds WSFC et les instances de serveur, consultez Prérequis, restrictions et recommandations pour les groupes de disponibilité Always On (SQL Server).

ENDPOINT_URL = 'TCP:// system-address :port'

Spécifie le chemin d’URL du point de terminaison de mise en miroir de bases de données sur l’instance de SQL Server qui hébergera le réplica de disponibilité que vous ajoutez ou modifiez.

ENDPOINT_URL est requis dans la clause ADD REPLICA ON et est facultatif dans la clause MODIFY REPLICA ON. Pour plus d’informations, consultez Spécifier l’URL de point de terminaison pendant l’ajout ou la modification d’un réplica de disponibilité (SQL Server).

'TCP:// system-address :port'

Spécifie une URL pour spécifier une URL de point de terminaison ou l'URL de routage en lecture seule. Les paramètres d'URL sont les suivants :

adresse système

Chaîne, telle qu’un nom de système, un nom de domaine complet ou une adresse IP, qui identifie sans ambiguïté le système informatique de destination.

port

Numéro de port associé au point de terminaison de mise en miroir de l’instance de serveur (pour l’option ENDPOINT_URL) ou numéro de port utilisé par le moteur de base de données de l’instance de serveur (pour l’option READ_ONLY_ROUTING_URL).

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

Spécifie si le réplica principal doit attendre le réplica secondaire pour accepter la sécurisation renforcée (écriture) des enregistrements de journal sur le disque avant que le réplica principal puisse valider la transaction sur une base de données principale donnée. Les transactions sur des bases de données différentes sur le même réplica principal peuvent être validées indépendamment.

SYNCHRONOUS_COMMIT

Spécifie que le réplica principal attendra que la sécurité soit renforcée sur les transactions de ce réplica secondaire (mode de validation synchrone) avant de les valider. Vous pouvez spécifier SYNCHRONOUS_COMMIT pour trois réplicas au maximum, y compris le réplica principal.

ASYNCHRONOUS_COMMIT

Spécifie que le réplica principal valide les transactions sans attendre que la sécurité du journal de ce réplica secondaire soit renforcée (mode de disponibilité de validation synchrone). Vous pouvez spécifier ASYNCHRONOUS_COMMIT pour cinq réplicas de disponibilité au maximum, y compris le réplica principal.

CONFIGURATION_ONLY

Spécifie que le réplica principal valide de manière synchrone les métadonnées de configuration du groupe de disponibilité sur la base de données master sur ce réplica. Le réplica ne contiendra pas de données utilisateur. Cette option :

Peut être hébergée sur n’importe quelle édition de SQL Server, y compris l’édition Express.
Exige que le point de terminaison de mise en miroir des données du réplica CONFIGURATION_ONLY soit de type WITNESS.
Impossible de modifier.
N’est pas valide quand CLUSTER_TYPE = WSFC.

Pour plus d’informations, consultez Réplica en configuration seule.

AVAILABILITY_MODE est requis dans la clause ADD REPLICA ON et est facultatif dans la clause MODIFY REPLICA ON. Pour plus d’informations, consultez Modes de disponibilité (Groupes de disponibilité Always On).

FAILOVER_MODE = { AUTOMATIC | MANUEL }

Spécifie le mode de basculement du réplica de disponibilité que vous définissez.

AUTOMATIQUE

Active le basculement automatique. AUTOMATIC n'est pris en charge que si vous spécifiez également AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Vous pouvez spécifier AUTOMATIC pour trois réplicas de disponibilité, y compris le réplica principal.

Notes

Avant SQL Server 2016, vous avez été limité à deux réplicas de basculement automatique, y compris le réplica principal.
Les instances de cluster de basculement (FCI) SQL Server ne prennent pas en charge le basculement automatique par les groupes de disponibilité. Par conséquent, tout réplica de disponibilité hébergé par une instance de cluster de basculement ne peut être configuré que pour un basculement manuel.

MANUELLE

Active le basculement manuel ou le basculement manuel forcé (basculement forcé) par l’administrateur de base de données.

FAILOVER_MODE est requis dans la clause ADD REPLICA ON et est facultatif dans la clause MODIFY REPLICA ON. Deux types de basculement manuel existent, le basculement manuel sans perte de données et le basculement forcé (avec perte de données possible) et sont pris en charge dans différentes conditions. Pour plus d’informations, consultez Basculement et modes de basculement (Groupes de disponibilité Always On).

SEEDING_MODE = { AUTOMATIC | MANUEL }

Spécifie comment le réplica secondaire est initialement amorcé.

AUTOMATIQUE

Permet l’amorçage direct. Cette méthode amorce le réplica secondaire sur le réseau. Cette méthode ne vous oblige pas à sauvegarder et restaurer une copie de la base de données primaire sur le réplica.

Notes

Pour l’amorçage direct, vous devez autoriser la création de la base de données sur chaque réplica secondaire en appelant ALTER AVAILABILITY GROUP avec l’option GRANT CREATE ANY DATABASE.

MANUELLE

Spécifie l’amorçage manuel (par défaut). Cette méthode vous oblige à créer une sauvegarde de la base de données sur le réplica principal et à restaurer manuellement cette sauvegarde sur le réplica secondaire.

BACKUP_PRIORITY = n

Spécifie la priorité d'exécution des sauvegardes sur ce réplica par rapport aux autres réplicas dans le même groupe de disponibilité. La valeur est un entier compris entre 0 et 100. Ces valeurs ont les significations suivantes :

1..100 indique que le réplica de disponibilité peut être choisi pour effectuer des sauvegardes. 1 indique la priorité la plus faible, 100 la priorité la plus élevée. Si BACKUP_PRIORITY = 1, le réplica de disponibilité est choisi pour l'exécution des sauvegardes uniquement si aucun réplica de disponibilité ayant une priorité plus élevée n'est actuellement disponible.
0 indique que ce réplica de disponibilité ne sera jamais choisi pour effectuer des sauvegardes. Cela est utile, par exemple, pour un réplica de disponibilité distant sur lequel vous ne souhaitez jamais basculer de sauvegardes.

Pour plus d’informations, consultez Secondaires actifs : sauvegarde sur les réplicas secondaires (Groupes de disponibilité Always On).

SECONDARY_ROLE ( ... )

Spécifie les paramètres spécifiques au rôle qui prendront effet si ce réplica de disponibilité possède actuellement le rôle secondaire (autrement dit, chaque fois qu’il s’agit d’un réplica secondaire). Entre parenthèses, spécifiez l'une ou l'autre, ou les deux options de rôle secondaire. Si vous spécifiez les deux, utilisez une liste séparée par des virgules.

Les options de rôle secondaire sont les suivantes :

ALLOW_CONNECTIONS = { NON | READ_ONLY | TOUS }

Spécifie si les bases de données d'un réplica de disponibilité donné qui joue le rôle secondaire (autrement dit, qui joue le rôle d'un réplica secondaire) peuvent accepter de clients, dont :

Non

Aucune connexion utilisateur n'est autorisée aux bases de données secondaires de ce réplica. Ils ne sont pas disponibles pour l’accès en lecture. Il s'agit du comportement par défaut.

READ_ONLY

Seules sont autorisées les connexions aux bases de données dans le réplica secondaire où la propriété d’intention de l’application est définie sur ReadOnly. Pour plus d'informations sur cette propriété, consultez Using Connection String Keywords with SQL Server Native Client.

Tous

Toutes les connexions sont autorisées aux bases de données dans le réplica secondaire pour un accès en lecture seule.

Pour plus d’informations, consultez Secondaires actifs : réplicas secondaires accessibles en lecture (Groupes de disponibilité Always On).

READ_ONLY_ROUTING_URL ='TCP:// system-address :port' | AUCUN

Spécifie l'URL à utiliser pour le routage des demandes de connexion de tentative de lecture à ce réplica de disponibilité. Il s'agit de l'URL sur laquelle le moteur de base de données SQL Server écoute. En général, l'instance par défaut du moteur de base de données SQL Server écoute le port TCP 1433.

À compter de SQL Server 2025 (17.x) Preview, vous pouvez spécifier NONE comme READ_ONLY_ROUTING_URL destination pour rétablir le routage en lecture seule spécifié pour le réplica de disponibilité et router le trafic en fonction du comportement par défaut.

Pour une instance nommée, vous pouvez obtenir le numéro de port en interrogeant les colonnes port et type_desc de la vue de gestion dynamique sys.dm_tcp_listener_states. L’instance de serveur utilise l’écouteur Transact-SQL (type_desc='TSQL' ).

Pour plus d’informations sur le calcul de l’URL de routage en lecture seule pour un réplica de disponibilité, consultez Calcul de l’URL de routage en lecture seule pour AlwaysOn.

Notes

Pour une instance nommée de SQL Server, l'écouteur Transact-SQL doit être configuré pour utiliser un port spécifique. Pour plus d’informations, consultez Configurer un serveur pour écouter sur un port TCP spécifique (Gestionnaire de configuration SQL Server).

PRIMARY_ROLE ( ... )

Spécifie les paramètres spécifiques au rôle qui prendront effet si ce réplica de disponibilité possède actuellement le rôle principal (c’est-à-dire, chaque fois qu’il s’agit du réplica principal). Entre parenthèses, spécifiez l'une ou l'autre, ou les deux options de rôle principal. Si vous spécifiez les deux, utilisez une liste séparée par des virgules.

Les options de rôle principal sont les suivantes :

ALLOW_CONNECTIONS = { READ_WRITE | TOUS }

Spécifie le type de connexion que les bases de données d'un réplica de disponibilité donné qui joue le rôle principal (autrement dit, qui joue le rôle d'un réplica principal) peuvent accepter de clients, dont :

LIRE_ÉCRIRE

Les connexions où la propriété de connexion d’intention de l’application a la valeur ReadOnly ne sont pas autorisées. Lorsque la propriété Application Intent est définie sur ReadWrite ou que la propriété de connexion d’intention d’application n’est pas définie, la connexion est autorisée. Pour plus d'informations sur la propriété de connexion d'intention de l'application, consultez Using Connection String Keywords with SQL Server Native Client.

Tous

Toutes les connexions aux bases de données sont autorisées dans le réplica principal. Il s'agit du comportement par défaut.

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ ,... n ] ) | NONE }

Spécifie une liste séparée par des virgules des instances de serveur qui hébergent les réplicas de disponibilité pour ce groupe de disponibilité qui répondent aux conditions suivantes lors de l'exécution sous le rôle secondaire :

Être configurés pour autoriser les connexions ou connexions en lecture seule (voir l'argument ALLOW_CONNECTIONS de l'option de SECONDARY_ROLE, ci-dessus).
Disposer de leur URL de routage en lecture seule définie (voir l'argument READ_ONLY_ROUTING_URL de l'option SECONDARY_ROLE, ci-dessus).

Les valeurs de READ_ONLY_ROUTING_LIST sont les suivantes :

<server_instance>

Spécifie l'adresse de l'instance de SQL Server qui est l'hôte d'un réplica de disponibilité qui est un réplica secondaire lisible lors de l'exécution sous le rôle secondaire.

Utilisez une liste séparée par des virgules pour spécifier toutes les instances de serveur qui peuvent héberger un réplica secondaire lisible. Le routage en lecture seule suivra l'ordre dans lequel les instances de serveur sont spécifiées dans la liste. Si vous incluez l'instance de serveur hôte d'un réplica dans la liste de routage en lecture seule du réplica, il est généralement recommandé d'insérer cette instance de serveur à la fin de la liste, afin que les connexions de tentative de lecture soient dirigées vers un réplica secondaire (le cas échéant).

Depuis SQL Server 2016 (13.x), vous pouvez équilibrer la charge des demandes d’intention de lecture entre les réplicas secondaires lisibles. Vous le spécifiez en plaçant les réplicas dans un jeu imbriqué de parenthèses dans la liste de routage en lecture seule. Pour plus d’informations et des exemples, consultez Configurer l’équilibrage de charge entre des réplicas en lecture seule.

Aucune

Spécifie que lorsque ce réplica de disponibilité est le réplica principal, le routage en lecture seule n’est pas pris en charge. Il s'agit du comportement par défaut. Lorsqu'elle est utilisée avec MODIFY REPLICA ON, cette valeur désactive une liste existante (le cas échéant).

READ_WRITE_ROUTING_URL = 'TCP:// system-address :port' | AUCUN

s’applique à : SQL Server 2019 (15.x) et versions ultérieures

Spécifie des instances de serveur qui hébergent les réplicas de disponibilité pour ce groupe de disponibilité qui répondent aux conditions suivantes lors de l’exécution sous le rôle principal :

La spécification du réplica PRIMARY_ROLE comprend READ_WRITE_ROUTING_URL.
La chaîne de connexion est ReadWrite en définissant ApplicationIntent comme ReadWrite ou en ne définissant pas ApplicationIntent et en laissant la valeur par défaut (ReadWrite) prendre effet.

À compter de SQL Server 2025 (17.x) Preview, vous pouvez spécifier NONE comme READ_WRITE_ROUTING_URL destination pour rétablir le routage en lecture-écriture spécifié pour le réplica de disponibilité et router le trafic en fonction du comportement par défaut.

Pour plus d’informations, consultez Redirection de connexion en lecture/écriture depuis un réplica secondaire vers le réplica principal (groupes de disponibilité Always On).

SESSION_TIMEOUT = secondes

Spécifie le délai d'expiration de la session en secondes. Si vous ne spécifiez pas cette option, par défaut, la période est de 10 secondes. La valeur minimale est de 5 secondes.

Important

Le temps d'attente recommandé est de 10 secondes minimum.

Pour plus d’informations sur le délai d’expiration de session, consultez Vue d’ensemble des groupes de disponibilité Always On (SQL Server).

MODIFIER LE RÉPLICA SUR

Modifie un réplica du groupe de disponibilité. La liste des réplicas à modifier contient l’adresse de l’instance de serveur et une clause WITH (...) pour chaque réplica.

Pris en charge uniquement sur le réplica principal.

SUPPRIMER LA RÉPLIQUE SUR

Supprime le réplica secondaire spécifié du groupe de disponibilité. Le réplica principal actuel ne peut pas être supprimé d’un groupe de disponibilité. Lorsqu'il est supprimé, le réplica cesse de recevoir des données. Ses bases de données secondaires sont supprimées du groupe de disponibilité et passent à l'état RESTORING.

Pris en charge uniquement sur le réplica principal.

Notes

Si vous supprimez un réplica lorsqu’il n’est pas disponible ou a échoué, lorsqu’il revient en ligne, il découvre qu’il n’appartient plus au groupe de disponibilité.

UNIR

Provoque l'hébergement par l'instance de serveur locale d'un réplica secondaire dans le groupe de disponibilité spécifié.

Pris en charge uniquement sur un réplica secondaire qui n’a pas encore été joint au groupe de disponibilité.

Pour plus d’informations, consultez Joindre un réplica secondaire à un groupe de disponibilité (SQL Server).

BASCULEMENT

Lance un basculement manuel du groupe de disponibilité sans perte de données vers le réplica secondaire auquel vous êtes connecté. Le réplica qui doit héberger le réplica principal est la cible de basculement. La cible de basculement assure le rôle principal, récupère sa copie de chaque base de données et les met en ligne en tant que nouvelles bases de données principales. Le réplica principal précédent joue simultanément le rôle secondaire, et ses bases de données deviennent des bases de données secondaires et sont immédiatement suspendues. Éventuellement, ces rôles peuvent être basculés par une série d'échecs.

Le basculement n’est pris en charge que pour un réplica secondaire à validation synchrone qui est actuellement synchronisé avec le réplica principal. Pour qu’une réplique secondaire soit synchronisée, elle doit également s’exécuter en mode de validation synchrone.

Pour deux instances SQL Server d’un groupe de disponibilité, vous pouvez exécuter la commande de basculement sur le réplica principal ou secondaire. Pour les instances répliquées via le lien Managed Instance, la commande de basculement doit être émise sur le réplica principal.

Notes

Pour un groupe de disponibilité, une commande de basculement est renvoyée dès que la cible de basculement a accepté la commande. Toutefois, la récupération de la base de données est asynchrone après que le basculement du groupe de disponibilité est terminé.
Pour un basculement de lien Managed Instance, la commande de basculement est renvoyée après un basculement réussi où la source et la cible ont échangé leurs rôles, ou si la commande de basculement échoue après l’échec des vérifications de précondition de basculement.
La commande de basculement ne peut pas être utilisée pour un basculement planifié d’un groupe de disponibilité distribué entre deux instances SQL Server.

Pour plus d’informations sur les limitations, les prérequis et les recommandations relatives à l’exécution d’un basculement manuel planifié, consultez Effectuer un basculement manuel planifié d’un groupe de disponibilité (SQL Server).

FORCE_FAILOVER_ALLOW_DATA_LOSS

Attention

Forcer un basculement peut entraîner une perte de données et est à proprement parler une méthode de récupération après sinistre. Par conséquent, nous vous recommandons vivement de forcer le basculement uniquement si le réplica principal n’est plus en cours d’exécution, si vous êtes prêt à risquer de perdre des données et si vous devez restaurer le service dans le groupe de disponibilité immédiatement.

Pris en chrage uniquement sur un réplica dont le rôle est dans l'état SECONDARY ou RESOLVING. --Le réplica sur lequel vous entrez une commande de basculement est appelé cible de basculement.

Force le basculement du groupe de disponibilité (avec possible perte de données) vers la cible de basculement. La cible de basculement assure le rôle principal, récupère sa copie de chaque base de données et les met en ligne en tant que nouvelles bases de données principales. Sur tous les réplicas secondaires restants, chaque base de données secondaire est suspendue jusqu'à ce qu'elle soit reprise manuellement. Lorsque le réplica principal précédent est disponible, il bascule sur le rôle secondaire, et ses bases de données deviennent des bases de données secondaires suspendues.

Pour les instances répliquées via le lien Managed Instance, la FORCE_FAILOVER_ALLOW_DATA_LOSS commande doit être émise sur le réplica secondaire (la cible de basculement).

Notes

Une commande de basculement est retournée dès que la cible de basculement a accepté la commande. Toutefois, la récupération de la base de données est asynchrone après que le basculement du groupe de disponibilité est terminé.

Pour plus d’informations sur les limitations, les prérequis et les recommandations pour forcer un basculement, ainsi que sur l’effet d’un basculement forcé sur les anciennes bases de données principales dans le groupe de disponibilité, consultez Effectuer un basculement manuel forcé d’un groupe de disponibilité (SQL Server).

AJOUTER UN ÉCOUTEUR 'dns_name'( <add_listener_option> )

Définit un nouvel écouteur de groupe de disponibilité pour ce groupe de disponibilité. Pris en charge uniquement sur le réplica principal.

Important

Avant de créer votre premier écouteur, nous vous recommandons vivement de lire Créer ou configurer un écouteur de groupe de disponibilité (SQL Server).

Après avoir créé un écouteur pour un groupe de disponibilité spécifique, nous vous recommandons fortement de procéder comme suit :

Demandez à votre administrateur réseau de réserver l'adresse IP de l'écouteur pour son utilisation exclusive.
Fournissez le nom d'hôte DNS de l'écouteur aux développeurs d'applications pour qu'ils l'utilisent dans les chaînes de connexion lorsqu'ils demandent des connexions clientes vers ce groupe de disponibilité.

dns_name

Spécifie le nom d'hôte DNS de l'écouteur du groupe de disponibilité. Le nom DNS de l'écouteur doit être unique dans le domaine et dans NetBIOS.

dns_name est une valeur de chaîne. Ce nom ne peut contenir que des caractères alphanumériques, des tirets (-) et des caractères de soulignement (_), dans n'importe quel ordre. Les noms d'hôte DNS ne respectent pas la casse. La longueur maximale autorisée est de 63 caractères.

Nous vous recommandons de spécifier une chaîne explicite. Par exemple, pour un groupe de disponibilité nommé AG1, un nom d'hôte DNS explicite est ag1-listener.

Important

NetBIOS identifie les 15 premiers caractères du nom_dns. Si vous avez deux clusters WSFC contrôlés par le même Active Directory et que vous essayez de créer des écouteurs de groupe de disponibilité dans les deux clusters à l’aide de noms de plus de 15 caractères et d’un préfixe de 15 caractères identique, vous obtenez un rapport d’erreur indiquant que la ressource nom de réseau virtuel n’a pas pu être mise en ligne. Pour plus d'informations sur les règles de préfixe des noms DNS, consultez Attribution de noms de domaine.

REJOIGNEZ LE GROUPE DE DISPONIBILITÉ SUR

Joint à un groupe de disponibilité distribué. Lorsque vous créez un groupe de disponibilité distribué, le groupe de disponibilité sur le cluster où il est créé est le groupe de disponibilité principal. Le groupe de disponibilité qui rejoint le groupe de disponibilité distribué devient le groupe de disponibilité secondaire.

<ag_name>

Spécifie le nom du groupe de disponibilité qui constitue la moitié du groupe de disponibilité distribué.

LISTENER = 'TCP:// system-address :port'

Spécifie le chemin de l’URL de l’écouteur associé au groupe de disponibilité.

La clause LISTENER est obligatoire.

'TCP:// system-address :port'

Spécifie une URL pour l’écouteur associé au groupe de disponibilité. Les paramètres d'URL sont les suivants :

adresse système

Chaîne, telle qu’un nom système, un nom de domaine complet ou une adresse IP, qui identifie sans ambiguïté l’écouteur.

port

Numéro de port associé au point de terminaison de mise en miroir du groupe de disponibilité. Notez que ce n’est pas le port de l’écouteur.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Spécifie si le réplica principal doit attendre le groupe de disponibilité secondaire pour accepter la sécurisation renforcée (écriture) des enregistrements de journal sur le disque avant que le réplica principal puisse valider la transaction sur une base de données principale donnée.

SYNCHRONOUS_COMMIT

Spécifie que le réplica principal attend que la sécurité soit renforcée sur les transactions de ce groupe de disponibilité secondaire avant de les valider. Vous pouvez spécifier SYNCHRONOUS_COMMIT pour deux groupes de disponibilité, y compris pour le groupe de disponibilité principal.

ASYNCHRONOUS_COMMIT

Spécifie que le réplica principal valide les transactions sans attendre que la sécurité du journal de ce groupe de disponibilité secondaire soit renforcée. Vous pouvez spécifier ASYNCHRONOUS_COMMIT pour deux groupes de disponibilité, y compris pour le groupe de disponibilité principal.

La clause AVAILABILITY_MODE est obligatoire.

FAILOVER_MODE = { MANUEL }

Spécifie le mode de basculement du groupe de disponibilité distribué.

MANUELLE

Active le basculement manuel planifié ou le basculement manuel forcé (généralement appelé basculement forcé) par l’administrateur de base de données.

Le basculement automatique vers le groupe de disponibilité secondaire n’est pas pris en charge.

SEEDING_MODE = { AUTOMATIC | MANUEL }

Spécifie comment le groupe de disponibilité secondaire est initialement amorcé.

AUTOMATIQUE

Active l’amorçage automatique. Cette méthode amorce le groupe de disponibilité secondaire sur le réseau. Cette méthode ne vous oblige pas à sauvegarder et restaurer une copie de la base de données primaire sur les réplicas du groupe de disponibilité secondaire.

MANUELLE

Spécifie l’amorçage manuel. Cette méthode vous oblige à créer une sauvegarde de la base de données sur le réplica principal et de restaurer manuellement cette sauvegarde sur le ou les réplicas du groupe de disponibilité secondaire.

MODIFIER LE GROUPE DE DISPONIBILITÉ SUR

Modifie les paramètres de groupe de disponibilité d’un groupe de disponibilité distribué. La liste des groupes de disponibilité à modifier contient le nom du groupe de disponibilité et une clause WITH (...) pour chaque groupe de disponibilité.

Important

Cette commande doit être répétée sur le groupe de disponibilité principal et sur les instances de groupes de disponibilité secondaires.

GRANT CRÉER N’IMPORTE QUELLE BASE DE DONNÉES

Autorise le groupe de disponibilité à créer des bases de données pour le compte du réplica principal, qui prend en charge l’amorçage direct (SEEDING_MODE = AUTOMATIC). Ce paramètre doit être exécuté sur chaque réplica secondaire qui prend en charge l’amorçage direct, après que cette base de données secondaire a rejoint le groupe de disponibilité. Nécessite l’autorisation CREATE ANY DATABASE.

REFUSER LA CRÉATION D’UNE BASE DE DONNÉES

Pour le groupe de disponibilité, supprime la possibilité de créer des bases de données pour le compte du réplica principal.

<add_listener_option>

ADD LISTENER prend l'une des options suivantes :

AVEC DHCP [ SUR { ('four_part_ipv4_address','four_part_ipv4_mask') } ]

Spécifie que l'écouteur du groupe de disponibilité utilise le protocole DHCP (Dynamic Host Configuration Protocol). Utilisez éventuellement la clause ON pour identifier le réseau sur lequel cet écouteur sera créé. DHCP est limité à un seul sous-réseau utilisé pour chaque instance de serveur qui héberge un réplica de disponibilité dans le groupe de disponibilité.

Important

Nous déconseillons DHCP dans l’environnement de production. S’il existe un délai d’arrêt et que le bail IP DHCP expire, un délai supplémentaire est nécessaire pour inscrire la nouvelle adresse IP réseau DHCP associée au nom DNS de l’écouteur et impacter la connectivité du client. Toutefois, DHCP peut tout à fait être utilisé pour configurer un environnement de développement et de test dans le but de vérifier les fonctions de base des groupes de disponibilité et l'intégration avec vos applications.

Par exemple :

WITH DHCP ON ('10.120.19.0','255.255.254.0')

WITH IP ( { ('four_part_ipv4_address','four_part_ipv4_mask') | ('ipv6_address') } [ , ... n ] ) [ , PORT = listener_port ]

Spécifie que l'écouteur du groupe de disponibilité utilisera une ou plusieurs adresses IP statiques au lieu d'utiliser DHCP. Pour créer un groupe de service sur plusieurs sous-réseaux, chaque sous-réseau requiert une adresse IP statique dans la configuration de l'écouteur. Pour un sous-réseau donné, l'adresse IP statique peut être une adresse IPv4 ou une adresse IPv6. Contactez votre administrateur réseau pour obtenir une adresse IP statique pour chaque sous-réseau qui hébergera un réplica de disponibilité pour le nouveau groupe de disponibilité.

Par exemple :

WITH IP ( ('10.120.19.155','255.255.254.0') )

ipv4_address

Spécifie une adresse IPv4 en quatre parties pour un écouteur du groupe de disponibilité. Par exemple : 10.120.19.155.

ipv4_mask

Spécifie un masque IPv4 en quatre parties pour un écouteur du groupe de disponibilité. Par exemple : 255.255.254.0.

ipv6_address

Spécifie une adresse IPv6 pour un écouteur du groupe de disponibilité. Par exemple : 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORT = listener_port

Spécifie le numéro de port listener_port à utiliser par un écouteur du groupe de disponibilité spécifié par une clause WITH IP. Le PORT est facultatif.

Le numéro de port par défaut est 1433. Toutefois, si vous avez des problèmes de sécurité, nous vous recommandons d'utiliser un numéro de port différent.

Par exemple : WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

MODIFIER L’ÉCOUTEUR 'dns_name'( <modify_listener_option> )

Modifie un écouteur du groupe de disponibilité existant pour ce groupe de disponibilité. Pris en charge uniquement sur le réplica principal.

<modify_listener_option>

MODIFY LISTENER prend l'une des options suivantes :

ADD IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('dns_name ipv6_address') }

Ajoute l’adresse IP spécifiée à l’écouteur de groupe de disponibilité spécifié par dns_name.

PORT = listener_port

Une description de cet argument est fournie plus haut dans cette section.

REMOVE IP { ('four_part_ipv4_address') | ('ipv6_address') }

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

Supprime l’adresse IP spécifiée de l’écouteur de groupe de disponibilité spécifié.

REDÉMARRER L’ÉCOUTEUR 'dns_name'

Redémarre l'écouteur associé au nom DNS spécifié. Pris en charge uniquement sur le réplica principal.

SUPPRIMER L’ÉCOUTEUR 'dns_name'

Supprime l'écouteur associé au nom DNS spécifié. Pris en charge uniquement sur le réplica principal.

HORS-LIGNE

Place un groupe de disponibilité hors connexion. Il n’existe aucune perte de données pour les bases de données de validation synchrone.

Une fois qu’un groupe de disponibilité est hors connexion, ses bases de données deviennent indisponibles pour les clients et vous ne pouvez pas remettre le groupe de disponibilité en ligne. Par conséquent, utilisez l'option OFFLINE uniquement pendant une migration entre clusters des groupes de disponibilité Always On, lorsque vous migrez des ressources du groupe de disponibilité vers un nouveau cluster WSFC.

Pour plus d’informations, consultez Placer un groupe de disponibilité hors connexion (SQL Server).

Conditions préalables requises et restrictions

Pour plus d’informations sur les prérequis et les restrictions des réplicas de disponibilité et de leurs ordinateurs et instances de serveur hôte, consultez Prérequis, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server).

Pour plus d’informations sur les restrictions relatives aux instructions Transact-SQL AVAILABILITY GROUP, consultez Vue d’ensemble des instructions Transact-SQL pour les groupes de disponibilité Always On (SQL Server).

Autorisations

Requiert l'autorisation ALTER AVAILABILITY GROUP sur le groupe de disponibilité, l'autorisation CONTROL AVAILABILITY GROUP, l'autorisation ALTER ANY AVAILABILITY GROUP ou l'autorisation CONTROL SERVER. Nécessite également l’autorisation ALTER ANY DATABASE.

Exemples

R. Jointure d'un réplica secondaire à un groupe de disponibilité

L’exemple suivant joint un réplica secondaire auquel vous êtes connecté au AccountsAG groupe de disponibilité.

ALTER AVAILABILITY GROUP AccountsAG JOIN;  
GO

B. Forcer le basculement d'un groupe de disponibilité

L’exemple suivant force le AccountsAG groupe de disponibilité à basculer vers le réplica secondaire auquel vous êtes connecté.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
GO

Chapitre C. Forcer le chiffrement dans les connexions au groupe de disponibilité

Les exemples de cette section forcent le chiffrement dans les connexions au AccountsAG groupe de disponibilité.

Si le nom du serveur est répertorié dans chaque certificat tel que défini par l’une ou l’autre méthode, vous pouvez omettre l’option HostNameInCertificate :

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict')

Si vous avez suivi la méthode 1 et que le nom de votre serveur n’est pas répertorié comme un autre nom d’objet dans le certificat, vous devez spécifier la valeur que vous avez répertoriée dans l’autre nom de l’objet dans l’option HostNameInCertificate.

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;HostNameInCertificate=<Subject Alternative Name>')

Si vous avez suivi la méthode 1 et que vous souhaitez utiliser la ServerCertificate propriété au lieu de fournir une valeur pour HostNameInCertificate:

ALTER AVAILABILITY GROUP [AccountsAG]
   SET (
   CLUSTER_CONNECTION_OPTIONS = 'Encrypt=Strict;ServerCertificate=C:\Users\admin\SqlAGCertificate.cer')

Voir aussi

CRÉER UN GROUPE DE DISPONIBILITÉ (Transact-SQL)
ALTER DATABASE SET HADR (Transact-SQL)
GROUPE DE DISPONIBILITÉ DES DÉPÔTS (Transact-SQL)
sys.availability_replicas (Transact-SQL)
sys.availability_groups (Transact-SQL)
Résoudre des problèmes de configuration des groupes de disponibilité Always On (SQL Server)
Vue d’ensemble des groupes de disponibilité Always On (SQL Server)
Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server)

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-08-15

Partager via

MODIFIER LE GROUPE DE DISPONIBILITÉ (Transact-SQL)

Syntaxe

Les arguments

group_name

AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDAIRE | NONE }

PRIMAIRE

SECONDARY_ONLY

SECONDAIRE

Aucune

FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }

HEALTH_CHECK_TIMEOUT = millisecondes

DB_FAILOVER = { LE | DÉSACTIVÉ }

= DTC_SUPPORT { PER_DB | AUCUN }

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

RÔLE

CLUSTER_CONNECTION_OPTIONS

AJOUTER UNE BASE DE DONNÉES database_name

SUPPRIMER LA BASE DE DONNÉES database_name

AJOUTER UNE RÉPLIQUE SUR

<server_instance>

nom_système

nom_réseau_FCI

instance_name

\

ENDPOINT_URL = 'TCP:// system-address :port'

'TCP:// system-address :port'

adresse système

port

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

CONFIGURATION_ONLY

FAILOVER_MODE = { AUTOMATIC | MANUEL }

AUTOMATIQUE

MANUELLE

SEEDING_MODE = { AUTOMATIC | MANUEL }

AUTOMATIQUE

MANUELLE

BACKUP_PRIORITY = n

SECONDARY_ROLE ( ... )

ALLOW_CONNECTIONS = { NON | READ_ONLY | TOUS }

Non

READ_ONLY

Tous

READ_ONLY_ROUTING_URL ='TCP:// system-address :port' | AUCUN

PRIMARY_ROLE ( ... )

ALLOW_CONNECTIONS = { READ_WRITE | TOUS }

LIRE_ÉCRIRE

Tous

READ_ONLY_ROUTING_LIST = { ('<server_instance>' [ ,... n ] ) | NONE }

<server_instance>

Aucune

READ_WRITE_ROUTING_URL = 'TCP:// system-address :port' | AUCUN

SESSION_TIMEOUT = secondes

MODIFIER LE RÉPLICA SUR

SUPPRIMER LA RÉPLIQUE SUR

UNIR

BASCULEMENT

FORCE_FAILOVER_ALLOW_DATA_LOSS

AJOUTER UN ÉCOUTEUR 'dns_name'( <add_listener_option> )

dns_name

REJOIGNEZ LE GROUPE DE DISPONIBILITÉ SUR

<ag_name>

LISTENER = 'TCP:// system-address :port'

'TCP:// system-address :port'

adresse système

port

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

FAILOVER_MODE = { MANUEL }

MANUELLE

SEEDING_MODE = { AUTOMATIC | MANUEL }

AUTOMATIQUE

MANUELLE

MODIFIER LE GROUPE DE DISPONIBILITÉ SUR

GRANT CRÉER N’IMPORTE QUELLE BASE DE DONNÉES

REFUSER LA CRÉATION D’UNE BASE DE DONNÉES

<add_listener_option>

ADD IP { ('four_part_ipv4_address','four_part_ipv4_mask') | ('dns_name ipv6_address') }