Créer et configurer un groupe de disponibilité pour SQL Server sur Linux

S’applique à :SQL Server sur Linux

Ce tutoriel montre comment créer et configurer un groupe de disponibilité (AG) pour SQL Server sur Linux. Contrairement à SQL Server 2016 (13.x) et aux versions antérieures sur Windows, vous pouvez activer des groupes de disponibilité en commençant ou non par créer le cluster Pacemaker sous-jacent. L’intégration au cluster, si nécessaire, se produit ultérieurement.

Le tutoriel inclut les tâches suivantes :

Activer des groupes de disponibilité.
Créer des points de terminaison de groupe de disponibilité et des certificats.
Utiliser SQL Server Management Studio (SSMS) ou Transact-SQL pour créer un groupe de disponibilité.
Créer la connexion SQL Server et les autorisations pour Pacemaker.
Créer des ressources de groupe de disponibilité dans un cluster Pacemaker (type externe uniquement).

Prerequisites

Déployez le cluster de haute disponibilité Pacemaker. Pour plus d’informations, voir Déploiement d’un cluster Pacemaker pour SQL Server sur Linux.

Activez la fonctionnalité Groupes de disponibilité

Vous ne pouvez pas utiliser PowerShell ou le Gestionnaire de configuration SQL Server pour activer la fonctionnalité Groupes de disponibilité comme sur Windows. Sur Linux, vous pouvez activer la fonctionnalité des groupes de disponibilité de deux façons : utiliser l’utilitaire ou modifier le mssql-confmssql.conf fichier manuellement.

Important

Vous devez activer la fonctionnalité AG pour les réplicas à des fins de configuration seulement, même sur SQL Server Express.

Utilisez le `mssql-conf` service public

À une invite, exécutez la commande suivante :

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1

Modifiez le fichier mssql-conf

Vous pouvez également modifier le mssql.conf fichier, situé sous le /var/opt/mssql dossier. Ajoutez les lignes suivantes :

[hadr]

hadr.hadrenabled = 1

Redémarrez SQL Server

Après avoir activé des groupes de disponibilité, vous devez redémarrer SQL Server. Utilisez la commande suivante :

sudo systemctl restart mssql-server

Créez les points de terminaison du groupe de disponibilité et les certificats

Un groupe de disponibilité utilise des points de terminaison TCP pour la communication. Sous Linux, SQL Server prend en charge les points de terminaison réseau d’un groupe de disponibilité uniquement si vous utilisez des certificats pour l’authentification. Vous devez restaurer le certificat à partir d’une instance sur toutes les autres instances qui participent en tant que réplicas au sein du même groupe de disponibilité. Le processus de certificat est requis même pour un réplica de configuration uniquement.

Vous ne pouvez créer des points de terminaison et restaurer des certificats qu’en utilisant Transact-SQL. Vous pouvez également utiliser des certificats non générés par SQL Server. Vous avez également besoin d’un processus de gestion et de remplacement des certificats qui arrivent à expiration.

Important

Si vous envisagez l’Assistant SQL Server Management Studio pour créer le groupe de disponibilité, vous devez toujours créer et restaurer les certificats à l’aide de Transact-SQL sur Linux.

Pour obtenir une syntaxe complète sur les options disponibles pour les différentes commandes (y compris la sécurité), consultez :

Note

Bien que vous créiez un groupe de disponibilité, le type de point de terminaison utilise FOR DATABASE_MIRRORING, car le type de terminaison partage des aspects sous-jacents avec cette fonctionnalité désormais obsolète.

Cet exemple crée des certificats pour une configuration à trois nœuds. Les noms d’instance sont LinAGN1, LinAGN2 et LinAGN3.

Exécutez le script suivant sur LinAGN1 pour créer la clé principale, le certificat et le point de terminaison, ainsi que pour sauvegarder le certificat. Pour cet exemple, le point d’extrémité utilise le port TCP typique 5022.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE LinAGN1_Cert
WITH SUBJECT = 'LinAGN1 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN1_Cert
TO FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN1_Cert,
    ROLE = ALL
);
GO

