Comment valider la réplication primaire-secondaire PostgreSQL 18 ? Liste de contrôle du basculement

La politique officielle de PostgreSQL prévoit cinq ans de prise en charge pour chaque version majeure, ce qui rend nécessaire une gestion suivie des versions et des opérations de maintenance (politique de versions PostgreSQL). Pour valider une architecture PostgreSQL 18 primaire-secondaire, ne vous fiez donc ni au seul retard de réplication ni à la simple connexion au serveur secondaire : vérifiez la réception et la relecture du WAL, la promotion planifiée, le retour des écritures dans l’application, l’état des slots logiques et les limites du retour arrière. La réplication asynchrone peut laisser des transactions non transmises au secondaire ; elle ne remplace jamais une sauvegarde hors site.

Adapté aux équipes qui préparent la mise en production d’un primaire PostgreSQL et d’un serveur de secours, et qui doivent établir des critères d’acceptation vérifiables.
Moins adapté à celles qui cherchent un tutoriel général de déploiement ou une garantie de basculement automatique : la liste ci-dessous porte sur la recette et les responsabilités de l’équipe, pas sur un service de haute disponibilité géré.

Étape 1 — valider la réplication PostgreSQL 18 côté émission et réception

Un indicateur de retard faible n’est pas, à lui seul, un feu vert. Il faut établir que le primaire envoie bien le WAL, que le secondaire le reçoit et qu’il le rejoue. PostgreSQL expose des vues distinctes pour ces observations : sur le primaire, pg_stat_replication décrit les processus d’envoi associés aux serveurs secondaires ; sur le secondaire, pg_stat_wal_receiver donne des informations sur le processus de réception. La documentation officielle sur le suivi du serveur de secours décrit ces vues et les positions de WAL à comparer.

Commencez par relever les résultats des requêtes sur chacun des nœuds, avec l’heure et le nom du serveur consignés dans le compte rendu.

Sur le primaire :

SELECT application_name, state, sync_state,
       sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;

Sur le secondaire :

SELECT status, receive_start_lsn, written_lsn, flushed_lsn,
       latest_end_lsn, latest_end_time
FROM pg_stat_wal_receiver;

Les noms de colonnes disponibles et leur signification sont à vérifier dans la documentation correspondant à la version effectivement installée. Une ligne présente sur le primaire ne démontre pas, à elle seule, que le secondaire a rejoué les dernières données ; de même, un processus récepteur actif ne prouve pas que les écritures ont été appliquées. Relevez également les positions de réception et de relecture sur le secondaire, par exemple avec les fonctions d’administration décrites dans la documentation PostgreSQL sur les fonctions de contrôle.

• [ ] Le secondaire attendu apparaît côté primaire, avec le bon nom d’application et le bon état.
• [ ] Le processus récepteur est actif sur le secondaire et son activité est cohérente avec le trafic observé.
• [ ] Les positions de réception, d’écriture et de relecture évoluent pendant une écriture contrôlée.
• [ ] L’équipe distingue les données reçues des données déjà rejouées.
• [ ] Les résultats, l’heure de collecte et le nom du nœud figurent dans la preuve de recette.

La réplication PostgreSQL peut-elle être considérée comme prête parce que son retard semble normal ?

Non. Le retard est un signal à interpréter dans un contexte : charge, fréquence des écritures, réseau et état de relecture. Même un retard momentanément faible ne prouve ni que le serveur secondaire pourra être promu, ni que l’application se reconnectera correctement. La réplication asynchrone laisse en outre une fenêtre pendant laquelle une transaction validée sur le primaire peut ne pas avoir atteint le secondaire. Si le primaire est perdu à ce moment-là, cette transaction peut manquer après la promotion.

L’équipe doit donc définir ce qu’elle accepte en matière de perte potentielle, puis vérifier le comportement sous charge représentative, sans transformer un instantané de mesure en promesse de protection. Les paramètres de réplication, notamment ceux qui influent sur l’envoi, l’attente et la conservation du WAL, sont décrits dans la référence PostgreSQL des paramètres de réplication.

Étape 2 — contrôler les slots et le risque de rétention du WAL

Les slots de réplication répondent à un besoin de continuité, mais ils peuvent aussi retenir du WAL tant qu’un consommateur ne progresse pas. Un slot inactif ou bloqué mérite donc une vérification avant la recette : selon la configuration et l’état du consommateur, la rétention peut accroître l’espace occupé par les fichiers WAL et finir par affecter le fonctionnement du primaire. La vue pg_replication_slots fournit notamment l’état des slots et des informations de rétention ; consultez la description officielle de ses colonnes pour interpréter les champs de la version utilisée.

