Configurer le groupe de disponibilité Always On SQL Server sur Windows et Linux (multiplateforme)

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

Cet article explique les étapes pour créer un groupe de disponibilité Always On avec une réplique sur un serveur Windows et une autre réplique sur un serveur Linux.

Important

Les groupes de disponibilité SQL Server multiplateformes, qui incluent des réplicas hétérogènes avec une prise en charge totale de la haute disponibilité et de la reprise d’activité, sont proposés par DH2i DxEnterprise. Pour plus d’informations, consultez Groupes de disponibilité SQL Server avec des systèmes d’exploitation mixtes.

Consultez la vidéo suivante pour en savoir plus sur les groupes de disponibilité multiplateformes avec DH2i.

Cette configuration est multiplateforme, car les réplicas se trouvent sur des systèmes d’exploitation différents. Utilisez cette configuration pour la migration d’une plateforme vers l’autre ou la récupération d’urgence (DR). Cette configuration ne prend pas en charge la haute disponibilité.

Schéma d’un groupe de disponibilité avec le type de cluster None.

Avant de continuer, vous devez être familiarisé avec l’installation et la configuration des instances sur Windows et Linux.

Scénario

Dans ce scénario, deux serveurs se trouvent sur des systèmes d’exploitation différents. Un serveur Windows 2022 nommé WinSQLInstance héberge le réplica principal. Un serveur Linux nommé LinuxSQLInstance héberge le réplica secondaire.

Configurer l'AG

Les étapes de création du groupe de disponibilité sont les mêmes que celles permettant de créer un groupe de disponibilité pour les charges de travail avec échelle de lecture. Le type de cluster de groupe de disponibilité est NONE, car il n’y a pas de gestionnaire de cluster.

Pour les scripts de cet article, les crochets pointus < et > identifient les valeurs que vous devez remplacer pour votre environnement. Les crochets pointus ne sont pas requis pour les scripts.

  1. Installez SQL Server 2022 (16.x) sur Windows Server 2022, activez les groupes de disponibilité Always On à partir de Gestionnaire de configuration SQL Server et définissez l’authentification en mode mixte.

    Conseil

    Si vous validez cette solution dans Azure, placez les deux serveurs dans le même groupe à haute disponibilité pour vous assurer qu’ils sont séparés dans le centre de données.

    Activer les groupes de disponibilité

    Pour obtenir des instructions, consultez Activer ou désactiver la fonctionnalité de groupe de disponibilité Always On.

    Capture d’écran montrant comment activer les groupes de disponibilité.

    Le Gestionnaire de configuration SQL Server remarque que l’ordinateur n’est pas un nœud dans un cluster de basculement.

    Après avoir activé les groupes de disponibilité, redémarrez SQL Server.

    Définir l’authentification en mode mixte

    Pour obtenir des instructions, consultez Modifier le mode d’authentification du serveur.

  2. Installez SQL Server 2022 (16.x) sur Linux. Pour obtenir des instructions, consultez Guide à l’installation de SQL Server sur Linux. Activer hadr avec mssql-conf.

    Pour activer hadr via mssql-conf depuis une invite d’interpréteur de commandes, exécutez la commande suivante :

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

    Une fois que vous avez activé hadr, redémarrez l’instance SQL Server :

    sudo systemctl restart mssql-server.service

  3. Configurez le fichier hosts sur les deux serveurs ou enregistrez les noms de serveurs avec DNS.

  4. Ouvrez les ports de pare-feu pour TCP 1433 et 5022 sur Windows et Linux.

  5. Sur le réplica principal, créez une connexion à la base de données et un mot de passe.

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

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

    Attention

    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.

  6. Sur le réplica principal, créez une clé principale et un certificat, puis sauvegardez le certificat avec une clé privée.

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

CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
    WITH PRIVATE KEY (
         FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
         ENCRYPTION BY PASSWORD = '<private-key-password>'
);
GO

    Attention

    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.

  7. Copiez le certificat et la clé privée sur le serveur Linux (réplica secondaire) à l’adresse /var/opt/mssql/data. Vous pouvez utiliser pscp pour copier les fichiers sur le serveur Linux.

  8. Définissez le groupe et la propriété de la clé privée et du certificat sur mssql:mssql.

    Le script suivant définit le groupe et la propriété des fichiers.

    sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.pvk
sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.cer

    Dans le diagramme suivant, la propriété et le groupe sont définis correctement pour le certificat et la clé.

    Capture d’écran d’une fenêtre Git Bash montrant .cer et .pvk dans le dossier /var/opt/mssql/data.

  9. Sur le réplica secondaire, créez une connexion à la base de données et un mot de passe, puis créez une clé principale.

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

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

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

    Attention

    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.

  10. Sur le réplica secondaire, restaurez le certificat que vous avez copié sur /var/opt/mssql/data.

    CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '<private-key-password>'
);
GO

    Dans l’exemple précédent, remplacez <private-key-password> par le même mot de passe que vous avez utilisé lors de la création du certificat sur le réplica principal.

  11. Sur le réplica principal, créez un point de terminaison.

    CREATE ENDPOINT [Hadr_endpoint]