Procédez de la même façon sur LinAGN2 :

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE LinAGN2_Cert
WITH SUBJECT = 'LinAGN2 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN2_Cert
TO FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN2_Cert,
    ROLE = ALL
);
GO

Enfin, exécutez la même séquence sur LinAGN3 :

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE LinAGN3_Cert
WITH SUBJECT = 'LinAGN3 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN3_Cert
TO FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP
(
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING
(
    AUTHENTICATION = CERTIFICATE LinAGN3_Cert,
    ROLE = ALL
);
GO

Utilisez scp un autre utilitaire pour copier les sauvegardes du certificat vers chaque nœud auquel vous souhaitez faire partie de l’AG.

Pour cet exemple :
- Copiez LinAGN1_Cert.cer vers LinAGN2 et LinAGN3.
- Copiez LinAGN2_Cert.cer vers LinAGN1 et LinAGN3.
- Copiez LinAGN3_Cert.cer vers LinAGN1 et LinAGN2.
Modifiez la propriété et le groupe associé aux fichiers de certificat copiés sur mssql.
```
sudo chown mssql:mssql <CertFileName>
```
Créez les connexions au niveau de l’instance et les utilisateurs associés à LinAGN2 et LinAGN3 sur LinAGN1.
```
CREATE LOGIN LinAGN2_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN2_User
FOR LOGIN LinAGN2_Login;
GO

CREATE LOGIN LinAGN3_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN3_User
FOR LOGIN LinAGN3_Login;
GO
```
Caution

Votre mot de passe doit respecter la stratégie de mot de passe par défaut de SQL Server. Par défaut, le mot de passe doit avoir au moins huit caractères appartenant à trois des quatre groupes suivants : lettres majuscules, lettres minuscules, chiffres de base 10 et symboles. Les mots de passe peuvent comporter jusqu'à 128 caractères. Utilisez des mots de passe aussi longs et complexes que possible.

Restaurez LinAGN2_Cert et LinAGN3_Cert sur LinAGN1. Les certificats des autres répliques sont essentiels à la communication et à la sécurité de l’AG.

CREATE CERTIFICATE LinAGN2_Cert
    AUTHORIZATION LinAGN2_User
    FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
    AUTHORIZATION LinAGN3_User
    FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Accordez aux connexions associées à LinAGN2 et à LinAGN3 l’autorisation de se connecter au point de terminaison sur LinAGN1.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
```

Créez les connexions au niveau de l’instance et les utilisateurs associés à LinAGN1 et LinAGN3 sur LinAGN2.

CREATE LOGIN LinAGN1_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN3_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN3_User
FOR LOGIN LinAGN3_Login;
GO

Restaurez LinAGN1_Cert et LinAGN3_Cert sur LinAGN2.

CREATE CERTIFICATE LinAGN1_Cert
    AUTHORIZATION LinAGN1_User
    FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
    AUTHORIZATION LinAGN3_User
    FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Accordez aux connexions associées à LinAGN1 et à LinAGN3 l’autorisation de se connecter au point de terminaison sur LinAGN2.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO
```

Créez les connexions au niveau de l’instance et les utilisateurs associés à LinAGN1 et LinAGN2 sur LinAGN3.

CREATE LOGIN LinAGN1_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN2_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN2_User
FOR LOGIN LinAGN2_Login;
GO

Restaurez LinAGN1_Cert et LinAGN2_Cert sur LinAGN3.

CREATE CERTIFICATE LinAGN1_Cert
    AUTHORIZATION LinAGN1_User
    FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN2_Cert
    AUTHORIZATION LinAGN2_User
    FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

Accordez aux connexions associées à LinAGN1 et à LinAGN2 l’autorisation de se connecter au point de terminaison sur LinAGN3.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO
```

Créez le groupe de disponibilité

Cette section montre comment utiliser SQL Server Management Studio (SSMS) ou Transact-SQL pour créer le groupe de disponibilité pour SQL Server.

Utilisez SQL Server Management Studio.

Cette section montre comment créer un AG avec un type de cluster externe en utilisant SSMS avec l’assistant du groupe de disponibilité nouveau.

Dans SSMS, étendez Always On High Availability, cliquez avec le bouton droit sur Groupes de disponibilité et sélectionnez Assistant Nouveau groupe de disponibilité.
Dans la boîte d’introduction de la boîte d’endroit, sélectionnez Suivant.
Dans la boîte de dialogue Spécifier les options du groupe de disponibilité, entrez un nom pour le groupe de disponibilité, puis sélectionnez un type de cluster parmi EXTERNAL ou NONE dans la liste déroulante. Utilisez EXTERNAL lorsque vous déployez Pacemaker. Utilisez NONE pour des scénarios spécialisés, tels que l'échelle horizontale de lecture. La sélection de l’option de détection d’intégrité au niveau de la base de données est facultative. Pour plus d’informations sur cette option, consultez Option de détection de l’intégrité au niveau base de données du groupe de disponibilité pour le basculement. Sélectionnez Suivant.
Dans la boîte de dialogue Sélectionner les bases de données , sélectionnez les bases de données auxquelles vous souhaitez participer à l’AG. Chaque base de données doit avoir une sauvegarde complète avant de pouvoir l’ajouter à un groupe de disponibilité (AG). Sélectionnez Suivant.
Dans la boîte de dialogue Spécifier les répliques , sélectionnez Ajouter une réplice.
Dans la boîte de dialogue Connect to Server, saisissez le nom de l’instance Linux de SQL Server pour la réplique secondaire, ainsi que les identifiants pour se connecter. Sélectionnez Se connecter.
Répétez les deux étapes précédentes pour l'instance qui contiendra une réplique uniquement de configuration ou une autre réplique secondaire.
Les trois instances apparaissent dans la boîte de dialogue Spécifier les répliques . Si vous utilisez un type de cluster Externe, pour la réplique secondaire qui est une véritable seconde, assurez-vous que le mode disponibilité correspond à celui de la réplique principale et réglez le mode de basculement sur Externe. Pour le réplica de configuration uniquement, sélectionnez un mode de disponibilité de configuration uniquement.

L’exemple suivant montre un groupe de disponibilité avec deux réplicas, un type de cluster externe et un réplica de configuration uniquement.

L’exemple suivant montre un groupe de disponibilité avec deux réplicas, un type de cluster None et un réplica de configuration uniquement.
Si vous souhaitez changer les préférences de sauvegarde, sélectionnez l’onglet Préférences de sauvegarde . Pour plus d’informations sur les préférences de sauvegarde auprès des AG, voir Configurer les sauvegardes sur des répliques secondaires d’un groupe de disponibilité Always On.
Si vous utilisez des réplicas secondaires lisibles ou créez un groupe de disponibilité avec un type de cluster None pour l’échelle lecture, vous pouvez créer un écouteur en sélectionnant l’onglet Écouteur. Un écouteur peut également être ajouté ultérieurement. Pour créer un écouteur, sélectionnez l’option Créer un groupe d’écouteur de disponibilité et saisissez un nom, un port TCP/IP, et si vous souhaitez utiliser une adresse IP DHCP statique ou automatiquement attribuée. Pour un AG avec un type de cluster None, utilisez une IP statique correspondant à l’adresse IP du principal.
Si vous créez un écouteur pour des scénarios lisibles, SSMS permet de créer un routage en lecture seule dans l’assistant. Vous pouvez aussi l’ajouter plus tard en utilisant SSMS ou Transact-SQL. Pour activer le routage en lecture seule maintenant :
1. Sélectionnez l’onglet Read-Only Routement .
2. Entrez les URL pour les réplicas en lecture seule. Ces URL sont similaires aux points de terminaison, sauf qu’elles utilisent le port de l’instance et non le point de terminaison.
  1. Sélectionnez chaque URL et, au bas, choisissez les versions lisibles. Pour sélectionner plusieurs éléments, maintenez la touche Maj enfoncée ou faites glisser pour sélectionner.
Sélectionnez Suivant.
Sélectionnez la méthode pour initialiser les réplicas secondaires. La valeur par défaut consiste à utiliser l'amorçage automatique, qui requiert le même chemin sur tous les serveurs participant au groupe de disponibilité. L’Assistant peut également sauvegarder, copier et restaurer (deuxième option) ; joindre si vous avez sauvegardé, copié et restauré manuellement la base de données sur le ou les réplicas (troisième option) ; ou ajouter ultérieurement la base de données (dernière option). Comme pour les certificats, si vous effectuez manuellement des sauvegardes et les copiez, définissez des autorisations sur les fichiers de sauvegarde sur les autres copies de sauvegarde. Sélectionnez Suivant.
Dans la boîte de dialogue Validation , si l’assistant ne retourne pas Succès pour tous les tests, enquêtez plus en détail. Certains avertissements sont acceptables et ne sont pas irrécupérables, par exemple si vous ne créez pas d’écouteur. Sélectionnez Suivant.
Dans la boîte de dialogue Résumé , sélectionnez Terminer. Le processus de création de l'AG commence.
Lorsque la création de l’AG est terminée, sélectionnez Fermer sur la page des résultats . Vous pouvez maintenant voir le groupe de disponibilité sur les réplicas dans les vues de gestion dynamique, ainsi que dans le dossier Haute disponibilité Always On dans SSMS.

Utiliser Transact-SQL

Cette section montre des exemples de création d’un AG en utilisant Transact-SQL. L’écouteur et le routage en lecture seule peuvent être configurés après la création du groupe de disponibilité. Vous pouvez modifier le groupe de disponibilité AG en utilisant ALTER AVAILABILITY GROUP, mais vous ne pouvez pas changer le type de cluster dans SQL Server 2017 (14.x). Si vous ne vouliez pas créer de groupe de disponibilité avec un type de cluster externe, vous devez le supprimer et le recréer avec un type de cluster None.

Pour plus d’informations et d’autres options, voir :

Exemple A : deux réplicas avec un réplica à configuration uniquement (type de cluster externe)

Cet exemple montre comment créer un groupe de disponibilité à deux réplicas qui utilise un réplica de configuration uniquement.

Exécutez l’instruction suivante sur le nœud réplique principal, qui contient la copie de lecture/écriture des bases de données. Cet exemple utilise l’amorçage automatique.

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE <DBName>
REPLICA ON
N'LinAGN1' WITH (
   ENDPOINT_URL = N' TCP://LinAGN1.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
N'LinAGN2' WITH (
   ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   SEEDING_MODE = AUTOMATIC
),
N'LinAGN3' WITH (
   ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
   AVAILABILITY_MODE = CONFIGURATION_ONLY
);
GO

Dans une fenêtre de requête connectée à l’autre réplique, exécutez l’instruction suivante pour relier la réplique à l’AG et commencer à semer de la réplique primaire vers la secondaire.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO
```
Dans une fenêtre de requête connectée à la réplique uniquement en configuration, exécutez l’instruction suivante pour la relier à l’AG.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
```

Exemple B : trois répliques avec routage en lecture seule (type de cluster externe)

Cet exemple vous montre comment configurer le routage en lecture seule dans le cadre de la création initiale de l’AG pour trois répliques complètes.

Exécutez l’instruction suivante sur le nœud qui joue le rôle de réplica principal et contient la copie complète en lecture/écriture des bases de données. Cet exemple utilise l’amorçage automatique.

CREATE AVAILABILITY GROUP [<AGName>] WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE < DBName > REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN2.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:1433')
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:1433')
    ),
    N'LinAGN3' WITH (
        ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN2.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN3.FullyQualified.Name:1433')
    )
    LISTENER '<ListenerName>' (
        WITH IP = ('<IPAddress>', '<SubnetMask>'), Port = 1433
    );
GO

Voici quelques points à noter concernant cette configuration :

AGName est le nom du groupe de disponibilité.
DBName est le nom de la base de données que vous utilisez avec le groupe de disponibilité. Il peut aussi s’agir d’une liste de noms séparés par des virgules.
ListenerName est un nom qui diffère de n’importe lequel des serveurs ou nœuds sous-jacents. Vous l’enregistrez dans le DNS avec IPAddress.
IPAddress est l’adresse IP de ListenerName. C’est aussi unique et ne correspond à aucun serveur ou nœud. Les applications et les utilisateurs finaux utilisent soit ListenerName, soit IPAddress pour se connecter au AG.
- SubnetMask est le masque de sous-réseau de IPAddress. Dans SQL Server 2019 (15.x) et les versions précédentes, cette valeur est 255.255.255.255. Dans SQL Server 2022 (16.x) et versions ultérieures, cette valeur est 0.0.0.0.

Dans une fenêtre de requête connectée à l’autre réplica, exécutez la commande suivante pour joindre le réplica au groupe de disponibilité et initier le processus d’amorçage du réplica principal au réplica secondaire.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO
```
Répétez l’étape 2 pour le troisième réplica.

Exemple C : deux réplicas avec routage en lecture seule (type de cluster « None »)

Cet exemple crée une configuration à deux répliques utilisant un type de cluster de None. Utilisez cette configuration pour le scénario de lecture à échelle où vous ne vous attendez pas à un basculement. Cette étape crée l’écouteur qui est la réplique principale et configure le routage en lecture seule avec une fonctionnalité round-robin.

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE)
FOR DATABASE <DBName> REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name: <PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(
            ALLOW_CONNECTIONS = READ_WRITE,
            READ_ONLY_ROUTING_LIST = (('LinAGN1.FullyQualified.Name'.'LinAGN2.FullyQualified.Name'))
        ),
        SECONDARY_ROLE(
            ALLOW_CONNECTIONS = ALL,
            READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:<PortOfInstance>'
        )
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
                 ('LinAGN1.FullyQualified.Name',
                    'LinAGN2.FullyQualified.Name')
                 )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfInstance>')
    ),
    LISTENER '<ListenerName>' (WITH IP = (
             '<PrimaryReplicaIPAddress>',
             '<SubnetMask>'),
            Port = <PortOfListener>
    );
