Qu’est-ce que la Streaming Replication (WAL) de PostgreSQL et comment la configurer

• La Streaming Replication de PostgreSQL est une méthode efficace pour maintenir une réplique quasi en temps réel de la base de données primaire sur un ou plusieurs serveurs standby
• Le serveur primaire transmet en continu les enregistrements du Write-Ahead Log (WAL) aux serveurs standby au fur et à mesure de leur création, afin de minimiser la latence du processus de réplication
• Conçue pour améliorer la haute disponibilité et la scalabilité, elle permet de déporter les requêtes de lecture vers les serveurs standby afin de réduire la charge du serveur primaire
• Elle prend en charge les modes synchrone et asynchrone, ce qui permet d’ajuster avec souplesse l’équilibre entre cohérence des données et performances
• Le processus inclut la connexion du serveur standby au primaire pour demander le streaming des WAL, puis l’application des enregistrements reçus à sa propre copie de la base
• Par rapport au transfert de journaux basé sur des fichiers, elle offre un basculement plus rapide et réduit le risque de perte de données, ce qui la rend idéale pour les environnements géographiquement distribués

Comment fonctionne la Streaming Replication ?

• Les données WAL sont transmises en continu et en temps réel du serveur primaire vers le serveur standby afin de maintenir la base du standby presque identique à celle du primaire
• Cela permet d’utiliser des répliques pour le basculement du maître ou pour traiter des opérations de lecture, ce qui rend possible une montée en charge du système par plusieurs ordres de grandeur

Fichiers de configuration PostgreSQL et leur emplacement

• Les fichiers de configuration PostgreSQL jouent un rôle essentiel dans la gestion des paramètres et du fonctionnement du serveur de base de données.
  • postgresql.conf : fichier principal contenant la plupart des paramètres du serveur. Selon le système d’exploitation, il peut se trouver à différents emplacements comme /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) ou /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
  • pg_hba.conf : contrôle l’authentification des clients et définit la manière dont ils peuvent se connecter au serveur. Il se trouve généralement dans le même répertoire que postgresql.conf
  • pg_ident.conf : utilisé pour le mapping des noms d’utilisateur, mais moins fréquemment employé
  • recovery.conf : utilisé pour configurer les serveurs standby dans les versions antérieures à PostgreSQL 12, mais son contenu a ensuite été déplacé vers postgresql.conf et postgresql.auto.conf
• L’emplacement exact peut varier selon le système d’exploitation, la méthode d’installation et la version de PostgreSQL
  • Vous pouvez localiser ces fichiers depuis une instance PostgreSQL avec la commande SQL SHOW config_file;

Exemple et structure des WAL (Write Ahead Logs)

• La commande pg_waldump permet d’afficher les WAL
• Chaque ligne représente un enregistrement WAL contenant des informations sur une opération de la base de données
• Composants de chaque enregistrement :
  • rmgr : gestionnaire de ressources (par ex. Heap, Btree, Transaction)
  • len : longueur de l’enregistrement
  • tx : ID de transaction
  • lsn : numéro de séquence du journal
  • prev : LSN précédent
  • desc : description de l’opération
• Types d’opérations visibles :
  • opérations INSERT (Heap et Btree)
  • opérations MULTI_INSERT (Heap2)
  • transactions COMMIT
  • opérations sur les fichiers (CREATE)
  • Full Page Writes (FPW)
• La sortie WAL montre en détail le flux des transactions, les modifications de données et l’activité du système, ce qui la rend utile pour analyser le comportement de la base, résoudre des problèmes et effectuer une restauration à un instant donné

Comment travailler avec Docker

• Paramètres importants liés à la Streaming Replication dans postgresql.conf :
  • wal_level, max_wal_senders, max_replication_slots, hot_standby, etc.
