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 ALTER AVAILABILITY GROUP arguments sont pris en charge uniquement sur le réplica principal actuel. Toutefois, les JOINFAILOVERarguments et FORCE_FAILOVER_ALLOW_DATA_LOSS les arguments sont pris en charge uniquement 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 façon dont un travail de sauvegarde évalue le réplica principal lors du choix de l’emplacement 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. Par conséquent, elle n'a aucune incidence 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 se produisent toujours 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 des journaux de transaction pour préparer les bases de données secondaires d’un groupe de disponibilité, définissez la préférence Primary de sauvegarde automatisée jusqu’à ce que toutes les bases de données secondaires soient préparées et jointes au groupe de disponibilité.

SECONDARY_ONLY

Spécifie que les sauvegardes ne se produisent jamais sur le réplica principal. Si le réplica principal est le seul réplica en ligne, la sauvegarde ne se produit pas.

SECONDAIRE

Spécifie que les sauvegardes se produisent sur un réplica secondaire, sauf si le réplica principal est le seul réplica en ligne. Dans ce cas, la sauvegarde se produit 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 AUTOMATED_BACKUP_PREFERENCE paramètre. L’interprétation de cette préférence dépend de la logique, le cas échéant, que vous créez un script dans des travaux de sauvegarde pour les bases de données d’un groupe de disponibilité donné. Le paramètre de préférence de sauvegarde automatisé n’a aucun effet sur les sauvegardes ad hoc. Pour plus d’informations, consultez Configurer des sauvegardes sur des réplicas secondaires d’un groupe de disponibilité Always On.

Notes

Pour afficher la préférence de sauvegarde automatisée d’un groupe de disponibilité existant, sélectionnez la ou automated_backup_preference_desc la automated_backup_preference colonne de l’affichage catalogue sys.availability_groups. En outre, sys.fn_hadr_backup_is_preferred_replica pouvez être utilisé pour déterminer le réplica de sauvegarde préféré. Cette fonction retourne 1 toujours pour au moins un des réplicas, même quand AUTOMATED_BACKUP_PREFERENCE = NONE.

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

Spécifie les conditions d’échec qui déclenchent un basculement automatique pour ce groupe de disponibilité. FAILURE_CONDITION_LEVEL est défini au niveau du groupe, mais il est pertinent uniquement sur les réplicas de disponibilité configurés pour le mode de disponibilité de validation synchrone (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). En outre, les conditions d’échec peuvent 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 que 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 démarre quand l’une des opérations suivantes se produit : Le service SQL Server est fermé. Le bail du groupe de disponibilité pour la connexion au cluster WSFC expire, car aucune n’est `ACK` reçue 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 démarre quand l’une des opérations suivantes se produit : L’instance de SQL Server ne se connecte pas au cluster et le seuil spécifié par `HEALTH_CHECK_TIMEOUT` 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 lance des erreurs internes SQL Server critiques, telles que des verrous de spinlock orphelins, des violations graves d’accès en écriture ou trop de dumping. Il s'agit du comportement par défaut.
4	Spécifie qu’un basculement automatique démarre sur des erreurs internes SQL Server modérées, telles qu’une condition de mémoire insuffisante persistante dans le pool de ressources interne SQL Server.
5	Spécifie qu’un basculement automatique démarre sur toutes les conditions de défaillance qualifiées, 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 FAILURE_CONDITION_LEVEL valeurs et HEALTH_CHECK_TIMEOUT les valeurs définissent une stratégie de basculement flexible 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 Configurer une stratégie de basculement automatique flexible pour un groupe de disponibilité Always On.

`HEALTH_CHECK_TIMEOUT` = Millisecondes

Spécifie le temps d’attente, en millisecondes, 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 suppose que l’instance de serveur est lente ou ne répond pas. Défini HEALTH_CHECK_TIMEOUT au niveau du groupe, mais il est pertinent uniquement sur les réplicas de disponibilité que vous configurez pour le mode de disponibilité de validation synchrone avec basculement automatique (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT). En outre, un délai d’expiration du 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 que le réplica secondaire est actuellement synchronisé avec le réplica principal.