GO

Dans cet exemple :

AGName est le nom du groupe de disponibilité.
DBName est le nom de la base de données que vous utilisez avec le groupe de disponibilité. Il peut aussi s’agir d’une liste de noms séparés par des virgules.
PortOfEndpoint est le numéro de port du point de terminaison que vous créez.
- PortOfInstanceest le numéro de port pour l’instance de SQL Server.
ListenerName est un nom provisoire différent de toutes les répliques sous-jacentes.
PrimaryReplicaIPAddress est l’adresse IP du réplica principal.
- SubnetMask est le masque de sous-réseau de IPAddress. Dans SQL Server 2019 (15.x) et les versions précédentes, cette valeur est 255.255.255.255. Dans SQL Server 2022 (16.x) et versions ultérieures, cette valeur est 0.0.0.0.

Joignez le réplica secondaire au groupe de disponibilité et lancez l’amorçage automatique.

ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = NONE);
GO

ALTER AVAILABILITY GROUP [<AGName>]
GRANT CREATE ANY DATABASE;
GO

Un cluster Pacemaker à haute disponibilité qui utilise SQL Server sur Linux a besoin d’accéder à l’instance SQL Server ainsi que des autorisations sur le groupe de disponibilité en lui-même. Ces étapes créent la connexion et les autorisations associées, ainsi qu’un fichier qui indique à Pacemaker comment s’authentifier auprès de SQL Server.

