Dans cet article de blog, nous nous penchons sur les rouages ​​de la configuration de la réplication en continu (SR) dans PostgreSQL. La réplication en continu est la pierre angulaire de la haute disponibilité de votre hébergement PostgreSQL. Elle est produite en exécutant une configuration maître-esclave.

Terminologie maître-esclave

Serveur maître/primaire

• Le serveur qui peut accepter les écritures.
• Également appelé serveur de lecture/écriture.

Serveur esclave/de secours

• Un serveur où les données sont synchronisées en permanence avec le maître.
• Également appelé serveur de sauvegarde ou réplique.
• Un serveur de secours semi-automatique est un serveur auquel il est impossible de se connecter tant qu'il n'a pas été promu en tant que serveur maître.
• En revanche, un serveur de secours automatique peut accepter des connexions et traiter des requêtes en lecture seule. Pour le reste de cette discussion, nous nous concentrerons uniquement sur les serveurs de secours.

Les données sont écrites sur le serveur maître et propagées aux serveurs esclaves. En cas de problème avec le serveur maître existant, l'un des serveurs esclaves prendra le relais et continuera à prendre en charge les écritures garantissant la disponibilité du système.

Réplication WAL basée sur l'expédition

Qu'est-ce que WAL ?

• WAL signifie Write-Ahead Logging.
• Il s'agit d'un fichier journal dans lequel toutes les modifications apportées à la base de données sont écrites avant d'être appliquées/écrites dans les fichiers de données.
• WAL est utilisé pour la récupération après un crash de la base de données, garantissant l'intégrité des données.
• WAL est utilisé dans les systèmes de bases de données pour atteindre l'atomicité et la durabilité.

Comment WAL est-il utilisé pour la réplication ?

Les enregistrements de journal à écriture anticipée sont utilisés pour synchroniser les données entre les serveurs de base de données. Ceci est réalisé de deux manières :

Envoi de journaux basé sur des fichiers

• Les fichiers journaux WAL sont envoyés du serveur maître aux serveurs de secours pour maintenir la synchronisation des données.
• Le maître peut copier directement les journaux sur le stockage du serveur de secours ou peut partager le stockage avec les serveurs de secours.
• Un fichier journal WAL peut contenir jusqu'à 16 Mo de données.
• Le fichier WAL n'est envoyé qu'après avoir atteint ce seuil.
• Cela entraînera un retard dans la réplication et augmentera également les risques de perte de données si le maître tombe en panne et si les journaux ne sont pas archivés

Enregistrements WAL en streaming

• Les blocs d'enregistrement WAL sont diffusés par les serveurs de base de données pour synchroniser les données.
• Le serveur de secours se connecte au maître pour recevoir les morceaux WAL.
• Les enregistrements WAL sont diffusés au fur et à mesure qu'ils sont générés.
• Le streaming des enregistrements WAL n'a pas besoin d'attendre que le fichier WAL soit rempli.
• Cela permet à un serveur de secours de rester plus à jour que ce qui est possible avec l'envoi de journaux basé sur des fichiers.
• Par défaut, la réplication en continu est asynchrone même si elle prend également en charge la réplication synchrone.

Les deux méthodes ont leurs avantages et leurs inconvénients. L'expédition basée sur les fichiers permet une récupération ponctuelle et un archivage continu, tandis que la diffusion en continu garantit la disponibilité immédiate des données sur les serveurs de secours. Cependant, vous pouvez configurer PostgreSQL pour utiliser les deux méthodes en même temps et profiter des avantages. Dans ce blog, nous nous concentrons principalement sur la réplication en continu pour atteindre la haute disponibilité de PostgreSQL.

Comment configurer la réplication en continu ?

La configuration de la réplication en continu dans PostgreSQL est très simple. En supposant que PostgreSQL est déjà installé sur tous les serveurs, vous pouvez suivre ces étapes pour commencer :

Configuration sur le nœud maître

• Initialisez la base de données sur le nœud maître à l'aide de l'utilitaire initdb.
• Créez un rôle/utilisateur avec des privilèges de réplication en exécutant la commande ci-dessous. Après avoir exécuté la commande, vous pouvez la vérifier en exécutant \du pour les lister sur psql.
  •   CREATE USER RÉPLICATION LOGIN CHIFFRÉ MOT DE PASSE '' ;
• Configurez les propriétés liées à la réplication en continu dans le fichier de configuration maître PostgreSQL (postgresql.conf) :
  

  # Les valeurs possibles sont replica|minimal|logical wal_level =replica# requis pour la capacité pg_rewind lorsque la veille est désynchronisée avec le maître wal_log_hints =on# définit le nombre maximal de connexions simultanées à partir des serveurs de secours. max_wal_senders =3 # Le paramètre ci-dessous est utilisé pour indiquer au maître de conserver le nombre minimum de # segments de journaux WAL afin qu'ils ne soient pas supprimés avant que la veille ne les consomme. # chaque segment est 16 Mo wal_keep_segments =8 # Le paramètre ci-dessous active la connexion en lecture seule sur le nœud lorsqu'il est en # rôle de veille. Ceci est ignoré lorsque le serveur s'exécute en tant que maître. hot_standby =sur

• Ajouter une entrée de réplication dans le fichier pg_hba.conf pour autoriser les connexions de réplication entre les serveurs :
  

  # Autoriser les connexions de réplication à partir de l'hôte local, # par un utilisateur avec le privilège de réplication. # TYPE    DATABASE    USER    ADDRESS    METHOD host    replication    repl_user    IPaddress(CIDR)    md5

• Redémarrez le service PostgreSQL sur le nœud maître pour que les modifications prennent effet.

Configuration sur le(s) nœud(s) de secours

• Créez la sauvegarde de base du nœud maître à l'aide de l'utilitaire pg_basebackup et utilisez-la comme point de départ pour la veille.
  

  # Explication de quelques options utilisées pour l'utilitaire pg_basebackup # L'option -X est utilisée pour inclure les fichiers journaux de transactions requis (fichiers WAL) dans la # sauvegarde. Lorsque vous spécifiez stream, cela ouvrira une deuxième connexion au serveur # et commencera à diffuser le journal des transactions en même temps que l'exécution de la sauvegarde. # -c est l'option de point de contrôle. Le régler sur rapide forcera le point de contrôle à # être créé rapidement. # -W oblige pg_basebackup à demander un mot de passe avant de se connecter # à une base de données. pg_basebackup -D  -h -X flux -c rapide -U repl_user -W

• Créez le fichier de configuration de réplication s'il n'est pas présent (il est créé automatiquement si l'option -R est fournie dans pg_basebackup) :
  

  # Spécifie s'il faut démarrer le serveur en tant que une veille. Dans la réplication en continu, # ce paramètre doit être activé. standby_mode ='on'# Spécifie une chaîne de connexion qui est utilisée pour que le serveur de secours se connecte # avec le primaire/maître. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Spécifie la restauration sur une chronologie particulière. La valeur par défaut consiste à restaurer le long de la # même chronologie qui était en cours lorsque la sauvegarde de base a été effectuée. # Régler ceci sur la dernière restauration à la dernière chronologie trouvée # dans l'archive, qui est utile dans un serveur de secours. recovery_target_timeline ='le plus récent'

• Démarrer la mise en veille.

La configuration de secours doit être effectuée sur tous les serveurs de secours. Une fois la configuration terminée et une veille démarrée, il se connectera au maître et commencera à diffuser les journaux. Cela configurera la réplication et peut être vérifié en exécutant l'instruction SQL "SELECT * FROM pg_stat_replication ; “.

Par défaut, la réplication en continu est asynchrone. Si vous souhaitez le rendre synchrone, vous pouvez le configurer à l'aide des paramètres suivants :

Synchronous_commit doit être activé pour la réplication synchrone et il s'agit de la valeur par défaut. PostgreSQL fournit des options très flexibles pour la validation synchrone et peut être configurée au niveau de l'utilisateur/de la base de données. Les valeurs valides sont les suivantes :

• Désactivé - La validation de la transaction est reconnue au client avant même que cet enregistrement de transaction ne soit réellement vidé dans le fichier journal WAL sur ce nœud.
• Local –  La validation de la transaction n'est reconnue au client qu'après que cet enregistrement de transaction a été vidé dans le fichier journal WAL sur ce nœud.
• Remote_write - La validation de la transaction est reconnue au client uniquement après que le ou les serveurs spécifiés par synchronous_standby_names ont confirmé que l'enregistrement de la transaction a été écrit dans le cache disque, mais pas nécessairement après avoir été vidé dans le fichier journal WAL.
• Activé - La validation de la transaction est reconnue au client uniquement après que le ou les serveurs spécifiés par synchronous_standby_names ont confirmé que l'enregistrement de la transaction est vidé dans le fichier journal WAL.
• Remote_apply - La validation de la transaction est reconnue au client uniquement après que le ou les serveurs spécifiés par synchronous_standby_names ont confirmé que l'enregistrement de la transaction est vidé dans le fichier journal WAL et qu'il est appliqué à la base de données.

Définir synchronous_commit sur off ou local en mode de réplication synchrone le fera fonctionner comme asynchrone et peut vous aider à obtenir de meilleures performances en écriture. Cependant, cela aura un risque plus élevé de perte de données et de retards de lecture sur les serveurs de secours. S'il est défini sur remote_apply, il garantira la disponibilité immédiate des données sur les serveurs de secours, mais les performances d'écriture peuvent se dégrader car il doit être appliqué sur tous les serveurs de secours mentionnés.

Vous pouvez activer le mode d'archivage si vous prévoyez d'utiliser l'archivage continu et la récupération ponctuelle. Bien qu'il ne soit pas obligatoire pour la réplication en continu, l'activation du mode d'archivage présente des avantages supplémentaires. Si le mode d'archivage n'est pas activé, nous devons utiliser les emplacements de réplication fonctionnalité ou assurez-vous que wal_keep_segments la valeur est suffisamment élevée en fonction de la charge.

Reportez-vous à cette excellente présentation pour plus de détails sur la haute disponibilité dans PostgreSQL. Dans notre prochain article de blog, nous vous présenterons le monde des outils utilisés pour gérer la haute disponibilité pour PostgreSQL à l'aide de la réplication en continu.