Examinez chaque slot et attribuez-lui un propriétaire opérationnel : réplication physique, abonnement logique, outil de capture des changements ou autre consommateur. Pour chacun, consignez la raison de son existence, le nœud ou service qui l’utilise, sa progression et la procédure prévue si le consommateur est arrêté. Un slot ancien dont personne ne revendique l’usage n’est pas un simple détail de configuration : il peut masquer une rétention de WAL évitable.

• [ ] Chaque slot possède un consommateur identifié et un responsable joignable.
• [ ] Les slots inactifs sont expliqués ; leur suppression n’est pas faite à l’aveugle.
• [ ] Le suivi de l’espace disque et des WAL retenus est opérationnel.
• [ ] La procédure de reprise d’un consommateur arrêté a été définie et testée séparément.
• [ ] Les slots physiques et logiques ne sont pas traités comme s’ils avaient le même rôle.

Étape 3 — comparer les signaux qui autorisent ou interdisent la promotion

Le tableau ci-dessous aide à séparer les constats techniques de la décision d’exploitation. Il ne fixe pas de seuil universel de retard ni de délai de reprise : ces objectifs doivent être arrêtés par l’équipe en fonction des transactions acceptables à perdre et du comportement réel de l’application.

La différence décisive n’est donc pas entre « retard bas » et « retard élevé » pris isolément, mais entre une observation partielle et une séquence complète, documentée et répétable. Une recette acceptable doit également désigner qui peut interrompre l’opération lorsque les résultats s’écartent de ce qui était prévu.

Étape 4 — réaliser une promotion planifiée sans la confondre avec l’automatisation

La promotion d’un serveur secondaire doit être testée dans un environnement et selon des conditions maîtrisés, avec les personnes responsables prévenues et une procédure de retour définie. Les mécanismes et précautions de promotion sont détaillés dans la documentation PostgreSQL sur le basculement d’un serveur de secours. La fonction pg_promote() fait partie des fonctions de contrôle documentées par PostgreSQL ; son invocation dans un exercice ne démontre toutefois pas qu’un dispositif automatique de détection et de décision existe.

Avant l’exercice, relevez le rôle de chaque nœud, l’état de la réplication, les écritures de test prévues et les personnes autorisées à décider. Pendant l’opération, consignez les horodatages, les messages observés et les réponses des commandes de contrôle. Après la promotion, vérifiez le rôle du nouveau primaire et une écriture de test réversible. Si l’un des résultats n’est pas conforme, arrêtez l’exercice au lieu d’enchaîner des changements de rôle improvisés.

• [ ] Les conditions de déclenchement de l’exercice et son responsable sont écrits.
• [ ] Les positions WAL et les rôles avant promotion sont conservés.
• [ ] La promotion est déclenchée selon la procédure retenue, sans supposer qu’elle est automatique.
• [ ] Le nouveau primaire accepte une écriture de test et la relit correctement.
• [ ] L’ancien primaire est isolé ou maintenu hors service tant que son rôle n’est pas clarifié.
• [ ] Le retour dans la topologie est planifié, et non improvisé depuis un ancien primaire potentiellement divergent.

Après une divergence, l’ancien primaire ne doit pas simplement être remis en ligne en espérant que les deux serveurs se réconcilient. L’équipe doit prévenir le partage du rôle primaire et appliquer la procédure de réintégration prévue, par exemple une reconstruction ou un mécanisme de resynchronisation si ses conditions sont réunies. Tant que cette étape n’est pas validée, l’ancien nœud ne doit pas recevoir d’écritures concurrentes.

Étape 5 — vérifier que les applications reprennent réellement leurs écritures

Un port ouvert ne signifie pas que le service métier est revenu. Après un changement de rôle, les connexions existantes peuvent rester dirigées vers l’ancien primaire, les pools peuvent conserver des connexions périmées et les clients peuvent ignorer si une transaction a été validée avant la rupture. L’équipe applicative doit donc participer à l’exercice, plutôt que de laisser la recette au seul DBA.

Que faut-il contrôler après un basculement PostgreSQL ?

Le test doit suivre le parcours d’une opération métier, depuis l’ouverture ou le renouvellement de la connexion jusqu’à la confirmation de la transaction par le client. Utilisez des données réversibles et reconnaissables ; ne vous contentez pas d’un test de connexion ou d’une requête de lecture.

• [ ] Le mécanisme de découverte du nouveau primaire oriente les nouvelles connexions vers le bon nœud.
• [ ] Les pools ferment ou renouvellent les connexions invalides selon le comportement attendu.
• [ ] L’application distingue un échec certain d’une réponse perdue après une validation potentiellement réussie.
• [ ] Les opérations rejouées ne créent pas de doublons ; les traitements sensibles disposent d’un mécanisme d’idempotence ou de vérification.
• [ ] Une écriture contrôlée, sa lecture et sa confirmation par l’application sont enregistrées.
• [ ] Les tâches en arrière-plan, traitements différés et consommateurs de messages sont inclus dans le contrôle.

