Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je suis en cours d'installation d'un cluster PostgreSQL en streaming replication utilisant repmgr (j'ai testé auparavant avec Pacemaker et Corosync, mais je me retrouve régulièrement avec des désynchronisations de timelines en cas de bascule, et repmgr semble bien mieux les gérer).
La réplication en elle-même fonctionne donc sans souci, mais je cherche une solution pour prendre en charge la gestion d'une adresse IP virtuelle associée au nœud maître, ainsi que sa migration vers le serveur esclave en cas de bascule.
Une idée ?
Merci,
Thierry
Hors ligne
Bonjour,
ce genre de fonctionnalités passent par des outils type F5 ou HA proxy.
Il y a des exemples et des tutos un peu partout
Cordialement,
Sébastien.
Hors ligne
par exemple dans patroni, le HA proxy peut interroger l'api patroni avec un curl et le retour sera différent si c'est un leader ou un replica.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Il est actuellement peu recommandé de choisir repmgr. Patroni est plus fiable, plus rigoureux et bien plus populaire.
Les architectures Pacemaker en shared storage restent cependant les plus fiables et simples dans un environnement SAN (si correctement déployées), et ont l'avantage d'être supportées par Suse, RH, Canonical, etc.
L'utilisation de Pacemaker en shared nothing avec PAF s'est jusqu'à présent montrée fiable, mais nécessite une expertise certaine (et semble supportée par RHEL aussi).
Je suis en cours d'installation d'un cluster PostgreSQL en streaming replication utilisant repmgr (j'ai testé auparavant avec Pacemaker et Corosync, mais je me retrouve régulièrement avec des désynchronisations de timelines en cas de bascule, et repmgr semble bien mieux les gérer).
Auriez-vous plus d'information à propos de ces désynchronisations de timeline ? Un scenario de reproduction que je puisse tester ?
Bonne journée,
Hors ligne
Bonjour @ruizsebactien et @ioguix,
J'ai bien fait un test avec un HAProxy mais manifestement la connexion SSL ne passe pas ; a priori de ce que j'en ai compris c'est lié au mode de fonctionnement de la négociation SSL faite par PostgreSQL, et je n'ai pas trouvé de solution.
Le scénario de désynchronisation est assez basique : nous avons des actions de maintenance sur nos infrastructures qui peuvent générer des redémarrages du nœud maître ; s'il s'agit d'un simple redémarrage, l'opération se passe généralement sans problème ; par contre, en cas de redémarrages successifs, la désynchronisation peut se produire (sans être systématique).
Pour info, les serveurs sont installés sur une distribution Debian avec PostgreSQL 15. Je suis loin d'être un expert de Pacemaker et du module PAF, le problème peut parvenir de ma configuration qui n'est peut-être pas optimale ; je peux vous faire parvenir une copie de mes fichiers de configuration si cela peut aider au diagnostic...
Bien à vous,
Thierry
Hors ligne
Bonjour,
Si vous avez un peu de temps à perdre, je vous invite à étudier Patroni qui est bien plus simple et robuste à utiliser que les autres solutions
(qui sont certes très performantes mais beaucoup compliquées à maitriser).
Patroni est peut être votre solution y compris pour la partie SSL parfaitement gérée.
Oh ! et pour les considérations de maintenances, c'est pour cette raison principale que nous sommes venus à considérer Patroni :
la bascule entre les nœuds est simplicime.
Dernière modification par ruizsebastien (12/09/2024 09:01:45)
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Je suis d'accord avec Sébastien, étudiez Patroni, il est plus simple et facilite certaines maintenances en les intégrant...Mais vous aurez à administrer en plus un cluster etcd (ou autre DCS supporté).
Pour le reste, je ne comprends pas trop vos problèmes avec SSL ou de désynchronisation des timelines. Ceci dit, si vous avez des maintenances à effectuer, sur PostgreSQL, les serveurs, le réseau, la couche application, quelque soit la solution de HA choisie, il vous faut passer par elle pour mettre le cluster en mode maintenance ou par exemple redémarrer PostgreSQL...
Pour le reste, PAF jusqu'à présent s'est montré fiable et robuste. Et les bascules entre nœuds se font en une commande aussi... Mais oui, Pacemaker est le plus puissant, le plus robuste (bien configuré), mais nécessite forcément plus de formation. Mais je suis biaisé, on va pas se cacher hein 
Clairement, PAF est la solution idéale pour les équipes utilisant déjà Pacemaker dans leur murs. Patroni est plus simple à mettre en œuvre pour un DBA connaissant bien ses outils.
Hors ligne
Bonjour,
Pour ce qui est du SSL, le problème est tout simplement que le client n'arrive pas à ouvrir la connexion avec le serveur PostgreSQL lorsqu'il y a un HAProxy entre les deux. Je dois avouer que je n'ai pas eu le temps de creuser le sujet d'avantage, mais les quelques articles que j'ai trouvés sur le sujet avaient l'air de stipuler que c'était lié à la façon dont PostgreSQL gérait la négociation SSL qui n'était pas standard.
Pour ce qui est de Pacemaker et de PAF, je pense avoir suivi les recommandations et les supports que j'ai pu trouver mais j'ai pu faire une boulette, ça peut vite arriver ! Après il est vrai que ça fonctionne *globalement* plutôt bien malgré tout, mais j'essaierai de suivre vos conseils et de jeter un œil à Patroni !
Ça reste dommage que repmgr ne soit pas mieux supporté, ça avait l'air de bien fonctionner (en dehors de cette gestion de la VIP)...
Merci encore,
Thierry
Hors ligne
…j'ai pu faire une boulette, ça peut vite arriver
Tout à fait, c'est bien le problème avec Pacemaker et les configurations un peu évoluées: il vaut mieux être accompagné d'un expert ou avoir une expérience pré-existante. Si l'équipe n'a pas le temps de se former, il vaut mieux passer à Patroni. Il est tout aussi nécessaire de se former avec Patroni, mais celle-ci est probablement plus rapide et moins complexe.
Si néanmoins vous cherchez à y voir plus clair, voici un workshop en Français très complet sur Pacemaker et PAF: https://github.com/ClusterLabs/PAF/tree … orkshop/fr
Ça reste dommage que repmgr ne soit pas mieux supporté, ça avait l'air de bien fonctionner (en dehors de cette gestion de la VIP)...
Au contraire, tant mieux qu'il ne soit pas mieux supporté. Repmgr a posé de nombreux problèmes, dans de nombreux contextes différents. Stabiliser une architecture repmgr est possible, mais nécessite une vraie expertise et du développement spécifique pour contourner ses défauts et maîtriser ses instabilités ou manquements.
Hors ligne
Bonjour,
En ce qui concerne la gestion de la VIP avec repmgr, moi j'ai trouvé un script sur un internet que j'ai adapté à mon cas, qui vérifie le statut du nœud:
1. Soit le nœud est maître
2. Soit le nœud est slave
Mais il est possible d'ajouter une option qui vous configure la VIP si le neoud est master, sinon ne pas configurer la VIP.
Le script affiche son résultat au format HTML
J'ai même créer un socket réseau qui exécute mon script pour exposer le résultat sur un port TCP et un service systemd qui m'exécute cela.
Ca marche bien mais je n'ai pas ajouter l'option VIP car j'accède depuis un serveur HAproxy sur le port TCP que j'ai crée.
Hors ligne
Bonjour @migra,
Ce serait possible d'avoir ce script ?
Hors ligne
voici le script il doit être exécutable par le compte postgres
#!/bin/bash
#
# This script checks if a PostgreSQL server is healthy running on localhost. It will
# return:
# "HTTP/1.x 200 OKr" (if postgres is running smoothly)
# - OR -
# "HTTP/1.x 500 Internal Server Errorr" (else)
#
# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly
#
FORCE_FAIL="/dev/shm/proxyoff"
SLAVE_CHECK="SELECT pg_is_in_recovery()"
WRITABLE_CHECK="SHOW transaction_read_only"
return_ok()
{
echo -e "HTTP/1.1 200 OK\r\n"
echo -e "Content-Type: text/html\r\n"
if [ "$1x" == "masterx" ]; then
echo -e "Content-Length: 56\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"
elif [ "$1x" == "slavex" ]; then
echo -e "Content-Length: 55\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"
else
echo -e "Content-Length: 49\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"
fi
echo -e "\r\n"
exit 0
}
return_fail()
{
echo -e "HTTP/1.1 503 Service Unavailable\r\n"
echo -e "Content-Type: text/html\r\n"
echo -e "Content-Length: 48\r\n"
echo -e "\r\n"
echo -e "<html><body>PostgreSQL is *down*.Run script not running by $UID</body></html>\r\n"
echo -e "\r\n"
exit 1
}
if [ -f "$FORCE_FAIL" ]; then
return_fail;
fi
# check if in recovery mode (that means it is a 'slave')
SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
return_fail;
elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then
return_ok "slave"
fi
# check if writable (then we consider it as a 'master')
READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)
if [ $? -ne 0 ]; then
return_fail;
elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then
return_ok "master"
fi
return_ok "none";
Hors ligne
Bonjour,
…
J'ai même créer un socket réseau qui exécute mon script pour exposer le résultat sur un port TCP et un service systemd qui m'exécute cela.Ca marche bien mais je n'ai pas ajouter l'option VIP car j'accède depuis un serveur HAproxy sur le port TCP que j'ai crée.
Et dans ce cas, tu peux même t'épargner de retourner le résultat en HTTP/HTML et retourner du texte brut en utilisant "tcp-check" coté HAProxy.
Passer par HAProxy est ici plutôt recommandé, tellement la gestion d'une vIP depuis repmgr est complexe et dangereux… Enfin, globalement, je déconseille l'utilisation de repmgr.
Hors ligne
Je te remercie pour ton retour.
Effectivement tu as raison pour le format de retour du script.
J'utilise le tcp-check de haproxy pour rechercher le status du nœud disponible dans le output de mon script afin de pouvoir me connecter depuis l'adresse IP du serveur haproxy donc plus besoin de gérer la VIP. Mais la grande contrainte que j'ai :
1. une fois la bascule faite en cas d'incident, il faut rétablir le cluster manuellement.
2. l'autre remarque, la gestion des fichiers WAL parfois certains certains étaient illisible du coup postgres ne pouvaient pas restaurer la base base pour résoudre cela j'ai utilisé ses deux paramètres:
1. fsync
2. wal_sync_method
Ce qui force les données à être écrite sur le disque en cas d’écriture. Cela à réglé le problème. pensée-vous que cela est une bonne astuce?
Hors ligne
Bonjour,
Je ne suis pas certain de suivre votre cheminement pour passer de WAL illisibles à la modification des paramètres "fsync" ou "wal_sync_method". Il doit manquer pas mal de détails.
Aussi, le sujet dérive grandement de celui de cette discussion.
Hors ligne
Pages : 1