Dans une fenêtre de requête connectée à la première réplique, exécutez le script suivant :

CREATE LOGIN PMLogin
    WITH PASSWORD = '<password>';
GO

GRANT VIEW SERVER STATE TO PMLogin;
GO

GRANT ALTER, CONTROL, VIEW DEFINITION
ON AVAILABILITY GROUP::<AGThatWasCreated> TO PMLogin;
GO

Sur le nœud 1, ajoutez les deux lignes suivantes au /var/opt/mssql/secrets/passwd fichier :
```
PMLogin

<password>
```
Vous devrez peut-être augmenter vos autorisations pour sudo modifier ce fichier.

Verrouillez le fichier :

sudo chmod 400 /var/opt/mssql/secrets/passwd

Répétez les étapes 1 à 5 sur les autres serveurs qui servent de réplicas.

Créer les ressources de groupe de disponibilité dans le cluster Pacemaker (externe uniquement)

Après avoir créé un AG (groupe de disponibilité) dans SQL Server, vous devez créer les ressources correspondantes dans Pacemaker lorsque vous spécifiez un type de cluster Externe. Un groupe de disponibilité a besoin de deux ressources : la ressource du groupe de disponibilité et une ressource d’adresse IP. La configuration de la ressource d’adresse IP est facultative si vous n’utilisez pas d’écouteur. Toutefois, il est recommandé lorsque vous avez besoin de fonctionnalités d’écouteur.

