Comprendre et exécuter les scénarios de basculement (Failover) et de permutation (Switchover) PostgreSQL

Dans l'architecture de base de données moderne, assurer un fonctionnement continu grâce à la haute disponibilité (HA) est primordial. PostgreSQL, une puissante base de données relationnelle open-source, s'appuie sur la réplication en continu (streaming replication) pour maintenir la cohérence des données sur plusieurs nœuds. Cependant, lorsque le serveur primaire rencontre un problème ou nécessite une maintenance, les administrateurs de bases de données doivent exécuter des procédures précises pour rétablir le service. Cet article différencie clairement deux opérations critiques de HA : le Basculement (Failover) et la Permutation (Switchover), et détaille les étapes et considérations pour promouvoir en toute sécurité une réplique secondaire au rôle de nouveau primaire.

Comprendre la distinction entre ces événements est vital. Une permutation (switchover) est une transition planifiée et contrôlée, tandis qu'un basculement (failover) est une réponse d'urgence à une panne inattendue. La réussite de l'un ou l'autre scénario dépend fortement d'une configuration appropriée, d'une surveillance robuste et de la familiarité avec les outils utilisés pour gérer la réplication.

Fondamentaux de la réplication : La base de la HA

La Haute Disponibilité PostgreSQL repose sur la réplication en continu, où un serveur agit comme Primaire (ou Maître) et un ou plusieurs serveurs agissent comme Secondaires (ou Répliques). Le Primaire diffuse les enregistrements du journal des écritures anticipées (WAL) vers les Secondaires pour les maintenir synchronisés.

Pour gérer efficacement ces rôles, des paramètres de configuration spécifiques sont nécessaires sur les nœuds primaires et secondaires :

Paramètres de configuration critiques

Ces paramètres régissent le fonctionnement de la réplication et la manière dont les nœuds s'identifient mutuellement :

• wal_level : Doit être défini sur replica ou supérieur (idéalement logical si vous utilisez des outils nécessitant un décodage logique) sur le Primaire.
• max_wal_senders : Définit le nombre maximal de connexions simultanées depuis les secondaires. Doit être augmenté par rapport à la valeur par défaut (généralement 10) pour accueillir tous les secondaires.
• hot_standby : Doit être défini sur on dans le postgresql.conf du serveur secondaire pour autoriser les requêtes en lecture seule pendant la réplication.
• synchronous_commit : Contrôle l'acquittement des transactions. Pour une perte de données nulle lors des permutations (switchovers), ceci est souvent réglé sur on (ou remote_write pour une tolérance à une latence mineure).
• primary_conninfo : Défini sur le secondaire, il détaille les informations de connexion (hôte, port, utilisateur, mot de passe) pour se connecter au Primaire actuel.

Meilleure pratique : Pour une HA robuste, utilisez des couches de mise en pool de connexions (comme PgBouncer ou des proxys HA dédiés tels que Patroni ou Repmgr) qui abstraient les adresses physiques des serveurs, rendant les basculements et les permutations transparents pour les applications.

Permutation (Switchover) : La transition planifiée

A Permutation (Switchover) est un processus contrôlé et gracieux où le nœud Primaire actif est intentionnellement mis hors service et un Secondaire désigné est promu pour prendre sa place. Cette procédure est généralement utilisée pour la maintenance planifiée, les mises à niveau de version ou les remplacements de matériel.

Étapes pour une permutation contrôlée

L'objectif d'une permutation est d'assurer une perte de données nulle en attendant que toutes les transactions en cours soient répliquées avant la promotion.

1. Arrêter les écritures sur le Primaire actuel : La première étape consiste à empêcher l'engagement de nouvelles transactions sur le Primaire actuel. Ceci est souvent réalisé en définissant default_transaction_read_only = on ou en arrêtant temporairement les connexions client.
2. Attendre la synchronisation de la réplication : Assurez-vous que le Secondaire désigné a reçu et appliqué tous les enregistrements WAL restants du Primaire. Vous pouvez vérifier le décalage de réplication en utilisant pg_stat_replication sur le Primaire ou en examinant l'état de récupération du secondaire.
3. Initier la promotion du secondaire : Exécutez la commande pour promouvoir le serveur Secondaire choisi au rôle de Primaire. La commande spécifique dépend de l'outil de gestion utilisé (par exemple, pg_ctl promote ou une commande de gestionnaire de cluster).
4. Reconfigurer l'ancien Primaire : Une fois que le Secondaire est promu avec succès, l'ancien Primaire doit être reconfiguré pour suivre le nouveau Primaire en tant que Secondaire. Cela implique de mettre à jour son primary_conninfo.
5. Rediriger les applications : Mettez à jour l'équilibreur de charge ou le pooler de connexion pour diriger le trafic vers le nouveau serveur Primaire.

