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.

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.

"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 ? ...).

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.

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.

C'est peut-être dans la page consacrée au fencing que ça aurait sa place donc.

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é.

Bien vu, je vais détailler un peu cette partie.

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.

À 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.

Bonjour,

Notez que je suis disposé à vous aider, mais disons que votre question sur le PGDATA m'a fait pensé que vous n'aviez pas lu la documentation. Plutôt que de longue phrases ici, autant profiter de la documentation que nous avons mis du temps à écrire

Pour le reste, si les pg_hba.conf présentés ici sont complets, il y a plusieurs erreurs. Pour commencer, les messages suivants de PostgreSQL indiquent qu'une connexion via un socket unix local est refusée car aucune ligne ne correspond dans le pg_hba:

J'imagine que ces connexions viennent de PAF...

Rajoutez donc en début de fichier la ligne suivante:

Reste que ça ne laisse pas beaucoup de place pour les connexions distantes d'une applications...

Ensuite, il semble que sur "pouj-pgsql-4", vous rejetiez les connexions de réplication non pas de "pouj-pgsql-4", mais de "pouj-pgsql-3"...

Bonjour,

Ce paramètre est mauvais: "clone-node-max=2 ". Vous ne pouvez pas avoir deux instances fait parti du même groupe de réplication sur le même nœud...

Pour le reste, isolez les lignes qui commencent par "pgsqlms" dans vos logs, ce sont tous les messages de l'agent PAF lui même. Vous y trouverez peut-être d'autres réponses.

Tiens, j'oubliais, vous avez aussi ce format de disponible:

psql "dbname=$database_name options=--search_path=pg_catalog" <<'EOQ'
...
EOQ

Ne pas avoir de fencing disponible et conserver stonith-enabled activé vous empêchera de démarrer quoi que ce soit dans votre cluster. Si vous voulez mettre temporairement le fencing de coté **le temps de réussir à démarrer vos instance PostgreSQL à travers Pacemaker**, il faut désactiver "stonith-enabled". Mais gardez bien à l'esprit que sans fencing, votre cluster (que ce soit avec PAF ou autre chose) finira par manger vos données.

Dans vos fichiers "pg_hba.conf", les lignes suivantes ne servent à rien:

1- il me semble que l'hyperviseur ne se connectera jamais à PostgreSQL (en tout cas je n'en vois pas l'intérêt)
2- lorsque vous spécifiez l'adresse d'une machine, le masque doit être "/32". Dans le cas présent, vos deux règles rejettent toute la plage 192.168.12.0.
3- pensez à conserver ces reject **AVANT** toute autre règle d'authentification