La valeur par défaut 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. Lorsqu’il est défini ONsur , tout état autre que ONLINE pour une base de données dans le groupe de disponibilité déclenche un basculement automatique. Lorsque vous définissez cette option OFFsur , seule l’intégrité de l’instance déclenche le basculement automatique.

Pour plus d’informations sur ce paramètre, consultez l’option de basculement de détection d’intégrité au niveau du groupe de disponibilité.

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 entre 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 - Groupes de disponibilité et mise en miroir de bases de données.

Notes

La prise en charge de la DTC_SUPPORT modification du paramètre 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 DROP et CREATE le groupe de disponibilité à nouveau.

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 serveur SQL Server qui héberge un réplica synchrone secondaire cesse de répondre, le serveur SQL Server qui héberge le réplica principal marque ce réplica secondaire en tant que NOT SYNCHRONIZED réplica secondaire et continue. Lorsque la base de données non réactive revient en ligne, elle est dans un état « non synchronisé » et le réplica est marqué comme non sain jusqu’à ce que le réplica 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 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, et cette SET option n’est valide que dans les groupes de disponibilité distribués. Utilisez-le pour basculer un groupe de disponibilité distribué.

CLUSTER_CONNECTION_OPTIONS

S’applique à : SQL Server 2025 (17.x) 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é. Spécifiez les options sous la forme d’une liste de paires clé-valeur, séparées par des points-virgules. Utilisez les paires clé-valeur 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) utilise Encrypt=Mandatorypar défaut , et TrustServerCertificate=Yes pour les connexions aux répliques 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 vous définissez le chiffrement `Mandatory`sur , vous `TrustServerCertificate` devez définir la valeur Oui. Si vous définissez le chiffrement `Strict`sur , il `TrustServerCertificate` est ignoré. Remarque : cette paire clé-valeur 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. Remarque : cette paire clé-valeur 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. Remarque : cette paire clé-valeur 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é. Remarque : cette paire clé-valeur 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 qu’un groupe de disponibilité peut prendre en charge, consultez Conditions préalables, restrictions et recommandations pour les groupes de disponibilité Always On. Pour savoir quelles bases de données locales appartiennent déjà à un groupe de disponibilité, consultez la replica_id colonne dans l’affichage catalogue sys.databases .

Pris en charge uniquement sur le réplica principal.

Notes

Après avoir créé le groupe de disponibilité, vous devez vous connecter à chaque instance de serveur qui héberge un réplica secondaire. Préparez ensuite chaque base de données secondaire et joignez-la 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é Always On.

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 son adresse d’instance de serveur suivie d’une WITH (...) clause.

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 , plus loin 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 que vous utilisez pour accéder à un cluster de basculement SQL Server. Utilisez ce nom si l’instance de serveur participe en tant que partenaire de basculement SQL Server. L’exécution SELECT @@SERVERNAME sur une instance de serveur FCI retourne la chaîne « FCI_network_name[\instance_name] » (qui est le nom complet du réplica).

Pour plus d’informations, consultez @@SERVERNAME.

instance_name

Nom d’une instance d’un serveur SQL Server qui system_name ou FCI_network_name hôtes et qui a Always On 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 identique à 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 Conditions préalables, restrictions et recommandations pour les groupes de disponibilité Always On.

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éberge le réplica de disponibilité que vous ajoutez ou modifiez.

ENDPOINT_URL est requis dans la ADD REPLICA ON clause et facultatif dans la MODIFY REPLICA ON clause. Pour plus d’informations, consultez Spécifier l’URL du point de terminaison - Ajout ou modification du réplica de disponibilité.

'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 attend que le réplica secondaire reconnaisse le renforcement (écriture) des enregistrements de journal sur le disque avant que le réplica principal puisse valider la transaction sur une base de données primaire 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 attend de valider les transactions jusqu’à ce qu’elles soient renforcées sur ce réplica secondaire (mode de validation synchrone). Vous pouvez spécifier SYNCHRONOUS_COMMIT jusqu’à trois réplicas, 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 jusqu’à cinq réplicas de disponibilité, y compris le réplica principal.

CONFIGURATION_ONLY

