Mise en oeuvre de la réplication PostgreSQL sous Linux

La réplication PostgreSQL permet facilement de mettre en place une base de type Hot standby database sans coût ni produit supplémentaires. De plus, sous certaines conditions de configuration, le cluster en standby est accessible en lecture seule.
 

1 Remarques

Il est habituellement préférable de créer les serveurs primaires et de standby de façon à ce qu’ils soient aussi similaires que possible, au moins du point de vue du serveur de bases de données. En particulier, les chemins associés avec les tablespaces seront passés d’un nœud à l’autre sans conversion (contrairement à ce que l’on peut faire sous Oracle), ce qui implique que les serveurs primaire et de standby doivent avoir les mêmes chemins de montage pour les tablespaces.
 
Gardez en tête que si CREATE TABLESPACE est exécuté sur le primaire, tout nouveau point de montage nécessaire pour cela doit être créé sur le primaire et tous les standby avant que la commande ne soit exécutée.
Le matériel n’a pas besoin d’être exactement le même, mais l’expérience montre que maintenir deux systèmes identiques est plus facile que maintenir deux différents sur la durée de l’application et du système.
 
Quoi qu’il en soit, l’architecture hardware doit être la même : répliquer par exemple un serveur 32 bits vers un 64 bits ne fonctionnera pas.
 

2 Pré-requis système

Assurez-vous que les fichiers /etc/hosts des serveurs primaire et standby soient correctement renseignés
 

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
172.xxx.yyy.zz1   serveurb01 serveurb01.fq.dn
172.xxx.yyy.zz2   serveurb02 serveurb02.fq.dn

 
Effectuer l’échange des clefs ssh entre les serveurs primaire et standby :
sur le serveur serveurb01

ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub serveurb02

 
sur le serveur serveurb02

ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub serveurb01

 
Contrôlez que l’on puisse bien se connecter de l’un à l’autre sans saisir le password.
 
 

3 Pré-requis PostgreSQL

Assurez-vous de la mise en place de l’archivage ( WAL ) et de la configuration « dataguard » dans le fichier $PG_DATA/postgresql.conf.
Dans notre exemple, les wals sont stockés dans le répertoire /u03/pgarch/moncluster.

listen_addresses = 'localhost,adresse.ip.du.serveurb1'
# mise en place de l'archivage
#==============================
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'test ! -f /u03/pgarch/moncluster/%f && cp %p /u03/pgarch/moncluster/%f'
archive_timeout = 300
# mise en place des parametre nécessaire a la standby
#======================================================
max_wal_senders = 10
hot_standby = on

 
Il faut ensuite créer un user spécifique, standby_user, qui ne sera utilisé que dans le cadre de la réplication de type dataguard.
Ce user devra posséder le droit REPLICATION, équivalent du droit superuser, dédié à la réplication des transactions.
 

psql -c "CREATE ROLE standby_user REPLICATION LOGIN ENCRYPTED PASSWORD 'standbyuser';"

 
Modifiez le fichier $PG_DATA/pg_hba.conf de manière à permettre aux serveurs standby de se connecter à la base primaire uniquement avec le user dédié à la réplication (standby_user).
 

host replication standby_user adresse.ip.serveur.standby/32 md5

 
Arrêtez puis redémarrez la base primaire pour faire prendre en compte les modifications de paramétrage.
A ce niveau de la procédure, il est indispensable d’effectuer une sauvegarde à chaud.
 

4 Mise en œuvre de la réplication

  • Sur le serveur secondaire

 
Restaurez la base précédemment sauvegardée.
Configurez le fichier $PG_DATA/postgresql.conf de la manière suivante :

listen_addresses = 'localhost,adresse.ip.du.serveurb2'
wal_level = hot_standby
hot_standby = on

 

hot_standby = on permet d’effectuer du requêtage sur la base standby.
 
Configurez comme suit le fichier $PG_DATA/recovery.conf

standby_mode = 'on'
primary_conninfo = 'host=IP.du.serveur.primaire port=5435 user=standby_user password=standbyuser'
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
trigger_file = '/tmp/MaBdd_replication.stop'

 
où les paramètres correspondent à :
standby_mode active le mode standby
primary_conninfo permet de définir la connexion au serveur primaire avec
l’adresse du serveur
le port
le user initiateur du flux et le mot de passe associé.
 
restore_command La commande utilisée pour restaurer les fichiers d’archive transférés
archive_cleanup_command la commande utilisée pour supprimer les archives une fois ceux-ci
devenus obsolètes
trigger_file définit le nom de fichier à mettre en place pour arrêter l’application des Walls sur la base standby et activer cette dernière en mode failover.
 
Démarrez la base standby.
 

5 Contrôle de la bonne installation de la réplication

Sur le cluster primaire
On contrôle de l’état du cluster, il ne doit pas être en mode recovery

SELECT pg_is_in_recovery();
pg_is_in_recovery
-------------------
f

 
 
Identification du snapshot courant.

SELECT txid_current_snapshot();
txid_current_snapshot
-----------------------
8423298:8423298:

 
sur le serveur « standby »
On vérifie que la base est bien et mode recovery.

SELECT pg_is_in_recovery();
pg_is_in_recovery
-------------------
t

 
Identification du snapshot courant, il doit correspondre à celui trouvé sur le cluster primaire.

SELECT txid_current_snapshot();
txid_current_snapshot
-----------------------
8423298:8423298:

 
Sur le serveur primaire
On contrôle l’état de la réplication.

SELECT * FROM pg_stat_replication;
pid | usesysid |   usename   | application_name | client_addr | client_hostname | client_port |         backend_start         |   state   | sent_location
| write_location | flush_location | replay_location | sync_priority | sync_state
------+----------+--------------+------------------+--------------+-----------------+-------------+-------------------------------+-----------+---------------
+----------------+----------------+-----------------+---------------+------------
3860 | 2959070 | standby_user | walreceiver     | 172.25.48.76 |                 |       34299 | 2015-04-27 12:39:40.798697+02 | streaming | 129/D000000
| 129/D000000   | 129/D000000   | 129/D000000     |             0 | async

 
Voila, la réplication est en place. Dans un prochain post, on verra comment effectuer un switchover et un failover.

1 réflexion sur “Mise en oeuvre de la réplication PostgreSQL sous Linux”

  1. Bonjour,

    Quelques remarques sur ce tutoriel :
    – Il n’y a ici qu’un master et un slave, du coup le max_wal_senders devrait être à 1 non ?
    – Le paramètre hot_standby = on ne doit être présent que sur le slave (pas très clair dans le 1er paragraphe)
    – Pourquoi modifier le fichier hosts et faire un échange de clés si derrière, les hostnames ne sont déclarés nul part ?

    Merci ! 😉

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *