Réplication en flux PostgreSQL (primary + standby)

Ajoute un ou plusieurs hot standby à un primary existant avec pg_basebackup (utilisateur de réplication, pg_hba, replication slot, mode asynchrone ou synchrone ANY/FIRST, suivi du retard) et produit les runbooks d'exploitation de ce cluster sans Patroni : switchover planifié, failover manuel (pg_promote), réintégration de l'ancien primary avec pg_rewind, reconstruction d'un standby, standby en cascade et standby différé, nettoyage des slots, modification du paramétrage synchrone. Le failover n'est pas automatique, c'est le DBA qui le déclenche ; pour un failover automatique, utilisez pg-patroni ; pour un flux de données au niveau table ou entre versions, utilisez pg-logical-repl.

Topologie: 1 primary + 1..N standby

Scénarios

• Installation : ajouter des standby au primary — Un ou plusieurs hot standby sont ajoutés à un primary existant avec pg_basebackup (slot, synchrone/asynchrone, supervision). Le primary reste ouvert ; la copie initiale impose une charge disque et réseau au primary.
• Switchover planifié (inversion des rôles, sans perte de données) — Maintenance planifiée : le primary est arrêté proprement, le premier standby est promu, l'ancien primary revient en standby. Aucune perte de données ; l'interruption des écritures dure généralement moins d'une minute.
• Failover manuel (primary tombé, promouvoir le standby) — Le primary est tombé ou injoignable : l'ancien primary est isolé (fencing), le standby le plus à jour est promu manuellement. En mode asynchrone, les dernières transactions peuvent être perdues.
• Réintégrer l'ancien primary comme standby avec pg_rewind — Après un failover, l'ancien primary est resynchronisé sur le nouveau primary avec pg_rewind et réintégré comme standby ; c'est beaucoup plus rapide qu'une copie complète.
• Ajouter un nouveau standby alimenté par un standby (cascade) — Le nouveau standby reçoit le WAL du premier standby au lieu du primary : dans un data center distant ou une architecture à nombreux standby, la charge réseau et d'envoi de WAL du primary diminue. Le primary n'est pas affecté.
• Mettre en place un standby différé (delayed) — Standby qui applique le WAL avec plusieurs heures de retard (recovery_min_apply_delay) : pour récupérer des données supprimées par erreur sans restaurer une sauvegarde. Ce n'est pas un candidat au failover.
• Reconstruire un standby à partir de zéro — Le standby a pris trop de retard, son WAL a été supprimé ou il est corrompu : le répertoire de données est mis de côté et recopié depuis le primary. Le primary n'est pas affecté.
• pg_wal grossit, le disque se remplit (nettoyage des slots inutilisés) — La cause de l'accumulation de WAL est identifiée (slot inactif, échec d'archivage, wal_keep_size) ; le replication slot inutilisé est supprimé et l'espace WAL est récupéré. Le primary reste ouvert.
• Ajouter / retirer un standby synchrone (synchronous_standby_names) — Réécrit la liste synchrone selon le mode du formulaire (ANY/FIRST, k) ou repasse en asynchrone ; appliqué par un reload, sans redémarrage. Un mauvais réglage peut laisser des commits en attente ; il est donc vérifié au préalable.

Avant de commencer

