Comment configurer la réplication en continu PostgreSQL avec des slots de réplication sur Debian 10

PostgreSQL est un système de gestion de base de données relationnelle (SGBDR) puissant et riche en fonctionnalités. Il est gratuit et open-source, et est en développement depuis 1996. Postgres propose différents modes d’archivage et de réplication des données, dont l’un est la réplication en continu. Dans ce mode, une instance primaire (maître) gère la principale base de données active et exécute les opérations. L’instance secondaire (esclave) copie toutes les modifications de l’instance primaire, conservant ainsi une copie identique de la base de données active. Le serveur secondaire peut aussi accepter des requêtes en lecture seule. Si le primaire tombe en panne, le serveur secondaire peut sortir du mode veille et fonctionner comme le nouveau maître (c’est ce qu’on appelle le basculement).

La réplication PostgreSQL s’appuie généralement sur la journalisation write-ahead (WAL), le processus qui consiste à enregistrer les modifications de données avant de les écrire sur le disque. Ces enregistrements WAL sont ensuite soit copiés sur un deuxième nœud sous forme de fichiers (expédition de journaux basée sur des fichiers), soit directement diffusés entre les nœuds (réplication en continu). Dans la plupart des cas, cette dernière solution réduit le délai de réception des modifications sur le nœud maître par le nœud en attente.

Le problème de l’utilisation de la réplication en continu sans expédition de journaux basée sur des fichiers est que le serveur secondaire peut manquer certains enregistrements WAL si le primaire les rejette trop tôt. Un certain nombre de paramètres de configuration peuvent réduire ce risque mais s’accompagnent souvent d’un coût de stockage inutile. La solution est la réplication en continu, une fonctionnalité fournie par Postgres qui garantit que le serveur primaire ne jette les enregistrements WAL qu’après qu’ils ont été reçus par le nœud en attente.

Nous allons configurer la réplication en continu avec des créneaux de réplication sur deux nœuds Debian 10.

Exigences

  • Deux instances Debian 10 identiques.
  • Accès à la racine des deux instances.
  • La variable d’environnement $EDITOR doit être définie sur les deux instances.

Étape 1 : Installation de PostgreSQL

Mets à jour et redémarre les deux nœuds :

apt update
apt upgrade -y
reboot

Installe Postgres sur les deux nœuds et assure-toi que PostgreSQL est activé et fonctionne :

apt install -y postgresql
systemctl enable --now [email protected]

REMARQUE : Lors de la mise à jour de PostgreSQL, mettre d’abord à jour le standby est l’option la plus sûre selon leur documentation.

Étape 2 : Configuration initiale

Par défaut, PostgreSQL écoute uniquement sur l’interface loopback et n’est pas accessible de l’extérieur. Change l’adresse d’écoute sur les deux nœuds en éditant postgresql.conf:

$EDITOR /etc/postgresql/11/main/postgresql.conf

Trouve la ligne suivante :

#listen_addresses = 'localhost'

Change-la en :

listen_addresses = 'node_ip_address,127.0.0.1'

Si les deux nœuds partagent le même réseau local, tu peux utiliser des adresses privées pour node_ip_address, mais Postgres ne sera pas accessible sur Internet. Sinon, utilise des adresses publiques.

Enregistre la modification puis redémarre les deux instances :

systemctl restart [email protected]

Étape 3 : Configuration du maître

Cette étape ne concerne que le serveur primaire/maître.

Ouvre le terminal Postgres :

sudo -u postgres psql

Le nœud standby utilisera un utilisateur pour se connecter au maître. Crée-le :

postgres=# CREATE ROLE replicator LOGIN REPLICATION ENCRYPTED PASSWORD 'replicator_password';

Crée ensuite un emplacement de réplication et quitte :

postgres=# SELECT * FROM pg_create_physical_replication_slot('replicator');
postgres=# \q

Pour simplifier, le rôle de réplication et le slot sont tous deux nommés « replicator », bien qu’ils ne doivent pas nécessairement être identiques.

Ensuite, crée une entrée dans pg_hba.conf pour autoriser l’utilisateur du réplicateur à se connecter du standby au master. Ouvre-la :

$EDITOR /etc/postgresql/11/main/pg_hba.conf

Ajoute la ligne suivante à la fin :

host	replication	replicator	standby_ip_address/32		md5

Redémarre l’instance maître :

systemctl restart [email protected]

Étape 4 : Sauvegarde de base

Les commandes de cette étape doivent être exécutées sur le serveur secondaire/esclave.