La ressource AG que vous créez est un type de ressource appelé clone. La ressource AG possède des copies sur chaque nœud, ainsi qu’une ressource contrôlante appelée ressource promue . La ressource promue correspond au serveur qui héberge la réplique principale. Les autres ressources hébergent des répliques secondaires (régulières ou en configuration uniquement), et elles peuvent être promues lors d’un basculement.

Note

Dans SQL Server 2025 (17.x) avec mise à jour cumulative (CU) 3 et versions ultérieures, l’agent de haute disponibilité Pacemaker v2 (préversion) est disponible pour Red Hat Enterprise Linux (RHEL) et Ubuntu via le mssql-server-ha package. Vous pouvez évaluer l’agent HA v2 de Pacemaker lors de déploiements non productifs. L’agent HA existant de Pacemaker (v1) est toujours entièrement pris en charge pour les déploiements en production. Pour plus d’informations, consultez Pacemaker HA Agent v2 (préversion).

Red Hat Enterprise Linux (RHEL) et Ubuntu
SUSE Linux Enterprise Server (SLES)

Agent de haute disponibilité Pacemaker v1

Créez la ressource AG dans le Pacemaker à l’aide de l’agent Haute Disponibilité Pacemaker (v1) : (ocf:mssql:ag)
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s promotable notify=true
```
Dans cet exemple, NameForAGResource est le nom unique que vous attribuez à cette ressource de cluster pour le groupe de disponibilité et AGName est le nom du groupe de disponibilité que vous avez créé.
Créez la ressource d’adresse IP pour le groupe de disponibilité qui sera associé à la fonctionnalité d’écouteur.
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
Dans cet exemple, NameForIPResource il s’agit du nom unique de la ressource IP et IPAddress de l’adresse IP statique que vous affectez à la ressource.
Pour vous assurer que l’adresse IP et la ressource AG s’exécutent sur le même nœud, configurez une contrainte de colocalisation.
```
sudo pcs constraint colocation add <NameForIPResource> with promoted <NameForAGResource>-clone INFINITY
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP et NameForAGResource est celui de la ressource de groupe de disponibilité.
Créez une contrainte d’ordre pour s’assurer que la ressource AG s’exécute avant l’adresse IP. Bien que la contrainte de colocation implique une contrainte d'ordonnancement, cette étape la renforce.
```
sudo pcs constraint order promote <NameForAGResource>-clone then start <NameForIPResource>
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP et NameForAGResource est celui de la ressource de groupe de disponibilité.

Pacemaker HA Agent v2 (préversion)

L’agent HA de Pacemaker v2 utilise une architecture basée sur le service. L’agent fonctionne comme un service système dédié nommé mssql-pcsag, qui est responsable de la gestion des opérations de haute disponibilité spécifiques à SQL Server et de la communication avec Pacemaker.

Vous gérez le mssql-pcsag service via des contrôles de service système standard. Démarrez, arrêtez, redémarrez, et vérifiez le statut de ce service selon les besoins avec les commandes suivantes :

sudo systemctl start mssql-pcsag  # Start the Pacemaker HA agent v2 (mssql-pcsag) service
sudo systemctl stop mssql-pcsag  # Stop the Pacemaker HA agent v2 (mssql-pcsag) service
sudo systemctl restart mssql-pcsag  # Restart the Pacemaker HA agent v2 (mssql-pcsag) service
sudo systemctl status mssql-pcsag  # Check the status of the Pacemaker HA agent v2 (mssql-pcsag) service

Pacemaker interagit avec les groupes de disponibilité SQL Server via le mssql-pcsag service. Pour que la surveillance et le basculement des groupes de disponibilité se fassent correctement :

Le cluster Pacemaker doit être en cours d’exécution.
Le mssql-pcsag service doit être en cours d’exécution.

Bien que Pacemaker et mssql-pcsag composants distincts, ils fonctionnent ensemble à l’exécution. Si Pacemaker ou le mssql-pcsag service s’arrêtent, les opérations de basculement du groupe de disponibilité ne fonctionnent pas comme prévu.

Note

Le redémarrage du mssql-pcsag service ne redémarre pas SQL Server. De même, le redémarrage de SQL Server ne redémarre pas automatiquement l’agent de haute disponibilité Pacemaker. Vérifiez que les deux services s’exécutent pendant la résolution des problèmes.

L’agent haute disponibilité Pacemaker v2 introduit des améliorations de fiabilité et de performances sur l’agent précédent, notamment :

Amélioration des performances de basculement pour réduire à la fois les temps de basculement prévus et ceux imprévus.
Prise en charge des stratégies de basculement automatique flexibles, notamment la configuration du niveau de condition d’échec et du délai d'attente de contrôle d'intégrité.

Exemple : l’instruction Transact-SQL suivante modifie le niveau de condition d’échec d’un groupe de disponibilité existant nommé AG1 au niveau 2 :
```
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);
```
Exemple : l’instruction Transact-SQL suivante modifie le seuil de délai d’expiration du contrôle d’intégrité d’un groupe de disponibilité existant nommé AG1 à 60 000 millisecondes (60 secondes).
```
ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT = 60000);
```
Exemple : après avoir appliqué la configuration, utilisez l’instruction Transact-SQL suivante pour vérifier le niveau de condition d’échec configuré et le délai d’expiration du contrôle d’intégrité pour les groupes de disponibilité.
```
SELECT failure_condition_level,
       health_check_timeout