• Le primary … est installé avec le guide pg-install et en service (PostgreSQL …, PGDATA …, port …).
• Sur les serveurs standby, seule la phase de préparation du système d'exploitation du guide pg-install (hostname, chrony, sysctl, THP) a été réalisée. Le cluster n'a pas été créé ; le logiciel est installé dans ce guide.
• Même famille de système d'exploitation, même architecture (x86_64/aarch64) et même version majeure de PostgreSQL (…) sur tous les serveurs. Le standby est une copie physique exacte du primary.
• Sur le standby, l'espace libre pour … dépasse d'au moins 20 % la taille des données du primary.
• Les serveurs se joignent sur le port … ; les hostnames sont résolus et les horloges synchronisées par NTP.
• Le port … est ouvert entre les serveurs dans le firewall (si pg-install n'a ouvert que le réseau applicatif, ajoutez aussi les IP de réplication).
• Sous Debian/Ubuntu, les fichiers de configuration sont hors du répertoire de données (/etc/postgresql), donc pg_basebackup ne les copie pas ; vous disposez d'un accès scp du standby vers le primary en root (ou avec un utilisateur sudo), ou vous déplacerez les fichiers manuellement.
• Le répertoire de données de l'ancien primary est intact et le serveur peut démarrer (en cas de panne disque, il faut une reconstruction avec pg_basebackup, pas pg_rewind).
• …Un créneau adapté a été choisi pour la copie initiale (pg_basebackup), qui charge le primary.…La fenêtre de maintenance est ouverte ; les équipes applicatives sont informées de la courte interruption des écritures.…Il est confirmé que le primary est réellement injoignable ; il est garanti qu'il ne reviendra pas accepter des écritures comme second primary (fencing).…Le nouveau primary est sain et accepte les écritures.…Le nouveau serveur (…) est prêt : la préparation du système d'exploitation est faite, … est vide et dispose d'assez d'espace ; la copie initiale chargera la source (…).…Pendant la reconstruction de …, sa charge de lecture peut être reportée sur les autres serveurs ; la copie chargera le primary.…Le remplissage du disque est surveillé ; avant de supprimer le slot, le responsable du standby qui l'utilise a été consulté.…La modification synchrone a lieu dans une fenêtre de maintenance ; les équipes applicatives sont informées car la latence des commits va changer.…

Phases du guide

• Préparation (tous les serveurs) — Ajouter les noms des serveurs dans /etc/hosts · Ajouter le dépôt PGDG · Ajouter le dépôt PGDG · Installer le logiciel serveur PostgreSQL · Préparer le répertoire de données · Créer la configuration du cluster et vider le répertoire de données
• Préparation de la réplication sur le primary — Vérifier le prérequis de pg_rewind · Écrire le fichier de paramètres de réplication · Charger les paramètres · Créer l'utilisateur de réplication · Définir le mot de passe de l'utilisateur de réplication · Ajouter les règles de réplication dans pg_hba.conf …
• Installation du standby (pg_basebackup) — Tester la connexion de réplication vers le primary · Prendre une copie du primary : … · Copier les fichiers de configuration depuis le primary · Démarrer le standby
• Vérification — Vérifier l'état de la réplication sur le primary · Vérifier le WAL receiver sur le standby · Écrire des données de test sur le primary · Lire les données de test sur le standby · Supprimer la table de test
• Activer la réplication synchrone — Écrire le fichier de paramètres synchrones · Charger le paramètre sur tous les serveurs · Vérifier l'état synchrone
• Supervision et post-installation — Requête de suivi du retard (primary) · Requête de suivi du retard (standby) · Supervision du remplissage des slots · Chaîne de connexion applicative · Adapter la sauvegarde au standby
• Contrôles avant switchover — Vérifier l'état des standby · Vérifier que le nouveau primary est prêt · Vérifier .pgpass et pg_hba sur l'ancien primary
• Switchover — Arrêter proprement l'ancien primary · Vérifier que le nouveau primary a reçu le dernier WAL · Promouvoir … · Créer les slots sur le nouveau primary · Configurer l'ancien primary en standby · Démarrer l'ancien primary en standby …
• Failover manuel — Arrêter et désactiver l'ancien primary (fencing) · Identifier le standby le plus à jour · Promouvoir … · Supprimer temporairement l'attente synchrone · Créer les slots sur le nouveau primary · Faire pointer les autres standby vers le nouveau primary : … …
• Réintégrer l'ancien primary avec pg_rewind — Vérifier le slot et la règle de connexion sur le nouveau primary · Vérifier que l'ancien primary est arrêté · Exécution à blanc de pg_rewind · Exécuter pg_rewind · Compléter les paramètres du standby · Démarrer l'ancien primary en standby …
• Gonflement de pg_wal et nettoyage des slots — Pourquoi pg_wal grossit-il ? · Trouver le propriétaire du slot · Supprimer le slot inutilisé : … · Suppression d'un slot : remplir le formulaire · Vérifier que l'espace WAL a été récupéré · Éviter que cela se reproduise : limite haute et supervision
• Modification des standby synchrones — État synchrone actuel · Contrôle de sécurité : suffisamment de standby sont-ils connectés ? · Écrire le fichier de paramètres synchrones · Supprimer le paramètre synchrone (repasser en asynchrone) · Charger le paramètre sur tous les serveurs · Vérifier le nouvel état