PostgreSQL est un système de gestion de base de données relationnelle (RDBMS) puissant et riche en fonctionnalités. Il est gratuit et open-source, et est en développement depuis 1996. Postgres propose différentes manières d'archiver et de répliquer les données, dont l'une est la réplication en continu. Dans ce mode, une instance principale (maître) gère la base de données active principale et exécute les opérations. L'instance secondaire (esclave) copie toutes les modifications à partir de l'instance principale, en conservant une copie identique de la base de données active. Le serveur secondaire peut également accepter des requêtes en lecture seule. Si le serveur principal tombe en panne, le serveur secondaire peut quitter le mode veille et fonctionner en tant que nouveau maître (c'est ce qu'on appelle le basculement).
La réplication PostgreSQL repose généralement sur la journalisation en écriture anticipée (WAL), le processus de journalisation des 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 (envoi de journaux basé sur des fichiers), soit directement diffusés entre les nœuds (réplication en continu). Dans la plupart des cas, ce dernier réduit le délai de réception des modifications sur le nœud maître par le nœud de secours.
Le problème avec l'utilisation de la réplication en continu sans envoi de journaux basé sur les fichiers est que le serveur secondaire peut manquer certains enregistrements WAL si le serveur principal les supprime 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 réside dans les emplacements de réplication, une fonctionnalité fournie par Postgres qui garantit que le serveur principal ne supprime les enregistrements WAL qu'après leur réception par le nœud de secours.
Nous allons configurer la réplication en continu avec des emplacements de réplication sur deux nœuds Debian 10.
Exigences
- Deux instances Debian 10 identiques.
- Accès root aux deux instances.
- La variable d'environnement $EDITOR doit être définie sur les deux instances.
Étape 1 :Installer PostgreSQL
Mettez à jour et redémarrez les deux nœuds :
apt update apt upgrade -y reboot
Installez Postgres sur les deux nœuds et assurez-vous que PostgreSQL est activé et en cours d'exécution :
apt install -y postgresql systemctl enable --now [email protected]
REMARQUE :lors de la mise à jour de PostgreSQL, la mise à jour de la veille en premier est l'option la plus sûre selon leur documentation.
Étape 2 :Configuration initiale
Par défaut, PostgreSQL n'écoute que sur l'interface de bouclage et n'est pas accessible de l'extérieur. Modifiez l'adresse d'écoute sur les deux nœuds en modifiant postgresql.conf :
$EDITOR /etc/postgresql/11/main/postgresql.conf
Recherchez la ligne suivante :
#listen_addresses = 'localhost'
Changez-le en :
listen_addresses = 'node_ip_address,127.0.0.1'
Si les deux nœuds partagent le même réseau local, vous pouvez utiliser des adresses privées pour node_ip_address, bien que Postgres ne soit pas accessible sur Internet. Sinon, utilisez les adresses publiques.
Enregistrez la modification puis redémarrez les deux instances :
systemctl restart [email protected]
Étape 3 :configuration principale
Cette étape concerne uniquement le serveur primaire/maître.
Ouvrez le terminal Postgres :
sudo -u postgres psql
Le nœud de secours utilisera un utilisateur pour se connecter au maître. Créez-le :
postgres=# CREATE ROLE replicator LOGIN REPLICATION ENCRYPTED PASSWORD 'replicator_password';
Créez ensuite un slot de réplication et quittez :
postgres=# SELECT * FROM pg_create_physical_replication_slot('replicator');
postgres=# \q
Par souci de simplicité, le rôle et l'emplacement de réplication sont tous deux nommés "réplicateur", bien qu'ils ne soient pas nécessairement identiques.
Ensuite, créez une entrée dans pg_hba.conf pour permettre à l'utilisateur du réplicateur de se connecter du mode veille au maître. Ouvrez-le :
$EDITOR /etc/postgresql/11/main/pg_hba.conf
Ajoutez la ligne suivante à la fin :
host replication replicator standby_ip_address/32 md5
Redémarrez 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êtez Postgres sur le nœud secondaire :
systemctl stop [email protected]
Sauvegardez l'ancien répertoire de données :
mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.bak
Utilisez la commande suivante pour cloner le répertoire de données du maître vers l'esclave :
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
Un mot de passe vous sera demandé. Entrez le mot de passe que vous avez choisi pour le rôle de réplicateur lors de sa création sur le maître. Une fois le transfert terminé, accordez la propriété du répertoire de données à l'utilisateur postgres :
chown -R postgres:postgres /var/lib/postgresql/11/main
Étape 5 :Configuration de la veille
Cette étape concerne uniquement le serveur secondaire/esclave.
Activez le mode de secours à chaud dans postgresql.conf :
$EDITOR /etc/postgresql/11/main/postgresql.conf
Recherchez et décommentez la ligne suivante :
#hot_standby = on
Créez le fichier recovery.conf dans le répertoire de données de Postgres :
$EDITOR /var/lib/postgresql/11/main/recovery.conf
Activer le mode veille :
standby_mode = 'on'
Définissez les paramètres de connexion de réplication à l'aide des informations d'identification créées sur le maître :
primary_conninfo = 'host=master_ip_address port=5432 user=replicator password=replicator_password'
Définissez le nom du slot de réplication que vous avez créé sur le maître :
primary_slot_name = 'replicator'
Définissez le chemin d'accès à un fichier déclencheur 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 démarrera le fonctionnement normal en tant que serveur principal lorsque ce fichier déclencheur sera créé. Ce paramètre n'est pas obligatoire.
Après avoir créé recovery.conf, accordez la propriété à l'utilisateur postgres :
chown postgres:postgres /var/lib/postgresql/11/main/recovery.conf
Vous pouvez maintenant démarrer Postgres :
systemctl start [email protected]
Il est maintenant en mode veille et devrait répliquer toute nouvelle transaction.
Tests
Tester la réplication
Pour tester la réplication, effectuez n'importe quelle action d'écriture sur le maître. Par exemple, créez une nouvelle base de données sur le maître :
sudo -u postgres psql -c "CREATE DATABASE replitest"
Attendez quelques secondes puis listez les bases de données sur l'esclave :
sudo -u postgres psql -c "\l"
Vous devriez voir que la base de données replitest a bien été répliquée par le serveur de secours :
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 de basculement
REMARQUE :Tester le basculement comme indiqué ici nécessitera la réinitialisation du serveur de secours après le basculement.
Étant donné que Postgres est en mode veille, vous ne devriez pas pouvoir effectuer d'opération d'écriture sur le nœud secondaire avant le basculement. Par exemple, exécutez 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éez le fichier déclencheur spécifié dans recovery.conf
touch /var/lib/postgresql/11/main/failover.trigger
Attendez quelques secondes, puis essayez d'effectuer une opération d'écriture. Par exemple :
sudo -u postgres psql -c "CREATE DATABASE test2"
Étant donné que Postgres ne fonctionne plus en mode veille, l'opération réussira. Postgres renommera également votre fichier recovery.conf en recovery.done et supprimera le fichier déclencheur.
Pour revenir en veille, arrêtez Postgres sur l'(ancien) nœud secondaire :
systemctl stop [email protected]
Réinitialiser 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éez recovery.conf :
cp /var/lib/postgresql/11/main.2.bak/recovery.done /var/lib/postgresql/11/main/recovery.conf
Enfin, redémarrez Postgres :
systemctl start [email protected]
L'instance secondaire est maintenant revenue en mode veille. Vous voudrez peut-être tester à nouveau la réplication à ce stade.
Finir
Supprimez toutes les bases de données inutiles sur le nœud maître, par exemple :
sudo -u postgres psql postgres=# DROP DATABASE replitest;
Et supprimez les anciens répertoires de données sur votre nœud de secours :
rm /var/lib/postgresql/11/main.bak -r rm /var/lib/postgresql/11/main.2.bak -r