Exploitation d'un groupe de disponibilité Always On SQL Server (Windows et Linux)

Pas une installation : exploitation courante et scénarios de panne d'un Always On Availability Group déjà installé : contrôle de santé, diagnostic du retard et de la croissance du journal, failover planifié, failover forcé (FORCE_FAILOVER_ALLOW_DATA_LOSS) et suites à donner, suspension/reprise du déplacement des données, mode synchrone/asynchrone, ajout de bases (automatic seeding ou sauvegarde/restauration), ajout/retrait de réplicas, read-only routing et modifications du listener. Avec les commandes WSFC sous Windows et Pacemaker (pcs) sous Linux.

Choisissez l'opération dans la carte des scénarios ; vous pouvez aussi ouvrir directement le scénario concerné en saisissant le numéro d'erreur (par ex. 9002, 35264, 41142) dans la recherche du catalogue. Si l'AG n'existe pas encore : AG (Windows) ou AG (Linux).

Topologie: AG de 2 à 9 réplicas (Windows WSFC ou Linux Pacemaker)

Scénarios

• Contrôle de santé de l'AG (requêtes du tableau de bord) — Tout va-t-il bien ? État des réplicas / bases, préparation au failover, cluster et derniers changements de rôle. Ne modifie rien.
• Le secondaire prend du retard / le fichier journal grossit (diagnostic du retard) — La file d'envoi/de redo grossit, les données du secondaire sont anciennes, le journal du primaire est presque plein (log_reuse_wait = AVAILABILITY_REPLICA) ou les commits sont lents (HADR_SYNC_COMMIT).
• Failover planifié (switchover, sans perte de données) — Déplace le primaire vers un secondaire synchrone et SYNCHRONIZED pour une maintenance, un patch ou un test ; quelques secondes d'interruption, aucune perte de données.
• Primaire perdu : failover forcé (FORCE_FAILOVER_ALLOW_DATA_LOSS) — Le primaire (ou tout le site / le quorum du cluster) est perdu et il n'est pas possible d'attendre : un secondaire est promu primaire en acceptant une perte de données ; ensuite les données sont comparées et les autres réplicas sont repris.
• Suspendre / reprendre le déplacement des données (SUSPEND / RESUME) — Arrêter temporairement l'envoi de données vers un secondaire (maintenance réseau, traitement de masse) ou reprendre une base restée suspendue (SUSPENDED).
• Changer le mode synchrone / asynchrone — Passer un réplica de SYNCHRONOUS_COMMIT à ASYNCHRONOUS_COMMIT ou l'inverse (site distant, réseau lent, exercice DR) et régler la protection des commits (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT).
• Ajouter une base à l'AG (automatic seeding ou sauvegarde/restauration) — Intégrer une base nouvelle ou existante à l'AG : automatic seeding pour les bases petites/moyennes, à partir d'une sauvegarde pour les grosses bases ou sur un réseau lent.
• Ajouter un réplica (nœud) — Ajouter un nouveau secondaire à l'AG : le nœud rejoint le cluster, l'endpoint est préparé, ADD REPLICA + JOIN, puis les bases arrivent par seeding.
• Retirer un réplica (nœud) — Retirer de l'AG et du cluster un secondaire qui sera définitivement arrêté ou reconstruit.
• Routage en lecture seule (read-only routing) — Router les connexions ApplicationIntent=ReadOnly via le listener vers les secondaires accessibles en lecture (décharger le primaire du reporting).
• Créer ou modifier le listener (IP, port) — Créer le listener s'il n'existe pas, changer son port ou (sous Windows) ajouter une IP pour un second sous-réseau.

Avant de commencer

