Vous n'êtes pas identifié(e).
Vous pouvez sinon essayer https://github.com/opmdg/check_pgactivity, mais je ne sais pas si une sonde nagios sera compatible avec munin.
Elle ne le sera pas...en revanche, ça pourrait valoir le coup d'étudier si on peut le rendre compatible... et ce serait carrément classe 
bonjour,
Je ne sais pas quelle procédure vous suivez, mais je ne vois pas le lien entre votre service PostgreSQL non démarré et le fait de (probablement) le détruire en utilisant l'outil pg_resetxlog.
Oubliez cet outil pour le moment, faite comme si vous n'en avez jamais entendu parlé.
Donnez plus de détails si vous en avez.
Alors bon courage et bonne continuation pour votre migration de donnée trainvapeur !
Salut,
Il est aussi possible d'utiliser l'excellent pgTap pour effectuer ces tests là. Voir: http://pgtap.org/documentation.html
D'autant plus que si vous migrez une application, je suis certain que quelques tests de non régression écrits avec pgTap ne seront pas de trop 
++
Bonjour,
Les services "postgresql@..." sont déduits d'un template "/lib/systemd/system/postgresql@.service".
Si vous regardez le contenu du template, vous verrez:
* "ConditionPathExists=/etc/postgresql/%I/postgresql.conf": si le fichier de conf existe, le service existe
* "Before=postgresql.service": si le service "postgresql.service" est démarré, ces services doivent l'être en premier
Donc, si vous souhaitez désactiver tout postgresql au démarrage, il faut désactiver le service "postgresql.service".
Si vous ne souhaiter que désactiver une instance parmi d'autres, il faut éditer le fichier "/etc/postgresql/%I/main/start.conf" correspondant.
Si vous souhaitez vous débarrasser du service "postgresql@9.3-main.service", archivez le contenu de "/etc/postgresql/9.3" et potentiellement de ses fichiers de données.
Excellent, heureux que tout fonctionne bien. L'apprentissage de Pacemaker est un peu rude, mais ensuite, c'est juste plaisant effectivement
la promotion manuelle d'un slave juste avec une commande et en à peine 1 seconde et sans coupure de service, franchement tous les dba en rêvaient, PAF l'a fait ;-)
Rendons à César ce qui appartient à César. La promotion d'un standby en une commande, sans PAF et sans coupure, c'est un simple "pg_ctl promote"
En revanche, pour ce cas bien précis, si c'est Pacemaker/PAF qui est au commande, alors il faut demander à PAF de le faire pour vous, bien entendu, donc avec pcs.
Bonne continuation !
Bonsoir,
Oui, c'est bien ça, j'ai pas de quoi tester là, mais je dirais que ça y ressemble, il n'y a pas de piège. Penser à rajouter autant de master que de ressource du coup;
pcs resource create pgsqld1 [...]
pcs resource master pgsql1-ha pgsqld1 [...]
pcs resource create pgsqld2 [...]
pcs resource master pgsql2-ha pgsqld2 [...]
pcs resource create pgsqld3 [...]
pcs resource master pgsql3-ha pgsqld3 [...]Excellent !
Bonjour,
Les infos sur le socket dans postgresql.conf ne sont pas commentées (il s(agit du résultat d'un grep).
Je ne vois pas comment grep pourrait ajouter des '#' tout seul devant les lignes...Mais bon, de toute façon, les sockets sont aux bons endroits, donc ce n'est pas bien important.
Au niveau des sockets ils sont bien dans /tmp :
.s.PGSQL.5433.lock
.s.PGSQL.5433
Vous n'utilisez pas le port par défaut...et je ne vois pas ce port 5433 apparaître dans la définition de votre ressource dans pacemaker. Game over
Bonjour,
D'après les log, pgsqlms n'arrive pas à se connecter à l'instance (il utilise "pg_isready") et pourtant "pg_ctl" lui indique bien que l'instance est démarrée ("postmaster.pid" présent et correspond bien à un processus postgres).
Je pense donc que pgsqlms n'arrive simplement pas à se connecter aux instances. Soit car il tente de se connecter au mauvais endroit, soit à cause d'un firewall (impossible si via le socket).
Je constate que le bout de conf que vous présentez à propos du socket est commenté. Néanmoins, il se peut tout à faire le socket soit bien situé dans "/tmp" (emplacement par défaut utilisé par pgsqlms). Avez-vous bien vérifié que tout est OK de ce coté là ?
Notez que si pouj-pgsql-5 est déclaré comme slave, c'est simplement car il n'existe aucune possibilité de l'isoler. Le nœud est bien marqué UNCLEAN et pgsqld FAILED (car pgsqlms n'a probablement pas pu s'y connecter donc).
Bonjour,
Cette question est plus de l'ordre de Corosync/Pacemaker que de l'ordre de PAF qui n'est qu'un agent pour cette stack.
En tout état de cause, tout dépend du réseau entre les deux sites et de sa fiabilité. Il est recommandé d'avoir une latence inférieure à 5ms et un lien extrêmement fiable, comme pour un LAN au final. De même, comme nous parlons de HA, il est plus que recommandé que ce réseau soit redondé...ou que le fencing soit capable d'agir à distance malgré la perte du lien réseau.
Une autre solution est de se tourner vers un cluster étendu, mais il requiers plusieurs serveur de chaque coté du lien WAN. Voir: http://clusterlabs.org/doc/en-US/Pacema … 0093104976
Bonjour,
Et pourquoi pas une seule base, mais avec un schéma pas cabinet. C'est l'équivalent de votre dernière option, mais sans préfixer les tables. Chaque cabinet a ses propres tables, "isolées" dans un schéma propre avec au besoin ses droits particuliers.
Cette approche vous permettra par exemple d'intégrer les données de plusieurs cabinets à la fois dans la même requête, sans difficultés (pour des besoins de reporting par exemple).
Bonjour,
Pour commencer, je dirais tout simplement les chapitres I.2, I.3 et II.4->8 de la doc postgresql: https://www.postgresql.org/docs/current/static/
Bonjour,
De mon coté, ext4 ou xfs indifféremment, sur LVM.
Pas de soucis. Bonne vacances !
Et voilà donc une béta de sortie: https://github.com/dalibo/PAF/releases/tag/v2.2_beta1
Comme tu sembles être concerné par l'une des nouvelles fonctionnalité, ton retour sur tes tests serait la bienvenue !
Merci !
Non, désolé, je publierais une beta quand j'aurais eu le temps de m'occuper du packaging des pages de manuels (cf. https://github.com/dalibo/PAF/issues/88).
Sachant que les tests sur pg10 sont déjà pas mal avancés de leur coté de toute façon. Le patch devrait entrer très prochainement donc.
Note que le "gros" patch pg10 n'est pas encore mergé dans la branche maser de PAF, il est relativement fiable de se lancer sur la version de dev actuellement, d'autant plus si la fin de ton projet est prévu dans plusieurs semaines/mois, où PAF 2.2 sera probablement déjà publié.
puis-je créer plusieurs clusters (pcs cluster setup...) avec des noms différents, des VIP différentes et des ressources séparées et cela sur un même couple de serveurs master/slave ?
À ma connaissance, il n'est pas possible de créer plusieurs instances indépendantes de Pacemaker sur un même serveur. Mais je peux me tromper, je n'ai jamais essayé non plus.
Bonjour Sébastien,
PAF 2.1 ne supporte pas d'avoir plusieurs ressources dans le cluster utilisant le même agent.
Cela a néanmoins été corrigé dans le dépôt de PAF et sera donc publié avec la version 2.2 très prochainement avec au passage le support de pg10 (je lutte un peu sur l'installation des pages de manuels et ce sera publié ensuite).
La meilleure approche pour moi est donc de créer une ressource par instance, avec une IP secondaire par master qui se promène dans le cluster...le tout avec la prochaine version de PAF donc.
Ceci dit, il est relativement dangereux d'installer plusieurs instances dans un même cluster: si l'une a une défaillance nécessitant un, fencing du nœud, l'autre sera emporté avec...
Concernant la corruption, oui. Si une corruption silencieuse survient sur le maître, elle sera strictement copiée sur l'esclave. Comme le maître ne s'en rend pas compte, il ne peut pas l'empêcher. Et si le maître ne s'en rend pas compte, l'esclave ne le pourra pas plus, donc il ne pourra pas non plus l'en empêcher.
Je me permets d'apporter un peu de détail à cette phrase. Si la "corruption" est "logique", càd qu'il vient d'un bug applicatif, oui, elle sera répliquée sur le standby.
Si elle est matérielle néanmoins, comme par exemple au niveau disque ou mémoire, il y a peu de chance qu'elle ne soit pas détectée par le standby, la fiabilités des WAL (qui sont répliqués) reposant sur un contrôle CRC qui est vérifié à sa lecture.
1 - quel agent de fencing installer ?
Tout dépend du type d'architecture on utilise (serveurs physiques, vmware, etc...)
Dans la doc on utilise l'agent fence-agents-virsh. Dans mon cas (vmware) il fallait utiliser l'agent fence-agents-vmware-soap.
Pour savoir si l'agent est déjà installé sur le serveur (pcs doit être installé au préalable) :pcs stonith list
Si l'agent nécessaire n'est pas dans la liste, il faut l'installer.
Une petite liste de correspondance des agents à utiliser selon l'architecture cible, ce serait vraiment royal
Oui, effectivement, le fencing est souvent compliqué à mettre en œuvre la première fois quand on découvre le principe. J'imagine que ça aurait plus sa place dans la page de documentation concernant le fencing justement et qui est pointée dans les pages de "Quick Start": https://dalibo.github.io/PAF/fencing.html
D'ailleurs, si vous avez un bout de doc concernant le fencing avec vmWare, je suis preneur pour l'intégrer dans cette page.
2 - corosync.conf
Après l'installation de corsync, le processus refuse de se lancer car il ne trouve pas le fichier corosync.conf.
Il faut donc le créer vide :cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
Alors ça c'est bizarre. L'une des grandes force ce pcs/pcsd est justement de ne pas avoir à toucher à ce fichier une seule fois. Tout se fait directement en ligne de commande avec pcs.
Le fichier corosync.conf est normalement généré par la commande "pcs cluster setup [...]" indiquée dans le quick start.
3 - recovery.conf.pcmk :
il manque la commande "restore_command = 'xxxxxxxxx' "
"Normal". La page de quick start n'a pas vocation à détailler la configuration et mise en œuvre de la réplication PostgreSQL. D'autant que le log shipping n'est pas du tout obligatoire dans le cadre de la réplication. Le quick start étant un "pied à l'étrier", nous avons fait le choix de la simplicité et de nous en passer afin d'éviter que le quick start ne devienne un "long and laborious start"
Et puis le log shipping requiers le plus souvent plusieurs prises de décisions concernant l'architecture (pousser les WAL ? Les tirer ? montage NFS ? SSH ? ...).
4 - pg_hba.conf :
Je me suis fait avoir sur cette partie. Il faut ajouter les lignes de la doc avant les autres lignes déjà existantes.
Il faut bien comprendre que le pg_hba.conf "avant PAF" doit fonctionner correctement pour la réplication et les connections applicatives.
Évidemment ne pas oublier d'alimenter le .pgpass si on est en authentification md5 (par exemple).
La partie mise en place de la replication postgresql dans la doc peut porter à confusion.
Par exemple, ça ne marchera pas si on ne met que ces 3 lignes dans le pg_hba.conf :host replication postgres 192.168.122.50/32 reject
host replication postgres $(hostname -s) reject
host replication postgres 0.0.0.0/0 trustIl manque au minimum les connexions "local"
Le quick start part du fichier pg_hba.conf par défaut, possédant déjà les connexions locales. Les commandes indiquées ne font qu'ajouter à la fin les règles concernant la réplication.
Néanmoins, je retiens que le chapitre sur PostgreSQL est peut-être un peu trop expéditif (malgré l'avertissement en début de chapitre). Je vais voir à l'étoffer un peu en tenant compte de ces remarques.
5 - clef d'authentification pour corosync :
Je ne sais plus exactement pourquoi, mais à un moment donné j'ai eu une erreur et en lisant la doc officielle de corosync, j'ai vu qu'il fallait créer une clef pour que les processus distants puissent dialoguer.
Je ne sais pas si c'est réellement indispensable mais dans mon cas ça m'a débloqué.cd /etc/corosync
corosync-keygen
chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
+ copier la clef sur l'autre serveur dans /etc/corosync/
Ce n'est pas nécessaire. Toute cette partie corosync me semble bizarre étant donné que sous les EL7, dans 90% des cas, il n'est plus nécessaire d'y toucher comme je l'indiquais plus tôt.
Voir le quick start sous Debian 8 (où le corosync.conf n'est pas généré par l'outil client) pour un exemple de fichier corosync, sans clé d'authentification.
6 - STONITH resources :
Le point le plus compliqué à mettre en oeuvre car les paramètres ne sont pas très intuitifs.
Une petite explication de chaque paramètre aurait été un vrai plus (vous me direz : RTFM...)
Ce qui m'a aidé : lancer la commande de fencing directement en mode verbeux et avant de créer la ressource pour voir ce qui ne va pas.
Par exemple dans le cadre de vmware :fence_vmware_soap --action=status --ip=(ip de l'hyperviseur) --plug=(nom du serveur tel qu'il est vu par l'hyperviseur) --username=(user créer dans l'hyperviseur qui a les droits d'agir sur la vm) --password=(passwd de ce user) --ssl --ssl-insecure -v
(ssl-insecure : si on a des problème de certificat sur l'hyperviseur)Les paramètres de la commande de fencing correspondent à ceci dans la commande de création de la ressource stonith :
pcmk_host_list = hostname complet du serveur
ipaddr = --ip
port = --plug
login = --username
passwd = --password
action = --action
C'est peut-être dans la page consacrée au fencing que ça aurait sa place donc.
dans la création de la ressource que signifie INFINITY ?
RTFM ? 
Ce n'est pas la création de la ressource mais de la contrainte de positionnement. Avec une contrainte de location "avoids", plus le score est élevé, et plus la ressource évitera le nœud. Ici, "avoids srv1=INFINITY" signifie que la ressource ne doit jamais se trouver sur ce nœud.
Notez qu'il est possible d'inverser le résonnement en remplaçant "avoids" par "prefers". Auquel cas, plus le score est élevé, plus la ressource préférera démarrer sur le nœud indiqué.
7 - resource pgsqld :
Il faudrait décrire ce que signifie :master-max
master-node-max
clone-max
clone-node-max
notifyLa aussi je me suis fait avoir.
Bien vu, je vais détailler un peu cette partie.
Pour le reste, c'était clair.
Quelques commande qui pourrait aider à comprendre et débugger l'installation :
pcs status --full
crm_mon -Afr -1
corosync-cfgtool -s
pcs property show
pcs resource show --full
traces corosync dans /var/log/cluster/corosync.logEn tout cas merci encore pour votre aide et votre travail sur ce produit.
Merci à vous d'avoir prit le temps d'écrire ce long message de retour, bien détaillé et intéressant. Je ferais évoluer la doc quand j'aurais un peu de temps à y consacrer.
Je vais capitalisé sur tout ça et je vais ensuite vous faire un retour (constructif) sur tous les problèmes et les interrogations que j'ai eu par rapport à la doc (quick start for centos7).
Excellent. Nous essaierons de faire avancer la doc dans le bon sens !
Merci encore pour votre aide.
Je vous en prie.
J'espère que tous nos échanges pourront servir à d'autres.
C'est l'intérêt des forums publiques, j'espère aussi du coup !
Pourriez-vous modifier le sujet de la discussion avec un tag "[résolu]" ? Merci !
Je me demande par contre pourquoi le heartbeat est "stopped".
À noter que ce n'est pas un "heartbeat" qui est en stopped, mais un clone nommé "pgsqld" dans votre conf. Le reste de la ligne signifie que cette ressource est de type "OCF", distribué par "heartbeat" et dont le ressource agent s'appelle "pgsqlms", aussi indiqué sous la forme "ocf::heartbeat:pgsqlms" donc.
En fait je connais bien postgresql depuis plusieurs années et mes aventures avec PAF ont été tellement semées d'embuches et d’échecs que j'en suis venu à douter de mes propres connaissances :-(
La haute dispo étant un sujet complexe et semé d'embûches (en tout cas pour avoir quelque chose de correcte), nous avons prit le parti dans PAF d'être très rigoureux, stricte et de contrôler l'environnement au maximum . Malheureusement, avec Pacemaker, ça se traduit souvent par du fencing ou des ressources qui ne démarrent pas. Mais lui non plus n'a pas le choix. À partir du moment où l'on souhaite une prise de décision non humaine et ne pas avoir de split brain, il faut en arriver là...
Je me demande par contre pourquoi le heartbeat est "stopped".
Je ne vois que deux nœuds dans ce cluster. Or, vous avez configuré votre nombre d'instance possible à 3 ( "clone-max=3" ) et autorisé qu'une seule instance par nœud ( "clone-node-max=1" ), ce qui est normal pour ce dernier.
Du coup, Pacemaker prévoit 3 instances pgsql (appelés "clones") dans le cluster, mais ne peux démarrer la 3ème nulle part, faute de place. Si vous rajoutez un nœuds à votre cluster (avec une instance PostgreSQL prête à démarrer et entrer en réplication) Pacemaker y placera donc ce 3ème clone.
En attendant, si vous ne construisez qu'un cluster à deux nœuds, il suffit simplement de modifier "clone-max=2".