Partage via

Basculement du groupe de disponibilité Always On sur Linux

  • Article

S’applique à :SQL Server - Linux

Dans le contexte d'un groupe de disponibilité, le rôle principal et le rôle secondaire des réplicas de disponibilité sont généralement interchangeables dans un processus appelé basculement. Trois formes de basculement existent : basculement automatique (sans perte de données), basculement manuel planifié (sans perte de données) et basculement manuel forcé (avec perte de données possible), ce dernier étant généralement appelé basculement forcé. Les basculements automatiques et manuels programmés préservent toutes vos données. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Autrement dit, un groupe de disponibilité bascule vers l’un de ses réplicas secondaires (cible de basculement actuelle).

Pour obtenir des informations en arrière-plan sur le basculement, consultez Basculement et modes de basculement.

Basculement manuel

Utilisez les outils de gestion de cluster pour basculer un groupe de disponibilité managé par un gestionnaire de cluster externe. Par exemple, si une solution utilise Pacemaker pour gérer un cluster Linux, utilisez pcs pour effectuer des basculements manuels sur RHEL ou Ubuntu. Sur SLES, utilisez crm.

Important

Dans des opérations normales, ne basculez pas avec les outils d’administration Transact-SQL ou SQL Server tels que SSMS ou PowerShell. Lorsque CLUSTER_TYPE = EXTERNAL, la seule valeur acceptable pour FAILOVER_MODE est EXTERNAL. Avec ces paramètres, toutes les actions de basculement manuelles ou automatiques sont exécutées par le gestionnaire de cluster externe. Pour obtenir des instructions et forcer le basculement avec perte de données potentielle, consultez Forcer le basculement.

Étape du basculement manuel

Pour effectuer un basculement, le réplica secondaire qui deviendra le réplica principal doit être synchrone. Si un réplica secondaire est asynchrone, modifiez le mode de disponibilité.

Basculement manuel en deux étapes.

Tout d'abord, basculez manuellement en déplaçant la ressource du groupe de disponibilité du nœud de cluster qui possède les ressources vers un nouveau nœud.

Le cluster bascule la ressource du groupe de disponibilité et ajoute une contrainte d’emplacement. Cette contrainte configure la ressource pour qu’elle s’exécute sur le nouveau nœud. Supprimez cette contrainte pour pouvoir réussir le basculement à l’avenir.

Ensuite, supprimez la contrainte d’emplacement.

Étape 1. Basculer manuellement en déplaçant la ressource du groupe de disponibilité

Pour basculer manuellement une ressource du groupe de disponibilité nommée ag_cluster vers le nœud de cluster nommé nodeName2, exécutez la commande appropriée pour votre distribution :

  • Exemple RHEL/Ubuntu

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

  • Exemple SLES

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Important

Lorsque vous utilisez l’option --lifetime, la contrainte d’emplacement créée pour déplacer la ressource est temporaire par nature et est valide pendant 30 secondes dans l’exemple précédent. Veuillez Noter que la contrainte temporaire n’est pas supprimée automatiquement et peut apparaître dans la liste de contraintes, mais comme une contrainte expirée. Les contraintes expirées n’affectent pas le comportement de basculement du cluster pacemaker. Si vous n’utilisez pas l’option --lifetime pendant le déplacement de la ressource, vous devez supprimer une contrainte d’emplacement qui est automatiquement ajoutée comme indiqué ci-dessous.

Étape 2. Supprimer la contrainte d’emplacement

À l’occasion d’un déplacement manuel, la commande pcsmove ou la commande crmmigrate ajoute une contrainte d’emplacement pour que la ressource prenne place sur le nouveau nœud cible. Pour afficher la nouvelle contrainte, exécutez la commande suivante après avoir déplacé manuellement la ressource :

  • Exemple RHEL/Ubuntu

    sudo pcs constraint list --full

  • Exemple SLES

    crm config show

Exemple de contrainte créée en raison d’un basculement manuel. Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Remarque

Le nom de la ressource du groupe de disponibilité dans les clusters Pacemaker sur Red Hat Enterprise Linux 8.x et Ubuntu 18.04 peut ressembler à ag_cluster-clone, car la nomenclature des ressources a été modifiée pour utiliser un clone pouvant être promu.

  • Exemple RHEL/Ubuntu

    Dans la commande cli-prefer-ag_cluster-master ci-dessous figure l’ID de la contrainte à supprimer. sudo pcs constraint list --full retourne cet ID.

    sudo pcs resource clear ag_cluster-master

    ou

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    Vous pouvez également déplacer et effacer des contraintes générées automatiquement sur une seule ligne, comme suit. L’exemple suivant utilise la terminologie de clone, conformément à Red Hat Enterprise Linux 8.x.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone

  • Exemple SLES

    Dans la commande suivante cli-prefer-ms-ag_cluster figure l’ID de la contrainte. crm config show retourne cet ID.

    crm configure
delete cli-prefer-ms-ag_cluster 
commit