AS TCP
(
    LISTENER_IP = (0.0.0.0),
    LISTENER_PORT = 5022
)
FOR DATABASE_MIRRORING
(
    ROLE = ALL,
    AUTHENTICATION = CERTIFICATE dbm_certificate,
    ENCRYPTION = REQUIRED ALGORITHM AES
);

ALTER ENDPOINT [Hadr_endpoint]
STATE = STARTED;

GRANT CONNECT
ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];
GO

    Important

    Le pare-feu doit être ouvert pour le port TCP de l’écouteur. Dans le script précédent, le port est 5022. Utilisez n’importe quel port TCP disponible.

  12. Sur le réplica secondaire, créez le point de terminaison. Répétez le script précédent sur la copie secondaire pour créer le point de terminaison.

  13. Sur le réplica principal, créez un Groupe de Disponibilité avec CLUSTER_TYPE = NONE. L’exemple de script utilise SEEDING_MODE = AUTOMATIC pour créer le groupe de disponibilité (AG).

    Remarque

    Lorsque l’instance Windows de SQL Server utilise des chemins différents pour les données et les fichiers journaux, l’amorçage automatique échoue à l’instance Linux de SQL Server parce que ces chemins n’existent pas sur le réplica secondaire. Pour utiliser le script suivant pour un groupe de disponibilité multiplateforme (AG), la base de données nécessite un chemin d'accès identique pour les fichiers de données et les fichiers journaux sur le serveur Windows. Vous pouvez également mettre à jour le script pour définir SEEDING_MODE = MANUAL, puis sauvegarder et restaurer la base de données avec NORECOVERY pour amorcer la base de données.

    Ce comportement s’applique aux images de la place de marché Azure.

    Pour plus d’informations sur l’amorçage automatique, consultez Amorçage automatique - Disposition du disque.

    Avant d’exécuter le script, mettez à jour les valeurs de vos groupes de disponibilité (AG).

    • Remplacez <WinSQLInstance> par le nom du serveur de l’instance de réplique primaire.

    • Remplacez <LinuxSQLInstance> par le nom du serveur du replica secondaire d'une instance SQL Server.

    Pour créer le groupe de disponibilité, mettez à jour les valeurs et exécutez le script sur le réplica principal.

    CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA ON
N'<WinSQLInstance>' WITH (
    ENDPOINT_URL = N'tcp://<WinSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)
),
N'<LinuxSQLInstance>' WITH (
    ENDPOINT_URL = N'tcp://<LinuxSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL);
);

    Pour plus d’informations, consultez CREATE AVAILABILITY GROUP.

  14. Sur la réplique secondaire, rejoignez le GA.

    ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

  15. Créez une base de données pour l'AG. Les étapes de l’exemple utilisent une base de données nommée TestDB. Si vous utilisez l’amorçage automatique, définissez le même chemin d'accès pour les données et les fichiers journaux.

    Avant d’exécuter le script, mettez à jour les valeurs de votre base de données.

    • Remplacez TestDB par le nom de votre base de données.

    • Remplacez <F:\Path> par le chemin d’accès de votre base de données et de vos fichiers journaux. Utilisez le même chemin d’accès pour la base de données et les fichiers journaux.

    Vous pouvez également utiliser les chemins d’accès par défaut.

    Pour créer votre base de données, exécutez le script.

    CREATE DATABASE [TestDB] CONTAINMENT = NONE
ON
    PRIMARY (NAME = N'TestDB', FILENAME = N'<F:\Path>\TestDB.mdf')
    LOG ON (NAME = N'TestDB_log', FILENAME = N'<F:\Path>\TestDB_log.ldf');
GO

  16. Prenez une sauvegarde complète de la base de données.

  17. Si vous n’utilisez pas l’amorçage automatique, restaurez la base de données sur le serveur de la réplique secondaire (Linux). Migrez une base de données SQL Server de Windows vers Linux à l’aide de la sauvegarde et de la restauration. Restaurez la base de données WITH NORECOVERY sur le réplica secondaire.

  18. Ajoutez la base de données au groupe de disponibilité (AG). Mettez à jour l’exemple de script. Remplacez TestDB par le nom de votre base de données. Sur le réplica principal, exécutez la requête T-SQL pour ajouter la base de données à l'AG.

    ALTER AG [ag1] ADD DATABASE TestDB;
GO

  19. Vérifiez que la base de données est en cours de remplissage sur le réplica secondaire.

Basculer le réplica principal

Chaque groupe de disponibilité contient un seul réplica principal. Le réplica principal autorise les opérations de lecture et d’écriture. Pour modifier le réplica principal, vous pouvez effectuer un basculement. Dans un groupe de disponibilité standard, le gestionnaire de cluster automatise le processus de basculement. Dans un groupe de disponibilité avec un type de cluster défini sur AUCUN, le processus de basculement est manuel.

