Gérer la haute disponibilité dans PostgreSQL – Partie 2 :Replication Manager

Déployez-vous PostgreSQL dans le cloud et voulez-vous comprendre vos options pour obtenir une haute disponibilité ? Dans notre article de blog précédent, Gestion de la haute disponibilité dans PostgreSQL – Partie I, nous avons discuté des capacités et du fonctionnement de PostgreSQL Automatic Failover (PAF) de ClusterLabs. Dans la partie II, nous vous présentons un outil open source alternatif, Replication Manager de 2ndQuadrant, qui sera suivi de près par la partie III où nous plongerons dans notre troisième alternative, Patroni de Zalando.

Gestion de la haute disponibilité dans PostgreSQL – Partie I :Basculement automatique PostgreSQL
Gestion de la haute disponibilité dans PostgreSQL – Partie 3 :Patroni

Gestionnaire de réplication (repmgr)

repmgr est une suite d'outils open source développée par 2ndQuadrant pour gérer la réplication et le basculement de vos clusters PostgreSQL. Il fournit les outils pour installer, configurer, gérer et surveiller la réplication de PostgreSQL, et vous permet également d'effectuer des tâches manuelles de basculement et de basculement à l'aide de l'utilitaire repmgr. Cet outil gratuit prend en charge et améliore la réplication en continu intégrée de PostgreSQL.

Replication Manager fournit deux outils principaux pour gérer la réplication et le basculement de PostgreSQL.

repmgr

Utilitaire d'interface de ligne de commande qui vous permet d'effectuer diverses tâches administratives.
repmgr vous permet de configurer des serveurs de secours, de promouvoir des serveurs de secours, d'effectuer un basculement et de surveiller l'état de votre cluster PostgreSQL.
Il fournit également une option de simulation pour presque toutes les commandes administratives.

repmgrd

C'est le démon qui :

Surveille activement les clusters PostgreSQL et effectue les actions nécessaires en fonction de l'état du cluster.
Effectue un basculement automatique en cas de panne du nœud principal en promouvant le serveur de secours le plus éligible en tant que nouveau nœud principal.
Fournit une option pour surveiller et stocker les données liées aux performances de réplication.
Fournit une notification en appelant les scripts utilisateur pour les événements enregistrés.

Comment ça marche

repmrg gère non seulement la réplication des clusters PostgreSQL, mais dispose également de capacités pour configurer les serveurs de secours pour la réplication. Suite à l'installation initiale, nous devons apporter des modifications au fichier de configuration repmgr (repmgr.conf) avec les détails requis sur chaque serveur. Lorsqu'un serveur est configuré, il doit être enregistré auprès de repmgr à l'aide de la commande repmgr primary/standby register. Tout d'abord, le nœud principal est configuré et enregistré. Ensuite, les serveurs de secours sont créés et configurés à l'aide de la commande repmgr standby clone qui clone le nœud de secours PostgreSQL à partir d'un autre serveur PostgreSQL.

Replication Manager utilise la fonctionnalité d'extensions PostgreSQL et crée son propre schéma sur la base de données du cluster pour stocker les informations relatives au cluster. L'installation de l'extension et la création du schéma se produisent lors de l'enregistrement du serveur principal à l'aide de repmgr. Une fois la configuration terminée, les opérations administratives manuelles telles que la promotion, le suivi, le basculement, etc. peuvent être effectuées à l'aide de l'utilitaire repmgr. Pour l'opération de basculement, il faut configurer SSH sans mot de passe entre les nœuds.

Le basculement automatique peut être configuré à l'aide de repmgrd. repmgrd nécessite qu'une bibliothèque partagée 'repmgr' soit chargée au moment du démarrage du serveur PostgreSQL. Le nom de la bibliothèque doit être mentionné dans les shared_preload_libraries paramètre de configuration dans le fichier postgresql.conf. De plus, pour que repmgrd fonctionne, failover=automatic Le paramètre doit être défini dans le fichier repmgr.conf. Une fois tous ces paramètres définis, le démon repmgrd commence à surveiller activement le cluster. S'il y a une défaillance dans le nœud principal, il essaiera de se reconnecter plusieurs fois. Lorsque toutes les tentatives de connexion au primaire échouent, le standby le plus éligible est choisi par élection comme nouveau primaire par repmgrd.

repmgr prend également en charge les notifications d'événements. Il dispose d'un ensemble d'événements prédéfinis et stocke chaque occurrence de ces événements dans la table repmgr.events. repmgr permet de transmettre les notifications d'événements à un programme ou un script défini par l'utilisateur qui peut prendre d'autres mesures, telles que l'envoi d'un e-mail ou le déclenchement d'une alerte. Cela se fait en définissant la event_notification_command paramètre dans repmgr.conf.