En revanche, j'imagine que ces mauvaises règles sont issues d'une confusion avec les règles de reject pour la réplication de chaque machine vers elle même, donc de leur IP locale (et non celle de l'hyperviseur donc)... Par exemple, dans le cas de la machine pouj-pgsql-4, les règles doivent être:

Les commandes virsh que je vous ai fourni sont à exécuter sur l'hyperviseur comme indiqué dans mon message précédent, pas depuis les VM (comme le montre votre prompt).

Bonjour,

Désolé pour l'attente, j'étais indisponible ces deux derniers jours.

Oui, ce template doit se trouver sur chaque nœud, c'est ce qui est d'ailleurs effectué dans le quick start de la documentation: http://dalibo.github.io/PAF/Quick_Start … esql-setup

Néanmoins, je vais prendre en compte cette question et l'indiquer plus clairement dans la documentation.

Ce fichier n'est qu'un template qui sera copié en tant que "recovery.conf" que si l'instance locale doit démarrer comme un standby. Dans un cluster, avec le jeu des bascules, des failover, etc, n'importe quel nœud doit pouvoir être un standby. Et surtout, le plus important, Pacemaker impose que toute ressource démarre comme un "slave" lors du "start", puis sera ensuite éventuellement promue en "master" avec un "promote". Ce qui explique la présence de ce fichier de template partout.

En théorie, cette IP ne sera placé que sur le nœud hébergeant l'instance master. Une fois que vous aurez réglé le problème associé à la configuration de vos instances PostgreSQL, nous pourrons vérifier le comportement de l'adresse IP.

Concernant la localisation du master, PAF la définie au premier démarrage du cluster en cherchant quelle est la seule instance éteinte alors qu'elle était en production (== pas un standby). Pour tous les futurs démarrages du cluster, les scores associés depuis aux instances sont ensuite utilisés (1001 pour le master donc).

Enfin, concernant vos log:
* je suis étonné qu'ils commencent tous par "ERROR: ... the instance has probably crashed", au démarrage du cluster, les instances doivent être au propre
* de même, je suis étonné que 1 minute après ce démarrage tumultueux de chaque instance, elles soient découvertes comme de nouveaux brutalement interrompues (d'autant plus si le fencing ne fonctionne pas).
* comment se fait-il qu'à 13:06:57, les DEUX instances entrent en streaming replication ("started streaming WAL from primary at 3F/39000000 on timeline 1") avec un master alors qu'elles sont toutes deux en standby ?

=> vérifiez bien les règles "reject" dans vos fichiers "pg_hba.conf"
=> supprimez l'adresse IP 192.168.12.15 AVANT le démarrage du cluster
=> arrêtez votre cluster, démarrez les instances PostgreSQL avec un master et un standby, assurez-vous que la réplication fonctionne bien, arrêtez toutes vos instances proprement, puis démarrez Pacemaker partout.

Concernant le fencing, il semble que votre configuration soit mauvaise:
* "ipaddr" doit contenir l'IP d' l'hyperviseur hébergeant la VM concernée
* concernant le login="root", vous devez indiquer ici l'utilisateur de connexion SSH vers l'hyperviseur. N'importe quel utilisateur système ayant le droit d'allumer/éteindre une VM à travers l'outil virsh fera l'affaire. La documentation de PAF donne un exemple avec root, mais dans mes maquette, j'utilise un autre utilisateur. Voir: http://dalibo.github.io/PAF/fencing.htm … -and-virsh
* vérifiez bien que "port" contient le nom de la VM tel que configuré coté hyperviseur (peut-être différent du hostname)

Je pense que la plupart des réponses à vos questions se trouvent dans la documentation de PAF. Je suis preneur si certaines choses ne vous y semble pas clair ou manquante. Merci !

Bonjour,

Première chose importante, une fois que vous aurez fait fonctionner l'ensemble, avant de faire vos tests de bascules, activez le fencing et le quorum :

<configuration>
    <crm_config>
      <cluster_property_set id="cib-bootstrap-options">
...
        <nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/>
        <nvpair id="cib-bootstrap-options-no-quorum-policy" name="no-quorum-policy" value="ignore"/>
      </cluster_property_set>
    </crm_config>

Ensuite, à propos du problème lui même, vu la situation, je dirais qu'il y a une erreur ou un oubli dans la configuration des instances PostgreSQL et qui est détecté par PAF dans la fonction "pgsql_validate_all" (dans le fichier "/usr/lib/ocf/resource.d/heartbeat/pgsqlms").

J'imagine que les log de Pacemaker doivent en faire état explicitement. Cherchez dans le fichier "/var/log/cluster/corosync.log" toutes les lignes débutant par "pgsqlms" autour de l'heure de ces erreurs 'Fri Jan 27 13:04:58 2017' (commande à adapter à votre environnement):

grep "^pgsqlms" /var/log/cluster/corosync.log

Le plus souvent, les erreurs concernent le template du recovery.conf, avec un mauvais "application_name" par exemple.

Rien à voir, mais validez bien aussi le contenu de votre pg_hba.conf afin de vous assurer que les règles "reject" y sont bien présentes et au bon endroit.

Hahaha, génial ! Veuillez m'excuser, cher Monsieur, pour ma formulation qui pouvait prêter, je l'admet, à confusion. Ce que je pensais en écrivant cette phrase était :

Bon, vous aurez réussi à me faire sourire malgré tout  :-)

Maintenant, j'arrête là, tout ça ne mène nulle part. Vous ne me semblez pas être dans vos meilleurs dispositions de toute façon et j'ai un métier aussi, figurez vous ;-)

Plutôt que de détourner le fond de la réponse de Tom Lane (PS: je n'ai pas l'intention d'en débattre avec vous), pourquoi ne pas avoir répondu à  sa demande de plan des autres moteurs publiquement ?

Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ? Avez vous une réponse à lui apporter ? Ouvrez vous un bug pour être constructif ou pour d'autres raisons ?

Ps: Pourquoi dieu est-il nécessaire de faire un screenshot pour récupérer un plan sous SQL Serveur ?!

Pour historique :
http://www.postgresql.org/message-id/28 … .pgh.pa.us
http://www.postgresql.org/message-id/53 … dalibo.com

Ahahah
Avec tant d'humour, vos cours en école d'ingé doivent être tellement amusants !

À propos des Hints, je vous propose d'aller en discuter avec les développeurs. Vous ne serez que le n-ième "DBA" Oracle qui sera venu les importuner à ce propos. Et pensez bien à les titiller avec les mêmes types de remarques que vous faites ici, histoire de pimenter un peu la discussion.

Moi, je vais m'installer confortablement devant ma mailing-list pgsql-hackers, prendre des popcorn et regarder si vous aurez des arguments différents de tous ces autres. À moins qu'ils vous balaient avec dédains en vous renvoyant à un simple lien [1] comme n'importe quel quidam...

En attendant, plutôt que de détailler et insister sur les (je cite) "grandes lacunes de PostgreSQL", vous pourriez plutôt titrer "Obstacles et différences à prévoir lors d'une migration vers PostgreSQL" et les façons de les contourner ou alors bien souvent...l'autre façon de faire dans le monde PostgreSQL.

Si je prends l'exemple des tablespaces, contrairement à Oracle, les développeurs de PostgreSQL ont décidés de ne pas ré-implémenter la roue. Il y a bien mieux à faire ailleurs. Ça vous demandera d'ôter vos œillères et aller voir coté système les solutions qui existent pour assurer le même type de souplesse...

Dommage, si vous passiez un quart de votre temps actuel accordé au pourissage pour écrire des choses constructives ou à participer de façon constructive à la communauté, on vous aurait peut-être cru quant à vos bons sentiments envers PostgreSQL.

[1] http://wiki.postgresql.org/wiki/Optimiz … Discussion