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’expédition du journal WAL (Write-Ahead Log). Cette solution permet de mettre en œuvre un serveur de secours à l’aide de la copie des journaux de transaction basée sur des fichiers ou de la réplication en continu, ou, si possible, d’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/principal, qui diffuse en continu les enregistrements WAL vers le serveur de secours au fur et à mesure qu’ils sont générés, sans attendre que le fichier WAL soit rempli.

Par défaut, la réplication en continu est asynchrone et les données sont écrites sur le ou les serveurs 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 peuvent ne pas être répliquées, ce qui peut entraîner une perte de données.

Ce guide montre comment configurer une réplication de streaming maître-secours Postgresql 12 sur CentOS 8. Nous utiliserons des « slots de réplication » pour le serveur de secours comme solution afin d’é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 ne conservent que 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 root via SSH (utilisez la commande Sudo si nécessaire si vous êtes connecté en tant qu’utilisateur normal avec des droits d’administration) :

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 apporte des modifications majeures à 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 ALTER SYSTEM SET SQL 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 lus en plus de celles stockées dans postgresql.conf. Mais les configurations du premier ont la priorité sur celles du second et des autres fichiers associés.

2. Créez ensuite un rôle de réplication qui sera utilisé pour les connexions du serveur de secours au 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 l’option -e fait écho aux commandes générées et envoyées par createuser au serveur de base de données.

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

3. Entrez ensuite l’entrée suivante à la fin du fichier de configuration d’authentification du client /var/lib/pgsql/12/data/pg_hba.conf avec le champ de base de données défini sur la 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 du 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 : Effectuer 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 permet d’amorcer le serveur de secours. Vous devez arrêter le service postgresql 12 sur le serveur de secours, basculer vers le compte utilisateur postgres, sauvegarder le répertoire de données (/var/lib/pgsql/12/data/), puis supprimer tout ce qui se trouve en dessous 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 bon propriétaire (l’utilisateur du système de base de données, c’est-à-dire Postgres, dans le compte utilisateur Postgres) et avec les bonnes autorisations.

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 connexion.
-P – permet de rendre compte de l’avancement.
-v – active le mode détaillé.
-R – permet la création de la configuration de récupération : Crée un fichier standby.signal et ajoute les paramètres de connexion à postgresql.auto.conf sous le répertoire data.
-X – utilisé pour inclure les fichiers journaux à écriture anticipée requis (fichiers WAL) dans la sauvegarde. Une valeur de stream signifie diffuser le WAL pendant la création de la sauvegarde.
-C : permet de créer 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 doit ressembler à celui de la capture d’écran. Un fichier 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 à on (la valeur par défaut) dans postgresql.conf et qu’il y a un fichier standby.signal présent dans le répertoire data.

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 la base de données sur le serveur de secours en démarrant le service PostgreSQL comme suit.

# systemctl start postgresql-12

Étape 3 : Test de la réplication en continu 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 de récepteur WAL sur le serveur de secours avec un statut de streaming, vous pouvez le vérifier à l’aide de la vue pg_stat_wal_receiver.

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

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

$ 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 allons montrer comment activer la réplication synchrone en option.

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 ;
[standby]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) dans la base de données principale et la base de données de secours/réplica simultanément. Il ne confirme qu’une transaction a réussi que 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 défini sur on (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 sur une valeur non vide. Pour ce guide, nous allons le régler pour tous.

$ 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. Maintenant, lorsque vous interrogez à nouveau le processus d’envoi WAL sur le serveur primaire, il doit 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 continu de la base de données maître-secours PostgreSQL 12 dans CentOS 8. Nous avons également expliqué comment activer la réplication synchrone dans un cluster de base de données PostgreSQL.