Comment gère-t-il le scénario du cerveau divisé ?

repmgr s'attaque aux scénarios de cerveau partagé en utilisant l'emplacement paramètre, où chaque nœud doit spécifier le paramètre d'emplacement en fonction du centre de données dans lequel il est placé. En cas de division du réseau, repmgr assurera la promotion du nœud qui se trouve au même emplacement que le nœud principal. S'il ne trouve aucun nœud à cet emplacement, il ne fera la promotion d'aucun nœud à aucun emplacement.

Il gère également l'isolement du réseau en cas de nombre pair de serveurs dans un cluster. Cela se fait à l'aide d'un nœud supplémentaire appelé serveur témoin. Le serveur témoin est un nœud qui n'est pris en compte que pour le décompte des votes majoritaires. Il n'y aura pas d'installation de PostgreSQL sur ce serveur, et donc, aucun rôle à jouer dans la réplication.

Y a-t-il des exigences de configuration ?

repmgr nécessitera une base de données dédiée et un utilisateur avec des privilèges de superutilisateur. Cependant, il existe également une option pour fournir un superutilisateur si vous ne souhaitez pas donner au superutilisateur l'accès à l'utilisateur repmgr.
Si vous souhaitez que repmgr copie les fichiers de configuration situés en dehors du répertoire de données PostgreSQL et/ou pour tester la fonctionnalité de basculement, vous aurez également besoin de connexions SSH sans mot de passe entre les deux serveurs, et rsync devrait être installé.
Si vous avez l'intention d'utiliser des commandes basées sur des services autres que pg_ctl (qui est utilisé par repmgr par défaut) pour démarrer, arrêter, recharger et redémarrer, vous pouvez les spécifier dans repmgr fichier de configuration (repmgr.conf).

Les paramètres de configuration de base requis dans le fichier de configuration de repmgr sont les suivants :

node_id (entier) – Un entier unique supérieur à zéro qui identifie le nœud.node_name (string) – Une chaîne arbitraire (mais unique), utilisant le nom d'hôte du serveur ou un autre identifiant associé sans ambiguïté au serveur est recommandée pour éviter toute confusion.

conninfo (chaîne) – Informations de connexion à la base de données sous forme de chaîne conninfo. Tous les serveurs du cluster doivent pouvoir se connecter au nœud local à l'aide de cette chaîne.

répertoire_données (chaîne) – Le répertoire de données du nœud. Cela est nécessaire à repmgr pour effectuer des opérations lorsque l'instance PostgreSQL n'est pas en cours d'exécution et qu'il n'y a pas d'autre moyen de déterminer le répertoire de données.

Avantages de repmgr

Repmgr fournit des utilitaires qui aident à configurer les nœuds principaux et de secours et à configurer la réplication.
Il n'utilise aucun port supplémentaire pour la communication. Si vous souhaitez effectuer le basculement, ce n'est qu'alors qu'il faudra configurer SSH sans mot de passe.
Fournit une notification en appelant les scripts utilisateur pour les événements enregistrés.
Effectue un basculement automatique en cas de panne du serveur principal.

repmgr Inconvénients

repmgr ne détecte pas si le serveur de secours est mal configuré avec un nœud inconnu ou inexistant dans la configuration de récupération. Le nœud sera affiché en veille même s'il est en cours d'exécution sans se connecter au nœud de secours principal/en cascade.
Impossible de récupérer le statut d'un autre nœud à partir d'un nœud où le service PostgreSQL est en panne. Par conséquent, il ne fournit pas de solution de contrôle distribué.
Il ne gère pas la récupération de la santé des nœuds individuels.

Gestion de la haute disponibilité dans #PostgreSQL – Partie II :Outil open source repmgr Cliquez pour tweeter

Scénarios de test de haute disponibilité

Nous avons effectué quelques tests sur la gestion de la haute disponibilité PostgreSQL à l'aide de repmgr. Tous ces tests ont été exécutés pendant que l'application s'exécutait et insérait des données dans la base de données PostgreSQL. L'application a été écrite à l'aide du pilote PostgreSQL Java JDBC en exploitant la capacité de basculement de connexion.

Tests de serveur de secours