Notes

Comme l’opération de basculement automatique n’ajoute pas de contrainte d’emplacement, aucun nettoyage n’est nécessaire.

Pour plus d'informations :

Forcer le basculement

Un basculement forcé est strictement destiné à la récupération d’urgence. Dans ce cas, vous ne pouvez pas effectuer le basculement avec les outils de gestion du cluster, car le centre de données principal est en panne. Si vous forcez le basculement vers un réplica secondaire qui n'est pas synchronisé, une perte de données est possible. Ne forcez le basculement uniquement si vous devez restaurer immédiatement le service sur le groupe de disponibilité et que vous êtes prêt à courir le risque de perdre des données.

Si vous ne pouvez pas utiliser les outils de gestion de clusters pour interagir avec le cluster, par exemple, si le cluster ne répond pas en raison d’un événement d’incident dans le centre de données principal, vous devrez peut-être forcer le basculement pour contourner le gestionnaire de cluster externe. Cette procédure n’est pas recommandée pour les opérations normales, car elle risque d’entraîner la perte de données. Utilisez-la lorsque les outils d’administration de clusters ne parviennent pas à exécuter l’action de basculement. Fonctionnellement, cette procédure est similaire à l’exécution d’un basculement manuel forcé sur un groupe de disponibilité dans Windows.

Ce processus de forçage du basculement est spécifique à SQL Server sur Linux.

  1. Vérifiez que la ressource du groupe de disponibilité n’est plus managée par le cluster.

    • Définissez la ressource en mode non géré sur le nœud de cluster cible. Cette commande indique à l’agent de ressources d’arrêter la surveillance et la gestion des ressources. Par exemple :
    sudo pcs resource unmanage <resourceName>
    • Si la tentative de définition du mode de ressource en mode non géré échoue, supprimez la ressource. Par exemple :
    sudo pcs resource delete <resourceName>

    Notes

    Lorsque vous supprimez une ressource, cela supprime également toutes les contraintes associées.

  2. Sur l’instance de SQL Server qui héberge le réplica secondaire, définissez la variable du contexte de la session external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';

  3. Basculez le groupe de disponibilité avec Transact-SQL. Dans l’exemple suivant, remplacez <MyAg> par le nom de votre groupe de disponibilité. Connectez-vous à l’instance de SQL Server qui héberge le réplica secondaire cible et exécutez la commande suivante :

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Après un basculement forcé, mettez le groupe de disponibilité à un état d’intégrité avant de redémarrer l’analyse et la gestion des ressources de cluster ou de recréer la ressource du groupe de disponibilité. Consultez les Tâches essentielles après un basculement forcé.

  5. Redémarrez l’analyse et la gestion des ressources de cluster :

Pour redémarrer l’analyse et la gestion des ressources de cluster, exécutez la commande suivante :

sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>

Si vous avez supprimé la ressource de cluster, recréez-la. Pour recréer la ressource de cluster, suivez les instructions de la rubrique Créer une ressource de groupe de disponibilité.

Important

N’utilisez pas les étapes précédentes pour les explorations de récupération d’urgence, car elles risquent d’entraîner la perte de données. Au lieu de cela, remplacez le réplica asynchrone par synchrone et modifiez les instructions pour le basculement manuel normal.

Déclencheur de surveillance et de basculement au niveau de la base de données

Pour CLUSTER_TYPE=EXTERNAL, la sémantique du déclencheur de basculement est différente de celle de WSFC. Lorsque le groupe de disponibilité est sur une instance de SQL Server dans un WSFC, la transition hors de l’état ONLINE pour la base de données entraîne le signalement d’une erreur par l’intégrité du groupe de disponibilité. En réponse, le gestionnaire de cluster déclenche une action de basculement. Sur Linux, l’instance de SQL Server ne peut pas communiquer avec le cluster. La surveillance de l’intégrité de la base de données est effectuée en interaction indirecte. Si l’utilisateur a opté pour la surveillance et le basculement du basculement au niveau de la base de données (en définissant l’option DB_FAILOVER=ON lors de la création du groupe de disponibilité), le cluster vérifie si l’état de la base de données est ONLINE à chaque fois qu’il exécute une action de surveillance. Le cluster interroge l’état dans sys.databases. Pour tout état différent de ONLINE, il déclenche un basculement automatique (si les conditions de basculement automatique sont remplies). L’heure réelle du basculement dépend de la fréquence de l’action d’analyse, ainsi que de l’état de la base de données en cours de mise à jour dans sys.databases.

Le basculement automatique nécessite au moins un réplica synchrone.

Contenu connexe

Contribuer à la documentation SQL

Saviez-vous que vous pouvez modifier le contenu SQL vous-même ? Dans ce cas, non seulement vous nous aidez à améliorer notre documentation, mais vous êtes également cité en tant que contributeur à la page.

Pour plus d’informations, consultez Guide pratique pour contribuer à la documentation SQL Server