Spécifie que le réplica principal valide de façon synchrone les métadonnées de configuration du groupe de disponibilité sur la master base de données sur ce réplica. Le réplica ne contient 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.
Nécessite que le point de terminaison de mise en miroir de données du CONFIGURATION_ONLY réplica soit de type WITNESS.
Impossible de modifier.
N’est pas valide quand CLUSTER_TYPE = WSFC.

Pour plus d’informations, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.

AVAILABILITY_MODE est requis dans la ADD REPLICA ON clause et facultatif dans la MODIFY REPLICA ON clause. Pour plus d’informations, consultez Différences entre les modes de disponibilité pour un groupe 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 est pris en charge uniquement si vous spécifiez AVAILABILITY_MODE = SYNCHRONOUS_COMMITégalement . Vous pouvez spécifier AUTOMATIC trois réplicas de disponibilité, y compris le réplica principal.

Notes

Avant SQL Server 2016 (13.x), vous êtes limité à deux réplicas de basculement automatique, y compris le réplica principal.
Les instances de cluster de basculement SQL Server (FCI) ne prennent pas en charge le basculement automatique par les groupes de disponibilité ; par conséquent, tout réplica de disponibilité qu’héberge un FCI 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.

Vous devez spécifier FAILOVER_MODE dans la ADD REPLICA ON clause. Vous pouvez éventuellement le spécifier dans la MODIFY REPLICA ON clause. Il existe deux types de basculement manuel : basculement manuel sans perte de données et basculement forcé (avec perte de données possible). Différentes conditions prennent en charge ces types. 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 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 effectuer des sauvegardes uniquement si aucun réplica de disponibilité de priorité supérieure n’est actuellement disponible.
0 indique que ce réplica de disponibilité n’est jamais choisi pour effectuer des sauvegardes. Cette option est utile, par exemple, pour un réplica de disponibilité à distance vers lequel vous ne souhaitez jamais que les sauvegardes basculent.

Pour plus d’informations, consultez Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité.

SECONDARY_ROLE ( ... )