• sqlcmd (/opt/mssql-tools18/bin/sqlcmd) et … sysadmin sur chaque nœud ; droits root (pcs). Mot de passe : read -rsp 'Mot de passe : ' SQLCMDPASSWORD; export SQLCMDPASSWORD et sudo --preserve-env=SQLCMDPASSWORD bash <script>.sh.
• PowerShell est ouvert en administrateur avec un compte de domaine sysadmin dans SQL Server et administrateur du WSFC ; sqlcmd et le module FailoverClusters sont disponibles.
• La ligne 1 de la liste des réplicas du formulaire est le primaire actuel (vérifiez-le avec la première requête du contrôle de santé) ; les étapes sont placées sur le bon nœud selon cet ordre.
• La fenêtre de changement est validée et l'équipe applicative est prévenue… : le listener est coupé quelques secondes et les transactions ouvertes sont annulées…… : un changement de port/d'IP affecte les chaînes de connexion….
• La décision de failover forcé a été prise par une personne habilitée et la perte de données est acceptée : le primaire est injoignable et ne reviendra pas dans un délai raisonnable. Si le primaire peut revenir, attendre ou faire un failover planifié est toujours préférable.

Phases du guide

• Contrôle de santé de l'AG — Tableau de bord de l'AG : réplicas, bases, préparation au failover · État du cluster (WSFC) · État du cluster (Pacemaker) · Derniers changements de rôle (AlwaysOn_health)
• Diagnostic du retard et de la croissance du journal — Diagnostic : files, débits et temps de rattrapage estimé (primaire) · Diagnostic : attentes de commit (primaire) · Diagnostic : le redo est-il bloqué ? (sur les secondaires) · Options de résolution et contrôle du journal
• Failover planifié — Diagnostic : la cible est-elle prête pour le failover ? (…) · Filet de sécurité : transactions longues ou jobs en cours ? (primaire) · Failover : faire de … le primaire (T-SQL) · Failover : faire de … le primaire (pcs) · Vérifier : nouveau primaire et listener
• Failover forcé (perte de données possible) — Diagnostic : état de la cible et perte de données possible (…) · Démarrer le quorum WSFC de force (…) · Retirer la ressource AG de la gestion Pacemaker (…) · Failover forcé : faire de … le primaire · Vérifier : nouveau primaire ouvert, les autres en SUSPENDED · Prendre un snapshot sur l'ancien primaire pour récupérer les données perdues (…, à son retour) …
• Suspendre / reprendre le déplacement des données — Diagnostic : bases suspendues et motif · …Suspendre le déplacement des données (SUSPEND)…Reprendre le déplacement des données (RESUME)… · Vérifier et surveiller
• Modification du mode de disponibilité — Diagnostic : modes actuels et protection des commits · … → … · Régler la protection des commits (Windows) · Régler la protection des commits (Pacemaker) · Vérifier
• Ajouter une base à l'AG — Diagnostic : la base peut-elle entrer dans l'AG ? (primaire) · Préparer : récupération FULL et sauvegarde (primaire) · Passer les réplicas en seeding manuel (primaire) · Ajouter la base à l'AG (primaire) · Suivre le seeding (primaire) · Préparer à partir de la sauvegarde sur le secondaire (NORECOVERY) : … …
• Ajouter un réplica — Ajouter le nouveau nœud au WSFC (primaire) · Activer Always On (nouveau nœud) · Créer l'endpoint et accorder les droits (nouveau nœud) · Préparer le nouveau nœud : agent HA, Always On, logiciels de cluster · Copier le certificat de l'endpoint sur le nouveau nœud (primaire) · Certificat, endpoint et login Pacemaker (nouveau nœud) …
• Retirer un réplica — Diagnostic : réplica à retirer et configuration restante · Retirer le nœud du cluster Pacemaker (primaire) · Retirer le réplica de l'AG (primaire) · Retirer le nœud du WSFC (facultatif) · Nettoyer les bases RESTORING du nœud retiré (…)
• Read-only routing — Diagnostic : accès en lecture et routage actuel · Définir les URL et les listes de routage (primaire) · Vérifier : liste de routage · Test : où va une connexion ReadOnly ? · Test : où va une connexion ReadOnly ?
• Listener — Diagnostic : listeners actuels · Créer la ressource d'IP virtuelle et les contraintes (Pacemaker) · …Créer le listener…Changer le port du listener…Ajouter une IP au listener… (primaire) · Paramètres du firewall et du DNS · Paramètres du firewall · Vérifier : connexion via le listener