Migration et renforcement d'un cluster de production PostgreSQL + Patroni vers Ubuntu avec restauration de réplication et configuration de sauvegarde

Situation initiale
J'utilise actuellement PostgreSQL 14 en production pour SaaS (multi-tenant, jusqu'à 1200 rps en pic, ~900 Go de données). Cluster 3 nœuds (2x primaire/veille + témoin) sur Ubuntu 20.04 dans Hetzner Cloud, géré par Patroni+etcd. Après une série d'incidents, nous avons remarqué : des basculements périodiques avec split-brain, des répliques en retard jusqu'à 20 à 40 minutes, des sauvegardes barman parfois interrompues et des mises à jour du système d'exploitation et de Postgres retardées. Le plan est de migrer vers Ubuntu 22.04 et PostgreSQL 16 avec un temps d'arrêt minimal, tout en mettant de l'ordre dans l'observabilité et un fonctionnement sûr.

Environnement technique
- 3 VM (Hetzner Cloud), NVMe, réseau 1 Gbps
-Ubuntu 20.04 -> 22.04
- PostgreSQL 14 -> 16
- Patroni, etcd, HAProxy
- barman pour PITR
- Prometheus + node_exporter est déjà là, postgres_exporter est configuré à certains endroits
- Accès : SSH via clé, limite de temps d'inactivité - pas plus de 10 minutes au basculement final

Tâche et résultat attendu
1) Analysez la configuration HA actuelle (Patroni/etcd/HAProxy/Postgres) et identifiez les causes du split-brain et des retards de réplication. Enregistrez les problèmes trouvés et les modifications proposées dans un court rapport.
2) Préparez un plan et effectuez une migration vers PostgreSQL 16 et Ubuntu 22.04, en préservant le cluster Patroni et la commutation transparente pour les applications via HAProxy.
3) Configurez les sauvegardes et la vérification de la récupération afin que le PITR et la validation régulière des sauvegardes soient garantis.
4) Renforcer la sécurité et la fiabilité opérationnelle : limitation de l'accès au réseau, paramètres corrects du noyau/limites, rotation des journaux, mesures de renforcement de base sans fanatisme.
5) Amenez la surveillance à un état où vous pouvez voir de manière mesurable le retard de réplication, l'état de basculement, la saturation du disque, les transactions de longue durée et la croissance des WAL.

Restrictions
- Vous ne pouvez pas modifier le schéma de l'application et de la base de données (uniquement la partie serveur et les paramètres Postgres/Patroni/HAProxy).
- Vous ne pouvez pas utiliser de base de données gérée, tout reste sur le fournisseur actuel.
- L'accès à la production est limité : le travail aux heures de grande écoute consiste uniquement en lecture et diagnostic, modifications et commutations - selon une fenêtre convenue.
- La documentation doit être compréhensible pour l'ingénieur qui assurera la maintenance du système une fois les travaux terminés.

Critères d'acceptation (mesurables)
- Le basculement final vers un nouveau primaire prend 10 minutes d'impact total sur le service.
- Réplication en mode normal : lag veille < 5 secondes à charge moyenne (selon métriques) et sans accumulation de WAL.
- Le split-brain a été éliminé : correction des paramètres quorum/ttl/loop_wait/retry_timeout et vérification du scénario de perte de réseau/nœud sur le stand ou dans une fenêtre convenue.
- Sauvegardes : sauvegarde quotidienne complète ou de base et archivage continu WAL, procédure de test PITR réussie avec restauration sur une VM distincte avant une heure spécifiée.
- Surveillance : les métriques Postgres sont disponibles dans Prometheus (y compris le décalage de réplication, les WAL, les requêtes de longue durée), il y a au moins 5 alertes (disque, décalage, indisponibilité du nœud, augmentation des erreurs, arrêt des sauvegardes).
- Transfert des artefacts : configurations Patroni/HAProxy/Postgres actuelles, instructions de mise à jour et de reprise après sinistre, liste des modifications apportées.

Étapes d'exécution
- Audit et enregistrement de l'état actuel, collecte de métriques et de journaux, diagnostic des incidents.
- Conception du schéma cible et du plan de migration avec rollback.
- Déploiement de nouvelles VMs, transfert des configurations, configuration de Patroni/etcd/HAProxy.
- Migration des données (pg_basebackup/pg_upgrade ou méthode convenue), exécution des contrôles.
- Configuration du Barman et test PITR.
- Mise en place de suivis et d'alertes, vérification finale et transfert de documentation.

Outils professionnels dont vous aurez besoin
- patronictl, etcdctl, psql, pgBackRest ou barman, pgbench (ou un analogue pour l'exécution), les exportateurs Prometheus, tcpdump/ss, journald/rsyslog, Ansible (de préférence) pour la reproductibilité.

Important
Ce qu’il faut, c’est un travail pratique sur l’infrastructure, avec une analyse et une migration minutieuse, et non une consultation générale.