Le compte rendu doit préciser ce que les utilisateurs et les processus automatisés voient pendant la transition : erreurs explicites, reprises, opérations à vérifier ou files d’attente bloquées. Sans cette description, une connexion rétablie côté base ne suffit pas à caractériser une reprise applicative.

Étape 6 — vérifier séparément les consommateurs et slots logiques

La réplication physique et la réplication logique ne remplissent pas la même fonction. Les équipes qui n’utilisent ni publication, ni abonnement, ni consommateur de changements peuvent inscrire ce contrôle comme « non applicable » avec une justification ; elles ne doivent pas le confondre avec l’état du secondaire physique.

Si des consommateurs logiques existent, dressez-en la liste et vérifiez leur comportement après promotion : abonnements, positions de reprise, slots utilisés et continuité des flux. PostgreSQL documente séparément la réplication logique et ses exigences de basculement avec réplication logique. La présence d’un slot sur l’ancien primaire ne prouve pas que le slot nécessaire est disponible et utilisable sur le nouveau.

Les slots logiques restent-ils disponibles après le changement de primaire ?

La réponse dépend de la configuration du dispositif de réplication et du fait que la synchronisation des slots de basculement ait été préparée conformément aux exigences officielles. La continuité ne doit donc pas être présumée à partir du seul succès de la promotion physique. Faites vérifier par le responsable des flux logiques les slots effectivement présents, leur état, les abonnements concernés et la reprise observable du consommateur. En l’absence de configuration adaptée, consignez une interruption possible et une procédure de réinitialisation ou de resynchronisation ; ne déclarez pas les flux rétablis sans preuve côté consommateur.

• [ ] Tous les consommateurs de données modifiées sont inventoriés et associés à un responsable.
• [ ] Les slots requis après promotion ont été contrôlés sur le nœud appelé à devenir primaire.
• [ ] Chaque consommateur a confirmé la reprise et l’absence de lacune non traitée.
• [ ] Les dépendances logiques non configurées pour le basculement sont clairement signalées comme telles.

Étape 7 — signer la recette avec une sauvegarde et une limite de retour explicites

Le responsable d’astreinte ou de mise en production rassemble les observations DBA, infrastructure, applications et consommateurs en une décision unique. Il doit pouvoir répondre à trois questions distinctes : les données sont-elles reçues et rejouées comme attendu, le service applicatif reprend-il les écritures, et l’équipe sait-elle quoi faire si l’ancien primaire ne peut pas être réintégré sans reconstruction ?

La sauvegarde doit faire l’objet d’une preuve indépendante : présence d’une copie hors des nœuds concernés, procédure de restauration connue et exercice de restauration effectué dans un contexte approprié. La documentation officielle sur les sauvegardes et restaurations PostgreSQL décrit les approches possibles ; la présence d’un fichier de sauvegarde ne prouve pas sa restaurabilité.

La même prudence s’applique au stockage. Si les serveurs ne disposent pas d’un RAID matériel, il appartient à l’équipe de décider si elle met en œuvre un miroir logiciel, une réplication ou une autre stratégie de protection, puis d’en tester les limites. Ni un miroir local ni un serveur secondaire ne remplace la copie hors site. Pour comparer les besoins de mémoire, de stockage NVMe et de système aux offres de serveurs dédiés, consultez le catalogue SFP Cloud, puis vérifiez les caractéristiques et les cycles de facturation sur la page des offres SFP Cloud ; ne supposez pas qu’une location de serveur unique inclut une topologie primaire-secondaire, un réseau privé ou un basculement géré.

Avant d’autoriser la production, le procès-verbal doit contenir au minimum :

• [ ] Les résultats des contrôles WAL sur le primaire et le secondaire, avec leur contexte.
• [ ] La preuve d’une promotion planifiée et d’une écriture applicative après promotion.
• [ ] L’état des slots et des consommateurs logiques, ou la justification de leur non-applicabilité.
• [ ] Le responsable de la décision, les conditions d’arrêt et la procédure concernant l’ancien primaire.
• [ ] La preuve qu’une sauvegarde hors site peut être restaurée, distincte de la réplication.
• [ ] Les risques acceptés, notamment la possibilité de transactions absentes avec une réplication asynchrone.

Une équipe qui ne peut pas documenter la réception et la relecture, le test applicatif ou la réintégration de l’ancien primaire devrait reporter la mise en production plutôt que de transformer une mesure de retard en critère de validation. Pour un projet exécuté sur serveur dédié, le choix du matériel doit être arrêté à partir des besoins et de la fiche de l’offre ; la conception de la topologie, les contrôles de réplication et les sauvegardes restent à concevoir et à vérifier par l’équipe. Le mot-clé opérationnel est bien la validation de la réplication PostgreSQL 18 : elle porte sur toute la chaîne, et non sur un indicateur isolé.