Configuration des emplacements de basculement dans PostgreSQL-17

PostgreSQL 17 introduit des slots de basculement qui améliorent les configurations de haute disponibilité. Un slot de réplication garantit que les données restent fiables et cohérentes entre les nœuds pendant la réplication, tandis qu’un slot de basculement assure la cohérence entre les nœuds, spécifiquement pendant et après un basculement.

Les slots de basculement sont une fonctionnalité puissante qui garantit que la réplication logique peut se poursuivre sans interruption, même après un basculement vers un serveur de secours. L’utilisation de slots de basculement permet aux slots de réplication logique d’être automatiquement synchronisés entre les nœuds principaux et de secours, réduisant ainsi considérablement les temps d’arrêt et la nécessité d’une intervention manuelle lors d’un basculement.

Ce guide vous guidera à travers la configuration d’un cluster PostgreSQL à haute disponibilité en utilisant la nouvelle fonctionnalité de slots de basculement. À la fin, vous disposerez d’une configuration de réplication robuste capable de gérer sans problème un basculement.

Pourquoi les slots de basculement sont importants d’un point de vue historique

Défis dans PostgreSQL 15

• Slots de réplication liés au nœud principal : Dans PostgreSQL 15, les slots de réplication étaient uniquement créés sur le serveur principal. Tous les slots de réplication logique étaient perdus si le serveur principal échouait, entraînant des délais de réplication significatifs et des pertes de données.
• Gestion manuelle du basculement : Lors de scénarios de basculement, les administrateurs recréaient manuellement les slots de réplication sur le nouveau serveur principal, ce qui augmentait la complexité, introduisait des erreurs et prolongeait les temps d’arrêt.
• Pas de synchronisation des slots : Les serveurs de secours ne pouvaient pas savoir quels étaient les slots de réplication logique sur le serveur primaire. Ce manque de synchronisation entraînait une réinitialisation complète des flux de réplication en cas de basculement.

Améliorations dans PostgreSQL 16

Décodage logique minimal

PostgreSQL 16 a introduit une fonctionnalité appelée décodage logique minimal sur les serveurs de secours :

• Décodage minimal sur le serveur de secours : Cela permettait aux serveurs de secours de décoder les journaux WAL pour se préparer à la réplication logique, permettant ainsi la préparation des slots en cas de basculement.
• Basculement plus rapide : En pré-décodant les modifications des WAL sur le serveur de secours, il était possible de réduire le délai de réplication lors de la promotion d’un serveur de secours en serveur primaire. Cependant, cela nécessitait toujours une certaine configuration manuelle pour garantir un basculement fluide.

PostgreSQL 17 : Le changement de jeu – Slots de basculement

• Slots de basculement : L’introduction des slots de basculement dans PostgreSQL 17 élimine le besoin d’intervention manuelle en synchronisant automatiquement les slots de réplication logique entre les serveurs primaire et de secours.
• Synchronisation automatique : Le nouveau travailleur de synchronisation des slots garantit que les slots activés pour le basculement (failover = true) sont toujours synchronisés, même lorsque le nœud primaire est actif.
• Transition Transparente: En cas de basculement, le serveur de secours peut prendre le relais en tant que principal sans perdre aucun slot de réplication, garantissant ainsi aucune perte de données et une réplication continue.

Création d’un cluster haute disponibilité PostgreSQL avec des slots de basculement

Cette section vous guidera dans la création d’un cluster haute disponibilité PostgreSQL avec des slots de basculement. Dans notre exemple, nous utiliserons les nœuds suivants:

1. NœudA (Serveur principal)
2. NœudB (Standby physique)
3. NœudC (Abonné logique)

Prérequis

Avant de commencer, assurez-vous d’avoir:

• PostgreSQL 17 installé sur les trois nœuds.
• Un accès SSH sans mot de passe entre chaque nœud.
• Une compréhension de base de PostgreSQL, de la réplication PostgreSQL et des fichiers de configuration PostgreSQL.