Tout d’abord, arrête Postgres sur le nœud secondaire:

systemctl stop [email protected]

Sauvegarde l’ancien répertoire de données :

mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.bak

Utilise la commande suivante pour cloner le répertoire de données du maître sur l’esclave :

pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator

Tu seras invité à entrer un mot de passe. Saisis le mot de passe que tu as choisi pour le rôle de réplicateur lors de sa création sur le maître. Une fois le transfert terminé, accorde la propriété du répertoire de données à l’utilisateur postgres:

chown -R postgres:postgres /var/lib/postgresql/11/main

Étape 5 : Configuration du standby

Cette étape ne concerne que le serveur secondaire/esclave.

Active le mode de veille à chaud dans postgresql.conf:

$EDITOR /etc/postgresql/11/main/postgresql.conf

Trouve et décommente la ligne suivante :

#hot_standby = on

Crée le fichier recovery.conf dans le répertoire de données Postgres :

$EDITOR /var/lib/postgresql/11/main/recovery.conf

Active le mode veille :

standby_mode = 'on'

Définis les paramètres de connexion de réplication en utilisant les informations d’identification créées sur le maître :

primary_conninfo = 'host=master_ip_address port=5432 user=replicator password=replicator_password'

Définis le nom de l’emplacement de réplication que tu as créé sur le maître :

primary_slot_name = 'replicator'

Définis le chemin d’accès à un fichier de déclenchement de basculement :

trigger_file = '/var/lib/postgresql/11/main/failover.trigger'

Si le paramètre trigger_file est défini, Postgres quittera le mode veille et commencera à fonctionner normalement en tant que serveur primaire lorsque ce fichier de déclenchement sera créé. Ce paramètre n’est pas nécessaire.

Après avoir créé recovery.conf, accorde la propriété à l’utilisateur postgres:

chown postgres:postgres /var/lib/postgresql/11/main/recovery.conf

Tu peux maintenant démarrer Postgres :

systemctl start [email protected]

Il est maintenant en mode veille et devrait répliquer toute nouvelle transaction.

Test de

Test de la réplication

Pour tester la réplication, effectue n’importe quelle action d’écriture sur le maître. Par exemple, crée une nouvelle base de données sur le maître :

sudo -u postgres psql -c "CREATE DATABASE replitest"

Attends quelques secondes puis liste les bases de données sur l’esclave :

sudo -u postgres psql -c "\l"

Tu devrais voir que la base de données du test de réplication a bien été répliquée par le serveur standby :

List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 replitest | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)

Test du basculement

REMARQUE : Pour tester le basculement comme indiqué ici, il faudra réinitialiser le serveur en attente après le basculement.

Comme Postgres est en mode veille, tu ne devrais pas pouvoir effectuer d’opération d’écriture sur le nœud secondaire avant le basculement. Par exemple, exécute la commande suivante :

sudo -u postgres psql -c "CREATE DATABASE test"

La commande devrait échouer :

ERROR:  cannot execute CREATE DATABASE in a read-only transaction

Pour signaler le basculement, crée le fichier de déclenchement spécifié dans recovery.conf.

touch /var/lib/postgresql/11/main/failover.trigger

Attends quelques secondes, puis essaie d’effectuer une opération d’écriture. Par exemple :

sudo -u postgres psql -c "CREATE DATABASE test2"

Comme Postgres ne fonctionne plus en tant que standby, l’opération réussira. Postgres renommera également ton fichier recovery.conf en recovery.done, et supprimera le fichier déclencheur.

Pour revenir en standby, arrête Postgres sur l’ancien nœud secondaire :

systemctl stop [email protected]

Réinitialise le répertoire de données :

mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.2.bak
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
chown -R postgres:postgres /var/lib/postgresql/11/main

Et recrée le fichier recovery.conf:

cp /var/lib/postgresql/11/main.2.bak/recovery.done /var/lib/postgresql/11/main/recovery.conf

Enfin, redémarre Postgres :

systemctl start [email protected]

L’instance secondaire est maintenant de retour en mode veille. Tu peux souhaiter tester à nouveau la réplication à ce stade.

Finition

Supprime toutes les bases de données inutiles sur le nœud maître, par exemple :

sudo -u postgres psql
postgres=# DROP DATABASE replitest;

Et supprime les anciens répertoires de données sur ton nœud standby :

rm /var/lib/postgresql/11/main.bak -r
rm /var/lib/postgresql/11/main.2.bak -r

Vous aimerez aussi...