Il existe deux façons de basculer le réplica principal dans un groupe de disponibilité avec le type de cluster AUCUN :

  • Basculement manuel sans perte de données
  • Basculement manuel forcé avec perte de données

Basculement manuel sans perte de données

Utilisez cette méthode quand le réplica principal est disponible, mais que vous devez temporairement ou définitivement changer l’instance qui héberge le réplica principal. Pour éviter toute perte de données potentielle, avant d’effectuer le basculement manuel, vérifiez que la réplique secondaire cible est à jour.

Pour effectuer un basculement manuel sans perte de données :

  1. Rendez le réplica principal actuel et le réplica secondaire cible comme SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Pour vérifier que les transactions actives sont validées sur le réplica principal et sur au moins un réplica secondaire synchrone, exécutez la requête suivante :

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    Le réplica secondaire est synchronisé quand synchronization_state_desc a pour valeur SYNCHRONIZED.

  3. Mettre à jour REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT à 1.

    Le script suivant définit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT sur 1 sur un groupe de disponibilité nommé ag1. Avant d’exécuter le script suivant, remplacez ag1 par le nom de votre groupe de disponibilité :

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Ce paramétrage garantit que chaque transaction active est validée sur le réplica principal et sur au moins un réplica secondaire synchrone.

    Remarque

    Ce paramètre n’est pas propre au basculement et doit être défini en fonction des exigences de l’environnement.

  4. Définissez le réplica principal et le ou les réplicas secondaires qui ne participent pas au basculement hors connexion pour préparer le changement de rôle :

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Promouvez le réplica secondaire en réplica principal.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Mettez à jour le rôle de l'ancien réplica principal et des autres réplicas secondaires en SECONDARY et exécutez la commande suivante sur l’instance de SQL Server qui héberge l’ancien réplica principal :

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Remarque

    Pour supprimer un groupe de disponibilité, utilisez DROP AVAILABILITY GROUP. Pour un groupe de disponibilité créé avec le type de cluster NONE ou EXTERNAL, exécutez la commande sur toutes les répliques faisant partie du groupe de disponibilité.

  7. Pour reprendre le déplacement des données, exécutez la commande suivante pour chaque base de données du groupe de disponibilité sur l’instance de SQL Server qui héberge le réplica principal :

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Recréez tout écouteur que vous avez créé pour la mise à l'échelle de la lecture et qui n’est pas géré par un gestionnaire de cluster. Si l’auditeur d’origine pointe vers l’ancien principal, supprimez-le et recréez-le pour qu’il pointe vers le nouveau principal.

Basculement manuel forcé avec perte de données

Si la réplique principale n’est pas disponible et ne peut pas être récupérée immédiatement, vous devez forcer un basculement vers la réplique secondaire avec perte de données. Cependant, si le réplica principal d’origine récupère après le basculement, il réassumera le rôle principal. Pour éviter que chaque réplique soit dans un état différent, supprimez le primaire d'origine du groupe de disponibilité après un basculement forcé avec perte de données. Une fois que le serveur principal d’origine revient en ligne, supprimez-y entièrement le groupe de disponibilité.

Pour forcer un basculement manuel avec perte de données du réplica principal N1 vers le réplica secondaire N2, effectuez les étapes suivantes :

  1. Sur la réplique secondaire (N2), initiez le basculement forcé :

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Sur la nouvelle réplique principale (N2), supprimez la réplique principale d’origine (N1) :

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Vérifiez que tout le trafic d’application pointe vers l’écouteur et/ou le nouveau réplica principal.

  4. Si le principal d’origine (N1) est en ligne, mettez immédiatement hors connexion le groupe de disponibilité AGRScale sur le principal d’origine (N1).

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. S’il existe des données ou des modifications non synchronisées, conservez ces données via des sauvegardes ou d’autres options de réplication des données qui répondent aux besoins de votre entreprise.

  6. Ensuite, supprimez le groupe de disponibilité du réplica principal initial (N1) :

    DROP AVAILABILITY GROUP [AGRScale];

  7. Supprimez la base de données du groupe de disponibilité sur le réplica principal d’origine (N1) :

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Facultatif) Si vous le souhaitez, vous pouvez maintenant ajouter N1 comme nouvelle réplique secondaire au groupe de disponibilité AGRScale.

Cet article a examiné les étapes de création d’un groupe de disponibilité multiplateforme pour prendre en charge les charges de travail de migration ou de lecture à grande échelle. Il peut être utilisé pour la récupération d’urgence manuelle. Il a également expliqué comment basculer le groupe de disponibilité (AG). Un groupe de disponibilité multiplateforme utilise le type de cluster NONE et ne prend pas en charge la haute disponibilité.

Contenu connexe

  • Last updated on