Sl. Non	Scénario de test	Observation
1	Tuer le processus PostgreSQL	Le serveur de secours a été marqué comme défaillant. Il n'y a eu aucune interruption dans l'application de l'écrivain. Une intervention manuelle a été nécessaire pour redémarrer le processus PostgreSQL.
2	Arrêter le processus PostgreSQL	Le serveur de secours a été marqué comme défaillant. Il n'y a eu aucune interruption dans l'application de l'écrivain. Une intervention manuelle a été nécessaire pour redémarrer le processus PostgreSQL.
3	Redémarrer le serveur	Le serveur de secours a été marqué comme défaillant. Une fois le serveur démarré après le redémarrage, PostgreSQL a été démarré manuellement et le serveur a été marqué comme étant en cours d'exécution. Il n'y a eu aucune interruption dans l'application du rédacteur.
4	Arrêter le processus repmgrd	Le serveur de secours ne fera pas partie de la situation de basculement automatique. Le service PostgreSQL a été trouvé en cours d'exécution. Il n'y a eu aucune interruption dans l'application du rédacteur.

Tests de serveur maître/primaire

Sl. Non	Scénario de test	Observation
1	Tuer le processus PostgreSQL	repmgrd a démarré la vérification de l'état de la connexion au serveur principal sur tous les serveurs de secours pendant un intervalle fixe. Lorsque toutes les tentatives ont échoué, une élection a été déclenchée sur tous les serveurs de secours. À la suite de l'élection, la réserve qui avait le dernier LSN reçu a été promue. Les serveurs de secours qui ont perdu l'élection attendront la notification du nouveau nœud maître et la suivront une fois qu'ils auront reçu la notification. Il y a eu un temps d'arrêt dans l'application d'écriture. Une intervention manuelle a été nécessaire pour redémarrer le processus PostgreSQL.
2	Arrêtez le processus PostgreSQL et ramenez-le immédiatement après l'expiration de la vérification de l'état	repmgrd a démarré la vérification de l'état de la connexion au serveur principal sur tous les serveurs de secours pendant un intervalle fixe. Lorsque toutes les tentatives ont échoué, une élection a été déclenchée sur tous les nœuds de secours. Cependant, le maître nouvellement élu n'a pas notifié les serveurs de secours existants puisque l'ancien maître était de retour. Le cluster a été laissé dans un état indéterminé et une intervention manuelle a été nécessaire.
3	Redémarrer le serveur	repmgrd a lancé l'élection lorsque la vérification de l'état de la connexion principale a échoué sur tous les serveurs de secours. La veille éligible a été promue. Lorsque ce serveur est revenu, il n'a pas rejoint le cluster et a été marqué comme ayant échoué. la commande repmgr node rejoin a été exécutée pour rajouter le serveur au cluster. Il y a eu un temps d'arrêt dans l'application d'écriture.
4	Arrêter le processus repmgr	Le serveur principal ne fera pas partie de la situation de basculement automatique. Le service PostgreSQL est en cours d'exécution. Il n'y a eu aucune interruption dans l'application du rédacteur.

Tests d'isolation réseau

Sl. Non	Scénario de test	Observation
1	Le réseau isole le serveur principal des autres serveurs (tous ont la même valeur pour l'emplacement dans la configuration repmgr)	repmgrd a lancé l'élection lorsque la vérification de l'état de la connexion principale a échoué sur tous les serveurs de secours. Le serveur de secours éligible a été promu, mais le processus PostgreSQL était toujours en cours d'exécution sur l'ancien nœud maître. Il y avait deux nœuds exécutés en tant que maître. Une intervention manuelle a été nécessaire après la correction de l'isolement du réseau.
2	Le réseau isole le serveur primaire des autres serveurs (les serveurs de secours ont la même valeur pour l'emplacement mais le primaire avait une valeur différente pour l'emplacement dans la configuration repmgr)	repmgrd a lancé l'élection lorsque la vérification de l'état de la connexion principale a échoué sur tous les serveurs de secours. Mais, aucun nouveau maître n'a été élu car les serveurs de secours avaient un emplacement différent de celui du serveur principal. repmgrd est passé en mode de surveillance de dégradation. PostgreSQL s'exécutait sur tous les nœuds et il n'y avait qu'un seul maître dans le cluster.

Inférence

repmgr fournit plusieurs commandes pour configurer et surveiller la réplication PostgreSQL. Il est riche en fonctionnalités et facilite également le travail de l'administrateur de base de données (DBA). Cependant, il ne s'agit pas d'un outil de gestion de la haute disponibilité à part entière, car il ne gère pas les ressources. Une intervention manuelle est nécessaire pour s'assurer que la ressource est en bon état.

Ainsi, dans cet article, nous avons discuté des capacités et du fonctionnement de Replication Manager de 2ndQuadrant. Dans notre prochain article, nous aborderons les mêmes aspects de haute disponibilité avec Patroni by Zalando. Pour les utilisateurs qui cherchent à automatiser leur haute disponibilité dans le cloud, consultez nos solutions entièrement gérées PostgreSQL sur Azure et PostgreSQL sur AWS.