Repmgr est un outil open-source développé par 2ndQuadrant permettant d’administrer la réplication de bases de données PostgreSQL.
Voyons comment configurer la réplication physique à l’aide de cet outil entre deux bases de données PostgreSQL 11.
1. Mise en place d’un environnement
L’environnement de test est constitué de deux serveurs, l’un visant à héberger la base de données primaire à l’adresse 192.168.122.10, et l’autre la base de données secondaire en réplication
à l’adresse 192.168.122.11. On considère ici qu’une résolution de noms est disponible, soit via alimentation des fichiers /etc/hosts des serveurs, ou bien par un serveur DNS.
Les serveurs sont installés sur CentOS 7.7. Il est nécessaire que les deux serveurs puissent communiquer entre eux sur le port d’écoute PostgreSQL par défaut 5432 et le port ssh 22.
1.1 Installation des repositories et paquets logiciels
Il est recommandé d’installer PostgreSQL depuis le repository du PostgreSQL Global Development Group (PGDG). Ce dernier dépend du repository EPEL (Extra Packages for Enterprise Linux) maintenu par le projet fedora. Il convient donc d’installer ces deux repositories pour éviter tout problème de dépendance. Enfin, repmgr est fourni par le repository public de 2ndQuadrant, il faut donc l’ajouter également.
Les étapes d’installation ci-après sont à réaliser sur les deux serveurs.
Installation du repository EPEL.
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Installation du repository PGDG.
yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
Installation du repository officiel de 2ndQuadrant.
curl https://dl.2ndquadrant.com/default/release/get/11/rpm | bash
Installation de PostgreSQL en version 11.
yum install postgresql11 postgresql11-server postgresql11-contrib
Installation du paquet repmgr pour PostgreSQL 11.
yum install repmgr11
Installation de divers paquets prérequis ou usuels.
yum install rsync telnet unzip nc net-tools
1.2 Configuration des pré-requis
Sur les deux serveurs, associer un mot de passe à l’utilisateur postgres qui a été installé par le rpm.
passwd postgres
Sur les deux serveurs, désactiver le pare-feu. En production, on favoriserait l’ajout de règles pare-feu sur les ports à ouvrir plutôt que sa désactivation totale.
systemctl stop firewalld systemctl disable firewalld
Sur les deux serveurs, il est nécessaire d’activer le ssh passwordless entre les utilisateurs postgres des deux serveurs.
pgprimary : -------------- su - postgres ssh-keygen ssh-copy-id -i ~/.ssh/id_rsa.pub pgstandby pgstandby : --------------- su - postgres ssh-keygen ssh-copy-id -i ~/.ssh/id_rsa.pub pgprimary
2. Configuration de l’environnement
2.1 Configuration de PostgreSQL
Depuis le serveur primaire, créer l’instance PostgreSQL en tant que postgres à l’aide de l’outil initdb.
/usr/pgsql-11/bin/initdb --data-checksums
Depuis le serveur primaire, définir les paramètres suivants dans le fichier postgresql.conf qui se trouve dans le répertoire $PGDATA (/var/lib/pgsql/11/data dans le cas d’une installation via le repository PGDG).
listen_addresses = '*' max_wal_senders = 10 max_replication_slots = 10 wal_level = replica hot_standby = on archive_mode = on wal_log_hints = on archive_command = '/bin/true'
NB : L’activation de l’archivage et la commande d’archive « /bin/true » permet simplement d’activer l’archivage sans redémarrage de la base de données à l’avenir. Ici, les wals ne seront pas archivés pour le log shipping, seul la streaming replication sera configurée, même si les deux peuvent fonctionner de concert.
Depuis le serveur primaire, démarrer l’instance et créer l’utilisateur de base de données et la base de données pour repmgr.
/usr/pgsql-11/bin/pg_ctl start createuser -s repmgr createdb repmgr -O repmgr psql postgres=# ALTER USER repmgr SET search_path TO repmgr, "$user", public; postgres=# ALTER USER repmgr WITH PASSWORD 'secret';
Depuis le serveur primaire, autoriser l’utilisateur repmgr à se connecter à la base repmgr ainsi que la pseudo-base replication via le fichier pg_hba.conf.
local replication repmgr trust host replication repmgr 192.168.122.0/24 md5 local repmgr repmgr trust host repmgr repmgr 192.168.122.0/24 md5 local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust
Sur les serveurs primaire et secondaire, créer un fichier .pgpass dans le répertoire home de l’utilisateur postgres pour permettre la connexion à la base de données repgmr et la pseudo-base de données réplication sans spécifier de mot de passe.
vi ~/.pgpass ----------------------------------------- pgprimary:5432:repmgr:repmgr:secret pgprimary:5432:replication:repmgr:secret pgstandby:5432:repmgr:repmgr:secret pgstandby:5432:replication:repmgr:secret -----------------------------------------
Tester la connexion depuis le serveur secondaire vers la base de données repmgr.
psql 'host=pgprimary user=repmgr dbname=repmgr connect_timeout=2'
La connexion doit s’établir.
2.2 Configuration de REPMGR
Depuis le serveur primaire, éditer la configuration de repmgr.
vi /etc/repmgr/11/repmgr.conf
Saisir la configuration suivante :
node_id=1 node_name=pgprimary conninfo='host=pgprimary user=repmgr dbname=repmgr connect_timeout=2' data_directory='/var/lib/pgsql/11/data' use_replication_slots=true
Depuis le serveur secondaire, éditer la configuration de repmgr.
vi /etc/repmgr/11/repmgr.conf
Saisir la configuration suivante :
node_id=2 node_name=pgstandby conninfo='host=pgstandby user=repmgr dbname=repmgr connect_timeout=2' data_directory='/var/lib/pgsql/11/data' pg_bindir='/usr/pgsql-11/bin' use_replication_slots=true
2.3 Mise en place de la streaming replication
Depuis le serveur primaire, effectuer l’enregistrement du serveur primaire. L’extension repmgr va être créée.
repmgr primary register
Depuis le serveur standby, on peut désormais vérifier un ensemble de pré-requis en effectuant un dry-run du clonage vers standby.
repmgr -h pgprimary -U repmgr -d repmgr standby clone --dry-run
Si aucune erreur ne se présente, repasser la même commande sans l’option « –dry-run ».
repmgr -h pgprimary -U repmgr -d repmgr standby clone
La commande clone le répertoire $PGDATA depuis le serveur primaire vers le serveur secondaire. Suite à cette modification, le serveur PostgreSQL secondaire peut être démarré.
pg_ctl start
Depuis le serveur standby, enregistrer le serveur standby.
repmgr standby register
Il est possible de vérifier la configuration à l’aide de la commande suivante :
repmgr cluster show
A ce stade, le serveur secondaire a démarré en mode standby avec réplication active. On peut confirmer ça en créant une table sur le serveur primaire et en vérifiant sa présence coté standby.
3. Utilisation de repmgr
Maintenant que le cluster de haute disponibilité est en place, voyons comment utiliser les possibilités offertes par repmgr.
3.1. Switchover
Le switchover consiste à inverser les rôles entre la primaire et la standby. Cette opération réversible requiert que les deux serveurs soient disponibles, elle n’est donc pas indiquée à la suite d’un désastre sur la base primaire, mais plutôt pour valider le bon fonctionnement de la configuration ou bien pour effectuer des opérations de maintenance sur la base de données primaire en limitant l’indisponibilité de la base de données.
Depuis le serveur secondaire, on commence là aussi par un dry-run de la commande pour vérifier un certain nombre de prérequis.
repmgr standby switchover --dry-run
Si aucune erreur n’apparait et que le message retourné est « INFO: prerequisites for executing STANDBY SWITCHOVER are met », on peut alors lancer la commande sans le « dry-run » pour lancer l’opération de switchover.
repmgr standby switchover
La commande doit retourner « NOTICE: STANDBY SWITCHOVER has completed successfully » à la fin de l’opération, auquel cas l’ancienne base de données primaire est maintenant standby et l’ancienne base de données standby est maintenant primaire. On peut à nouveau valider que la réplication fonctionne bien dans le sens inverse pour valider l’opération.
Une fois le switchover réalisé, on peut très simplement faire machine arrière pour rétablir la situation initiale. Pour ce faire, il suffit de passer la même commande sur le nouveau serveur secondaire (pgprimary) pour ré-inverser les rôles.
repmgr standby switchover
3.1 Failover
L’opération de failover est celle qui consiste à promouvoir un serveur secondaire en primaire, sans considération pour l’ancien serveur primaire. C’est donc l’opération que l’on pourra effectuer suite à un désastre sur le serveur primaire, ce dernier étant alors considéré comme perdu. Dans le contexte de repmgr, le failover consiste à promouvoir la base de données secondaire en primaire. Le serveur primaire à partir de ce moment est arrêté physiquement pour simuler un désastre, les opérations suivantes sont donc réalisées sur le serveur secondaire.
On peut afficher l’état du cluster, repmgr doit retourner le serveur primaire en « unreachable ».
repmgr cluster show
Depuis le serveur secondaire, promouvoir la standby en primaire.
repmgr standby promote
L’ancienne standby prend le rôle de primaire et est prête à accepter les écritures. Repasser la commande repmgr cluster show doit faire apparaitre l’ancienne primaire comme « failed », elle est donc perdue pour le cluster. Pour rétablir la situation initiale, il faut alors cloner la primaire sur l’ancien serveur primaire pour y créer une nouvelle secondaire, pour enfin effectuer le switchover vers cette base de données.
Alternativement, si la base de données est très volumineuse, il peut être couteux en temps de la cloner intégralement, l’outil pg_rewind permet de se passer d’un clonage intégral en « rembobinant » l’ancienne primaire jusqu’au point de divergence, suite à quoi celle-ci peut directement reprendre le rôle de standby repliquée ».
Et si vous souhaitez vous former sur PostgreSQL, découvrez notre offre de formations PostgreSQL.
