Recherche de site Web

Comment configurer la réplication en streaming PostgreSQL 12 dans CentOS 8


La base de données PostgreSQL prend en charge plusieurs solutions de réplication pour créer des applications à haute disponibilité, évolutives et tolérantes aux pannes, dont l'une est le Write-Ahead Log (WAL ) Expédition. Cette solution permet d'implémenter un serveur de secours en utilisant l'envoi de journaux basé sur des fichiers ou la réplication en continu, ou si possible, une combinaison des deux approches.

Avec la réplication en continu, un serveur de base de données de secours (esclave de réplication) est configuré pour se connecter au serveur maître/primaire, qui diffuse les enregistrements WAL vers le serveur de secours au fur et à mesure de leur génération, sans attendre le WAL fichier à remplir.

Par défaut, la réplication en continu est asynchrone : les données sont écrites sur le(s) serveur(s) de secours après qu'une transaction a été validée sur le serveur principal. Cela signifie qu'il y a un petit délai entre la validation d'une transaction sur le serveur maître et le moment où les modifications deviennent visibles sur le serveur de secours. L'un des inconvénients de cette approche est qu'en cas de panne du serveur maître, les transactions non validées risquent de ne pas être répliquées, ce qui peut entraîner une perte de données.

Ce guide montre comment configurer une réplication streaming maître-veille Postgresql 12 sur CentOS 8. Nous utiliserons des « emplacements de réplication » pour le serveur de secours comme solution pour éviter que le serveur maître ne recycle les anciens segments WAL avant que le serveur de secours ne les ait reçus.

Notez que par rapport à d’autres méthodes, les emplacements de réplication conservent uniquement le nombre de segments dont on sait qu’ils sont nécessaires.

Environnement de test :

Ce guide suppose que vous êtes connecté à vos serveurs de base de données maître et de secours en tant que racine via SSH (utilisez la commande Sudo si nécessaire si vous êtes connecté en tant qu'utilisateur normal avec des droits d'administrateur) :

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Postgresql 12 doit être installé sur les deux serveurs de base de données. Sinon, consultez : Comment installer PostgreSQL et pgAdmin dans CentOS 8.

Remarque : PostgreSQL 12 comporte des modifications majeures dans l'implémentation et la configuration de la réplication, telles que le remplacement de recovery.conf et la conversion des paramètres recovery.conf en paramètres de configuration PostgreSQL normaux, ce qui facilite grandement la configuration de la réplication de cluster.

Étape 1 : Configuration du serveur de base de données maître/primaire PostgreSQL

1. Sur le serveur maître, basculez vers le compte système postgres et configurez la ou les adresses IP sur lesquelles le serveur maître écoutera les connexions des clients.

Dans ce cas, nous utiliserons * signifiant tout.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

La commande SQL ALTER SYSTEM SET est une fonctionnalité puissante pour modifier les paramètres de configuration d'un serveur, directement avec une requête SQL. Les configurations sont enregistrées dans le fichier postgresql.conf.auto situé à la racine du dossier data (par exemple /var/lib/pgsql/12/data/) et lisez l'ajout à ceux stockés dans postgresql.conf. Mais les configurations du premier ont priorité sur celles du second et sur les autres fichiers associés.

2. Créez ensuite un rôle de réplication qui sera utilisé pour les connexions du serveur de secours vers le serveur maître, à l'aide du programme createuser. Dans la commande suivante, l'indicateur -P demande un mot de passe pour le nouveau rôle et -e fait écho aux commandes générées par createuser et envoyées au serveur de base de données.

su – postgres
createuser --replication -P -e replicator
exit

3. Saisissez ensuite l'entrée suivante à la fin du fichier de configuration d'authentification client /var/lib/pgsql/12/data/pg_hba.conf avec le champ de base de données défini sur réplication comme indiqué dans la capture d'écran.

host    replication     replicator      10.20.20.8/24     md5

4. Redémarrez maintenant le service Postgres12 à l'aide de la commande systemctl suivante pour appliquer les modifications.

systemctl restart postgresql-12.service

5. Ensuite, si le service firewalld est en cours d'exécution, vous devez ajouter le service Postgresql dans la configuration firewalld pour autoriser les requêtes du serveur de secours vers le maître.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Étape 2 : Réalisation d'une sauvegarde de base pour amorcer le serveur de secours

6. Ensuite, vous devez effectuer une sauvegarde de base du serveur maître à partir du serveur de secours ; cela aide à amorcer le serveur de secours. Vous devez arrêter le service postgresql 12 sur le serveur de secours, passer au compte utilisateur postgres, sauvegarder le répertoire de données (/var/lib/pgsql/12/data/), puis supprimer tout ce qu'il contient. comme indiqué, avant d'effectuer la sauvegarde de base.

systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Utilisez ensuite l'outil pg_basebackup pour effectuer la sauvegarde de base avec le droit de propriété (l'utilisateur du système de base de données, c'est-à-dire Postgres, dans le compte utilisateur Postgres) et avec les autorisations appropriées.

Dans la commande suivante, l'option :

  • -h – spécifie l'hôte qui est le serveur maître.
  • -D – spécifie le répertoire de données.
  • -U – spécifie l'utilisateur de la connexion.
  • -P – active le rapport de progression.
  • -v – active le mode verbeux.
  • -R – permet la création d'une configuration de récupération : crée un fichier standby.signal et ajoute les paramètres de connexion à postgresql.auto.conf sous les données. annuaire.
  • -X – utilisé pour inclure les fichiers journaux à écriture anticipée requis (fichiers WAL) dans la sauvegarde. La valeur stream signifie diffuser le WAL pendant la création de la sauvegarde.
  • -C – permet la création d'un emplacement de réplication nommé par l'option -S avant de démarrer la sauvegarde.
  • -S – spécifie le nom de l'emplacement de réplication.
pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Une fois le processus de sauvegarde terminé, le nouveau répertoire de données sur le serveur de secours devrait ressembler à celui sur la capture d'écran. Un standby.signal est créé et les paramètres de connexion sont ajoutés à postgresql.auto.conf. Vous pouvez lister son contenu à l'aide de la commande ls.

ls -l /var/lib/pgsql/12/data/

Un esclave de réplication s'exécutera en mode « Hot Standby » si le paramètre hot_standby est défini sur on (la valeur par défaut) dans postgresql.conf et il y a un fichier standby.signal présent dans le répertoire de données.

9. De retour sur le serveur maître, vous devriez pouvoir voir l'emplacement de réplication appelé pgstandby1 lorsque vous ouvrez la vue pg_replication_slots comme suit.

su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

10. Pour afficher les paramètres de connexion ajoutés dans le fichier postgresql.auto.conf, utilisez la commande cat.

cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Commencez maintenant les opérations normales de base de données sur le serveur de secours en démarrant le service PostgreSQL comme suit.

systemctl start postgresql-12

Étape 3 : tester la réplication en streaming PostgreSQL

12. Une fois qu'une connexion est établie avec succès entre le maître et le serveur de secours, vous verrez un processus récepteur WAL dans le serveur de secours avec un statut de streaming, vous pouvez le vérifier en utilisant la vue pg_stat_wal_receiver.

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

et un processus émetteur WAL correspondant dans le serveur maître/primaire avec un état de streaming et un sync_state asynchrone, vous pouvez vérifier cette vue pg_stat_replication pg_stat_replication.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

D'après la capture d'écran ci-dessus, la réplication en streaming est asynchrone. Dans la section suivante, nous montrerons comment activer éventuellement la réplication synchrone.

13. Testez maintenant si la réplication fonctionne correctement en créant une base de données de test sur le serveur maître et vérifiez si elle existe sur le serveur de secours.
[master]postgres=# CRÉER UNE BASE DE DONNÉES tecmint;
[veille]postgres=# \l

Facultatif : Activation de la réplication synchrone

14. La réplication synchrone offre la possibilité de valider une transaction (ou d'écrire des données) simultanément dans la base de données principale et dans la base de données de secours/réplica. Il confirme uniquement qu'une transaction a réussi lorsque toutes les modifications apportées par la transaction ont été transférées vers un ou plusieurs serveurs de secours synchrones.

Pour activer la réplication synchrone, le synchronous_commit doit également être activé (qui est la valeur par défaut, donc aucune modification n'est nécessaire) et vous devez également définir le paramètre synchronous_standby_names. à une valeur non vide. Pour ce guide, nous le définirons sur all.

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Rechargez ensuite le service PostgreSQL 12 pour appliquer les nouvelles modifications.

systemctl reload postgresql-12.service

16. Désormais, lorsque vous interrogez à nouveau le processus émetteur WAL sur le serveur principal, il devrait afficher un état de streaming et un sync_state de synchronisation.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Nous sommes arrivés à la fin de ce guide. Nous avons montré comment configurer la réplication en streaming de base de données maître-veille PostgreSQL 12 dans CentOS 8. Nous avons également expliqué comment activer la réplication synchrone dans un cluster de bases de données PostgreSQL.

Il existe de nombreuses utilisations de la réplication et vous pouvez toujours choisir une solution qui répond à votre environnement informatique et/ou aux exigences spécifiques de votre application. Pour plus de détails, accédez à Log-Shipping Standby Servers dans la documentation PostgreSQL 12.