• Éléments nécessaires pour un exemple Docker Compose :
  • init-master.sh : configure le maître PostgreSQL pour la réplication. Crée l’utilisateur et le slot de réplication, puis met à jour les paramètres liés aux WAL
  • init-replica.sh : prépare la réplique PostgreSQL à se connecter au maître et à démarrer la réplication. Attend que le maître soit prêt, effectue une sauvegarde de base, puis configure la réplique
  • start-replica.sh : démarre la réplique PostgreSQL dans le conteneur Docker. Exécute le script init-replica.sh, puis démarre PostgreSQL
  • docker-compose.yml : définit les services maître et réplique, ainsi que les variables d’environnement, volumes, commandes et autres éléments nécessaires
• Après avoir donné les droits d’exécution aux scripts, lancez docker-compose up -d pour démarrer le maître et la réplique
• Vous pouvez vous connecter au maître et vérifier l’état de la réplication avec pg_stat_replication
• Vous pouvez vous connecter à la réplique et vérifier qu’elle est en mode récupération avec pg_is_in_recovery()

L’avis de GN⁺

• La Streaming Replication peut considérablement améliorer les performances et la résilience d’une infrastructure de base de données. Que ce soit pour se préparer à des scénarios de basculement ou pour répartir la charge de lecture sur des répliques, elle permet à la base de monter en charge tout en garantissant des performances stables
• Il est important de montrer l’ensemble du processus de configuration et des sorties produites. Cela offre une vue d’ensemble de toutes les pièces en mouvement et aide à mieux comprendre ce qui se passe
• Il est essentiel de comprendre le fonctionnement de la Streaming Replication et de la configurer correctement. Espérons que cet article a clarifié le processus et apporté un éclairage sur le fonctionnement de la réplication
• Parmi les autres produits ou projets offrant des fonctions similaires, on peut citer la Replication de MySQL ou Data Guard d’Oracle. Ces solutions fonctionnent également en transmettant les modifications du maître vers les répliques, même si les détails d’implémentation peuvent différer
• Lors de l’utilisation de la Streaming Replication, il faut tenir compte de la bande passante réseau et de la latence. Le transfert de données entre le maître et les répliques peut consommer des ressources réseau de manière significative. La capacité à faire évoluer le nombre de répliques est également un point important
• Les exigences de cohérence des données doivent aussi être évaluées. La réplication synchrone peut affecter les performances en écriture, mais offre une cohérence plus forte. La réplication asynchrone fournit de meilleures performances, mais comporte un léger risque de perte de données

[GN⁺]

Avis Hacker News

• Cet article est excellent, mais certains estiment qu’il manque de cas d’usage concrets du point de vue d’un développeur full-stack qui cherche à administrer une base de données

  • Question sur la manière de vérifier à quel point le réplica est en retard par rapport au maître
  • Suggestion d’utiliser une simple tâche cron pour surveiller l’état du réplica
  • Question plus complexe sur la manière de basculer vers le réplica si le serveur principal tombe en panne
  • Réflexion sur le choix entre un basculement automatique ou manuel
  • Interrogation sur la nécessité de disposer de deux réplicas pour éviter un scénario de split-brain
  • Question sur la manière de revenir à l’état initial après le basculement

• Certains affirment que la solution la plus simple pour la réplication PostgreSQL est un opérateur Kubernetes

  • CloudnativePG est cité en exemple
  • Il est expliqué qu’au-delà de la réplication, il faut aussi gérer le failover, la restauration, la supervision, l’auto-réparation et les sauvegardes
  • Question sur l’existence d’autres implémentations gratuites/open source en dehors de Kubernetes

• Pour certains, l’une des raisons d’utiliser Kubernetes et Helm est justement de pouvoir résoudre ce problème

  • Il est expliqué qu’avec le package Bitnami PostgreSQL, on peut presque tout configurer sans réglages supplémentaires
  • Il est expliqué que Postgres-ha crée un proxy et gère les défaillances de manière spécialisée, ce qui permet un failover sans interruption

• Recommandation de StackGres pour les utilisateurs de Kubernetes

• Enfin, un avis sceptique estime que cet article semble avoir été rédigé par une IA