FROM sys.availability_groups;
```
Prise en charge de TLS 1.3 pour la communication entre le cluster Pacemaker et SQL Server.

Créez la ressource AG dans Pacemaker à l'aide de l'agent Pacemaker HA v2 : (ocf:mssql:agv2)
```
sudo pcs resource create <NameForAGResource> ocf:mssql:agv2 ag_name=<AGName> meta failure-timeout=30s promotable notify=true
```
Si vous effectuez une mise à niveau de l’agent HA Pacemaker v1 vers v2, supprimez la ressource AG existante avant de créer la ressource agv2.
```
sudo pcs resource delete <NameForAGResource>
```
Cette opération interrompt temporairement la synchronisation du groupe de disponibilité pendant que la ressource est recréée. La suppression et la recréation de la ressource Pacemaker AG ne suppriment pas l'AG. Une fois la ressource recréée, Pacemaker reprend automatiquement la gestion et la synchronisation du groupe de disponibilité (AG).
Créez la ressource d’adresse IP pour le groupe de disponibilité qui sera associé à la fonctionnalité d’écouteur.
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
Dans cet exemple, NameForIPResource il s’agit du nom unique de la ressource IP et IPAddress de l’adresse IP statique que vous affectez à la ressource.
Pour vous assurer que l’adresse IP et la ressource AG s’exécutent sur le même nœud, configurez une contrainte de colocalisation.
```
sudo pcs constraint colocation add <NameForIPResource> with promoted <NameForAGResource>-clone INFINITY
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP et NameForAGResource est celui de la ressource de groupe de disponibilité.
Créez une contrainte de classement pour vous assurer que la ressource de groupe de disponibilité est active et en cours d’exécution avant l’adresse IP. Bien que la contrainte de colocation implique une contrainte d'ordonnancement, cette étape la renforce.
```
sudo pcs constraint order promote <NameForAGResource>-clone then start <NameForIPResource>
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP et NameForAGResource est celui de la ressource de groupe de disponibilité.

Note

À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

Créez la ressource AG avec la syntaxe suivante :

primitive <NameForAGResource> \
ocf:mssql:ag \
params ag_name="<AGName>" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Promoted" \
op notify timeout=60s
clone ms-ag_cluster <NameForAGResource> \
meta promoted-max="1" promoted-node-max="1" clone-max="3" \
    promotable="true" clone-node-max="1" notify="true" \
commit

Dans cet exemple, NameForAGResource est le nom unique que vous donnez à cette ressource de cluster pour l’AG, et AGName c’est le nom de l’AG que vous créez.

Créez la ressource d’adresse IP pour le groupe de disponibilité qui sera associé à la fonctionnalité d’écouteur.
```
crm configure \
primitive <NameForIPResource> \
   ocf:heartbeat:IPaddr2 \
   params ip=<IPAddress> \
      cidr_netmask=<Netmask>