Étape 1: Configuration du nœud principal (NœudA)

1.1 Initialiser le cluster sur NodeA

Après avoir installé PostgreSQL sur le nœud principal, initialisez le cluster; vous pouvez utiliser les commandes suivantes:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Configurer la réplication dans le fichier postgresql.conf

Après avoir initialisé le cluster, modifiez le fichier postgresql.conf, situé par défaut dans /home/pgedge/nodeA/postgresql.conf. Définissez les valeurs des paramètres suivants:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Mettre à jour le fichier pg_hba.conf permettant l’accès à la réplication

Le fichier pg_hba.conf gère l’authentification des clients pour le serveur PostgreSQL. Ajoutez l’entrée suivante à /home/pgedge/nodeA/pg_hba.conf pour assurer l’accès à un utilisateur de réplication:

host replication replicator 127.0.0.1/32 md5

Ensuite, rechargez la configuration:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Créer un utilisateur de réplication

Ensuite, connectez-vous à PostgreSQL et créez l’utilisateur de réplication:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Créer une table et configurer une publication

Ensuite, vous devrez créer une table et créer une publication associée:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Étape 2: Configuration du standby physique (NodeB)

2.1 Initialiser NodeB

Après avoir installé PostgreSQL, initialisez NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Créer une sauvegarde de base

Ensuite, utilisez pg_basebackup pour effectuer une sauvegarde du cluster:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Configurer postgresql.conf sur le nœud B

Modifiez le fichier postgresql.conf (situé dans /home/pgedge/nodeB/postgresql.conf), en définissant :

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Activer la synchronisation des slots de basculement

Utilisez le client psql pour vous connecter à NodeB :

psql -d postgres -p 5433 

Ensuite, utilisez les déclarations suivantes pour configurer la réplication pour NodeB :

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Quittez le client psql et redémarrez NodeB :

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Vérifier la synchronisation des slots

Ensuite, reconnectez-vous à NodeB avec psql et vérifiez que les slots sont synchronisés :

SELECT slot_name, failover, synced FROM pg_replication_slots;

Étape 3 : Configuration du souscripteur logique (NodeC)

3.1 Initialiser le cluster et configurer NodeC

Après avoir installé PostgreSQL, initialisez le cluster ; vous pouvez utiliser les commandes suivantes :

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Ensuite, modifiez le fichier /home/pgedge/nodeC/postgresql.conf, en définissant les valeurs des paramètres suivants :

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Créer un abonnement sur NodeC

Utilisez la commande suivante pour créer un abonnement sur NodeC :

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Étape 4 : Simuler une bascule et garantir la continuité

Vous pouvez utiliser les commandes suivantes pour simuler une bascule et confirmer que la réplication se poursuit et que l’intégrité des données est préservée.

4.1 Simuler une bascule

Utilisez les commandes suivantes pour simuler une défaillance de NodeA, suivie par la promotion de standby à primaire de NodeB :

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

Mettre à jour l’abonnement sur NodeC

Après avoir promu le nœud B, connectez-vous au nœud C et mettez à jour la connexion pour indiquer que le nœud B est désormais le nœud principal :

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Vérifier la continuité des données

Pour tester la réplication, utilisez psql pour vous connecter au Nœud B (maintenant le principal) :

INSERT INTO foo VALUES (3), (4);

Vérifiez la réplication sur le Nœud C :

SELECT * FROM foo;

Conclusion

La fonction de créneau de basculement de PostgreSQL 17 permet une bascule transparente dans les environnements de réplication logique. En suivant les étapes décrites dans ce guide, vous pouvez créer un cluster haute disponibilité qui garantit un flux de données ininterrompu, même en cas de défaillance du serveur principal.

En optimisant les configurations et en tirant parti des nouvelles capacités de PostgreSQL 17, vous pouvez créer une infrastructure de base de données résiliente et efficace pour vos applications critiques.