Basculement (Failover) : La réponse d'urgence

Le Basculement (Failover) est une procédure immédiate et réactive déclenchée lorsque le serveur Primaire actuel tombe en panne de manière inattendue (par exemple, crash matériel, partition réseau, erreur logicielle) et ne peut pas être remis en ligne rapidement.

Le basculement comporte intrinsèquement un risque plus élevé de perte de données car rien ne garantit que les dernières transactions validées aient eu le temps de se propager aux Secondaires avant que la panne ne se produise.

Exécuter un basculement d'urgence

Les procédures de basculement sont conçues pour la rapidité et la récupération, utilisant souvent des outils spécialisés pour automatiser la promotion.

1. Déterminer l'état de l'ancien Primaire : Vérifiez que l'ancien Primaire est véritablement indisponible et ne rencontre pas seulement un problème réseau transitoire (cela évite les scénarios dangereux de 'split-brain').
2. Sélectionner le meilleur Secondaire : Choisissez le Secondaire présentant le décalage de réplication le plus faible (celui qui est le plus avancé dans le flux WAL).
3. Promouvoir le Secondaire : Promouvez immédiatement le Secondaire sélectionné en utilisant la commande de promotion (pg_ctl promote).
4. Gérer la perte de données (si nécessaire) : Si le cluster utilise une réplication asynchrone, les données perdues sur le Primaire défaillant pourraient devoir être réconciliées manuellement ou simplement acceptées, en fonction de la tolérance de l'application.
5. Reconfigurer l'ancien Primaire : Une fois que le Primaire d'origine est récupéré, il doit être nettoyé, réinitialisé (nécessitant souvent une sauvegarde de base à partir du nouveau Primaire) et configuré pour suivre le nouveau Primaire.

Outils pour une promotion sécurisée : Repmgr contre Patroni

Bien que la promotion manuelle à l'aide de pg_ctl soit possible, les environnements HA robustes s'appuient sur des outils dédiés pour gérer la chorégraphie complexe requise pour le basculement et la permutation, gérant automatiquement les changements de configuration et l'état du cluster.

Repmgr (Replication Manager)

repmgr est un outil puissant et léger qui surveille la réplication et facilite le basculement manuel ou automatique. Les commandes clés incluent :

• Permutation (Switchover) : repmgr standby promote suivi de repmgr switchover --sibling-nodes-wait (pour assurer la synchronisation).
• Basculement (Failover) : repmgr failover

Patroni

Patroni utilise des magasins de consensus distribués (tels qu'etcd, ZooKeeper ou Consul) pour gérer l'état du cluster, élisant automatiquement un nouveau Primaire lors de la détection d'une panne. Patroni automatise en grande partie les permutations et les basculements via des appels API ou des opérateurs Kubernetes, réduisant considérablement l'intervention manuelle.

Exemple utilisant Patroni (Commande de promotion conceptuelle) :

# Déclencher une permutation via l'API REST de Patroni
curl -X POST http://patroni-api-endpoint/switchover -H "Content-Type: application/json" -d '{"target": "nom_du_nœud_secondaire"}'

Avertissement sur le Split-Brain : Le plus grand danger lors d'un basculement automatisé est le scénario de « split-brain », où deux nœuds croient à tort être le Primaire en raison d'une partition réseau. Des outils comme Patroni atténuent cela en utilisant des mécanismes de quorum, tandis que les configurations manuelles nécessitent des mécanismes de blocage (fencing) stricts (comme des contrôles d'alimentation) pour garantir qu'un seul Primaire existe.

Résumé des différences

L'exécution des basculements et des permutations PostgreSQL exige une compréhension approfondie de l'état du cluster et des outils qui le gèrent. Alors que les permutations visent une perte de données nulle grâce à la coordination, les basculements privilégient une restauration rapide du service, souvent au détriment des transactions les plus récentes. Une configuration appropriée des paramètres de réplication et l'utilisation d'outils de gestion de cluster robustes sont les pierres angulaires d'une Haute Disponibilité PostgreSQL fiable.