```
Dans cet exemple, NameForIPResource il s’agit du nom unique de la ressource IP et IPAddress de l’adresse IP statique que vous affectez à la ressource. Sur SLES, vous devez aussi fournir le masque de réseau. Par exemple, 255.255.255.0 a la valeur 24 pour Netmask.
Pour vous assurer que l’adresse IP et la ressource AG s’exécutent sur le même nœud, configurez une contrainte de colocalisation.
```
crm configure <NameForConstraint> inf: \
<NameForIPResource> <NameForAGResource>:Promoted
commit
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP, NameForAGResource est le nom de la ressource AG, et NameForConstraint est le nom de la contrainte.
Créez une contrainte d’ordre pour s’assurer que la ressource AG s’exécute avant l’adresse IP. Bien que la contrainte de colocation implique une contrainte d'ordonnancement, cette étape la renforce.
```
crm configure \
order <NameForConstraint> Mandatory: <NameForAGResource>:promote <NameForIPResource>:start
commit
```
Dans cet exemple, NameForIPResource est le nom de la ressource IP, NameForAGResource est le nom de la ressource AG, et NameForConstraint est le nom de la contrainte.

Failover du groupe de disponibilité Always On sous Linux

Commentaires

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

Last updated on 2026-08-14

Créer et configurer un groupe de disponibilité pour SQL Server sur Linux

Prerequisites

Activez la fonctionnalité Groupes de disponibilité

Utilisez le mssql-conf service public

Modifiez le fichier mssql-conf

Redémarrez SQL Server

Créez les points de terminaison du groupe de disponibilité et les certificats

Créez le groupe de disponibilité

Utilisez SQL Server Management Studio.

Utiliser Transact-SQL

Exemple A : deux réplicas avec un réplica à configuration uniquement (type de cluster externe)

Exemple B : trois répliques avec routage en lecture seule (type de cluster externe)

Exemple C : deux réplicas avec routage en lecture seule (type de cluster « None »)

Créer la connexion SQL Server et les autorisations pour Pacemaker

Créer les ressources de groupe de disponibilité dans le cluster Pacemaker (externe uniquement)

Agent de haute disponibilité Pacemaker v1

Pacemaker HA Agent v2 (préversion)

Contenu connexe

Commentaires

Ressources supplémentaires

Utilisez le `mssql-conf` service public