Spécifie les paramètres spécifiques au rôle qui prennent effet si ce réplica de disponibilité possède actuellement le rôle secondaire (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 effectuent le rôle secondaire (agissant en tant que réplica secondaire) peuvent accepter les connexions des clients, l’un des éléments suivants :

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 les connexions sont autorisées aux bases de données du réplica secondaire où la propriété Application Intent est définie ReadOnlysur . 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 Décharger une charge de travail en lecture seule vers un réplica secondaire d’un groupe de disponibilité Always On.

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

Spécifie l’URL à utiliser pour acheminer les demandes de connexion en lecture-intention vers ce réplica de disponibilité. Cette URL est l’endroit où 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.

À partir de SQL Server 2025 (17.x), vous pouvez spécifier NONE comme READ_ONLY_ROUTING_URL destination la remise en arrière du routage en lecture seule spécifié pour la réplique de disponibilité, et router le trafic selon le comportement par défaut.

Pour une instance nommée, interrogez les colonnes et type_desc les port colonnes de la vue de gestion dynamique sys.dm_tcp_listener_states pour obtenir le numéro de port. 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, configurez l’écouteur Transact-SQL pour utiliser un port spécifique. Pour plus d’informations, consultez Configurer SQL Server pour l’écoute sur un port TCP spécifique.

PRIMARY_ROLE ( ... )

Spécifie les paramètres spécifiques au rôle qui prennent effet si ce réplica de disponibilité possède actuellement le rôle principal (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é exécutant le rôle principal (agissant comme réplica principal) peuvent accepter à partir de clients, l’un des éléments suivants :

LIRE_ÉCRIRE

Connexions dans lesquelles la propriété de connexion d’intention d’application est définie ReadOnly comme non autorisée. Lorsque la propriété Application Intent est définie ReadWrite sur 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é pour autoriser toutes les connexions ou connexions en lecture seule (consultez l’argument ALLOW_CONNECTIONS de l’option SECONDARY_ROLE , précédemment dans cet article).
Définissez leur URL de routage en lecture seule (voir l’argument READ_ONLY_ROUTING_URL de l’option SECONDARY_ROLE , précédemment dans cet article).

Les READ_ONLY_ROUTING_LIST valeurs 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 suit 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' | NONE }

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 PRIMARY_ROLE du réplica inclut 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.

À partir de SQL Server 2025 (17.x), vous pouvez spécifier NONE comme READ_WRITE_ROUTING_URL destination pour revenir au routage lecture-écriture spécifié pour la réplique de disponibilité, et router le trafic selon le 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, la période par défaut est de 10 secondes. La valeur minimale est de 5 secondes.

Important

Conservez la période d’expiration à 10 secondes ou ultérieures.

Pour plus d’informations sur la période d’expiration de session, consultez Qu’est-ce qu’un groupe de disponibilité Always On ?

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 WITH (...) clause 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é. Vous ne pouvez pas supprimer le réplica principal actuel d’un groupe de disponibilité. Lorsque vous supprimez un réplica, il cesse de recevoir des données. Les bases de données secondaires du réplica sont supprimées du groupe de disponibilité et entrent dans 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’est pas encore joint au groupe de disponibilité.

Pour plus d’informations, consultez Joindre un réplica secondaire à un groupe de disponibilité Always On.

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 héberge le réplica principal est la cible de basculement. La cible de basculement prend le rôle principal et récupère sa copie de chaque base de données, en les mettant en ligne en tant que nouvelles bases de données primaires. 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. Potentiellement, ces rôles peuvent basculer vers l’arrière par une série d’échecs.

Le basculement est uniquement pris en charge pour un réplica secondaire de 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, vous devez émettre la commande de basculement sur le réplica principal.

Notes

Pour un groupe de disponibilité, une commande de basculement retourne dès que la cible de basculement accepte la commande. Toutefois, la récupération de base de données se produit de manière asynchrone une fois le basculement du groupe de disponibilité terminé.
Pour un basculement de liaison Managed Instance, la commande de basculement retourne après un basculement réussi où les rôles de commutateur source et cible, ou si la commande de basculement échoue après l’échec des vérifications de condition préalable de basculement.
Vous ne pouvez pas utiliser la commande de basculement pour un basculement planifié d’un groupe de disponibilité distribué entre deux instances SQL Server.

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

FORCE_FAILOVER_ALLOW_DATA_LOSS

Attention

Lancez uniquement un basculement forcé en tant que mesure de récupération d’urgence, car cela peut entraîner une perte de données. Le basculement forcé doit être effectué uniquement lorsque le réplica principal n’est pas disponible, que vous êtes prêt à accepter une perte de données potentielle et que vous devez restaurer immédiatement le service sur le groupe de disponibilité.

Pris en charge uniquement sur un réplica dont le rôle est dans l’état ou RESOLVING dans l’étatSECONDARY. Le réplica sur lequel vous entrez une commande de basculement est la 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 prend le rôle principal et récupère sa copie de chaque base de données, en les mettant en ligne en tant que nouvelles bases de données primaires. Sur tous les réplicas secondaires restants, chaque base de données secondaire est suspendue jusqu'à ce qu'elle soit reprise manuellement. Lorsque l’ancien réplica principal devient disponible, il bascule vers 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, vous devez émettre la FORCE_FAILOVER_ALLOW_DATA_LOSS commande sur le réplica secondaire (cible de basculement).

Notes

Une commande de basculement retourne dès que la cible de basculement accepte la commande. Toutefois, la récupération de base de données se produit de manière asynchrone une fois le basculement du groupe de disponibilité terminé.

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

ADD LISTENER '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, lisez Configurer un écouteur pour un groupe de disponibilité Always On.

Après avoir créé un écouteur pour un groupe de disponibilité donné, procédez 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.

Spécifiez une chaîne significative. Par exemple, pour un groupe de disponibilité nommé AG1, un nom d'hôte DNS explicite est ag1-listener.

Important

NetBIOS reconnaît uniquement les 15 premiers caractères dans le dns_name. 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 identique de 15 caractères, vous obtenez un message d’erreur indiquant que la ressource Nom du 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ù vous le créez 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 LISTENER clause est requise.

'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é. Ce n’est pas le port de l’écouteur.

AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }

Spécifie si le réplica principal attend que le groupe de disponibilité secondaire reconnaisse le renforcement (écriture) des enregistrements de journal sur le disque avant que le réplica principal puisse valider la transaction sur une base de données primaire donnée.

SYNCHRONOUS_COMMIT

Spécifie que le réplica principal attend de valider les transactions jusqu’à ce qu’elle reçoive la confirmation que les transactions sont renforcées sur le groupe de disponibilité secondaire. Vous pouvez spécifier SYNCHRONOUS_COMMIT jusqu’à deux groupes de disponibilité, y compris 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 jusqu’à deux groupes de disponibilité, y compris le groupe de disponibilité principal.

La AVAILABILITY_MODE clause est requise.

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 à restaurer manuellement cette sauvegarde sur 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 WITH (...) clause pour chaque groupe de disponibilité.

Important

Vous devez exécuter cette commande sur les instances du groupe de disponibilité principal et du groupe de disponibilité secondaire.

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

Permet au groupe de disponibilité de 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). Exécutez ce paramètre sur chaque réplica secondaire qui prend en charge l’amorçage direct après que celui-ci joint 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 [ ON { ('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). Si vous le souhaitez, utilisez la ON clause pour identifier le réseau sur lequel cet écouteur est 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

N’utilisez pas DHCP dans un environnement de production. S’il y a un temps 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 affecte 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 ]

Au lieu d’utiliser DHCP, l’écouteur de groupe de disponibilité utilise une ou plusieurs adresses IP statiques. 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éberge 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

Adresse en quatre parties IPv4 pour un écouteur de groupe de disponibilité. Par exemple : 10.120.19.155.

ipv4_mask

Masque en quatre parties IPv4 pour un écouteur de groupe de disponibilité. Par exemple : 255.255.254.0.

ipv6_address

Adresse IPv6 pour un écouteur de groupe de disponibilité. Par exemple : 2001::4898:23:1002:20f:1fff:feff:b3a3.

PORT = listener_port

Numéro de port (listener_port) à utiliser par un écouteur de groupe de disponibilité spécifié par la WITH IP clause. PORT est facultatif.

Le numéro de port par défaut, est 1433pris en charge. Toutefois, vous pouvez choisir un autre numéro de port.

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

MODIFY LISTENER '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') | ('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.

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

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

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

RESTART LISTENER 'dns_name'

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

REMOVE LISTENER '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.

Lorsqu’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 lors d’une migration entre clusters de groupes de disponibilité Always On, lorsque vous migrez des ressources de groupe de disponibilité vers un nouveau cluster WSFC.

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

Prérequis et restrictions

Pour plus d’informations sur les conditions préalables et les restrictions sur les réplicas de disponibilité et sur leurs ordinateurs et instances de serveur hôte, consultez Conditions préalables, restrictions et recommandations pour les groupes de disponibilité Always On.

Pour plus d’informations sur les restrictions sur les AVAILABILITY GROUP instructions Transact-SQL, consultez Transact-SQL instructions pour les groupes de disponibilité Always On.

Autorisations

Vous avez besoin ALTER AVAILABILITY GROUP d’autorisations sur le groupe de disponibilité, CONTROL AVAILABILITY GROUP l’autorisation, ALTER ANY AVAILABILITY GROUP l’autorisation ou CONTROL SERVER l’autorisation. Vous avez également besoin d’une ALTER ANY DATABASE autorisation.

Exemples

R. Joindre 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 apparaît 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 mais que vous n’avez pas listé le nom du serveur comme autre nom d’objet dans le certificat, vous devez spécifier la valeur qui apparaît 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')

Commentaires

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

Last updated on 2026-01-06

Partage 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' | NONE }

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' | NONE }

SESSION_TIMEOUT = secondes

MODIFIER LE RÉPLICA SUR

SUPPRIMER LA RÉPLIQUE SUR

UNIR

BASCULEMENT

FORCE_FAILOVER_ALLOW_DATA_LOSS

ADD LISTENER '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>

`HEALTH_CHECK_TIMEOUT` = Millisecondes

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

READ_ONLY_ROUTING_URL = { 'TCP:// system-address:port' | NONE }

{ READ_WRITE_ROUTING_URL = 'TCP:// system-address:port' | NONE }

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

'TCP:// system-address:port'