Forums PostgreSQL.fr

Je me permets de vous rediriger vers le chapitre concerné dans la documentation... : http://dalibo.github.io/PAF/configurati … parameters

Et plus globalement, pensez à revoir cette page en entier à propos des autres pré-requis ou configuration à respecter.

Encore une fois, si l'ensemble de la documentation n'est pas suffisante (les pages d'installation, configuration, fencing, les admin cookbook, les quick start), n'hésitez pas à l'étoffer ou à proposer des améliorations.

++

Bonjour,

Oui, d'autres l'ont fait, mais il faut utiliser l'agent de fencing "fence_vmware" dans ce cas et non "fence_virsh".

Bonjour,

Vous pouvez aussi initialiser le search_path directement à la connexion. Eg.:

$ psql <<'EOQ'                                     
SELECT current_setting($$search_path$$);
EOQ

 current_setting 
-----------------
 "$user",public
(1 row)

$ PGOPTIONS="--search_path=pg_catalog" psql <<'EOQ'
SELECT current_setting($$search_path$$);
EOQ

 current_setting 
-----------------
 pg_catalog
(1 row)

Non. Nous parlons ici de fencing. L'intérêt du fencing est de forcer l'arrêt (ou le reboot) de la machine sans lui demander son avis. une connexion locale à la VM en tant que root ne servira donc à rien. Ici, il faut se connecter à l'hyperviseur (192.168.12.34 ou 192.168.12.35 chez vous) pour y éteindre la VM désignée. Le compte "login=" à utiliser est donc un utilisateur système sur l'hyperviseur ayant les droits d'administration sur les VM (les commandes que je vous ai fourni la dernière fois).

Il faut mettre l'adresse IP de l'hyperviseur...et indiquer pour le paramètre "port=" le nom de la VM hébergée sur l'hyperviseur et qu'il doit donc éteindre.

Pas forcément, PostgreSQL fait une résolution de nom ET une résolution de nom inverse (IP -> nom) pour s'assurer que la connexion entrante correspond à la règle pg_hba (voir doc postgres). Néanmoins, j'imagine que ça devrait fonctionner désormais.
Mais sinon, comme je l'écrivais, positionnez les adresses IP des machines plutôt que leur nom dans le pg_hba.conf pour les reject. Dans le cadre de votre maquette ce sera déjà un bon point de départ pour valider l'ensemble.

Bonjour,

Concernant le fencing, de ce que je vois, vous autorisez l'utilisateur "postgres" à se connecter en SSH à vos hyperviseurs 192.168.12.34 et 192.168.12.35 pour y arrêter/démarrer vos instances qui y sont nommées POUJ-PGSQL-3 et POUJ-PGSQL-4, c'est bien ça ?

Faites le test manuellement, l'utilisateur "postgres" a-t-il le droit de se connecter en SSH sur ces hyperviseur avec le mot de passe indiqué ? Si oui, que retourne la commande "virsh list --all" ? Les commandes suivantes fonctionnent-elles ?

# démarrer la VM
virsh start POUJ-PGSQL-3

# interrompre la VM (ps: ne la "détruit" pas)
virsh destroy POUJ-PGSQL-3

Concernant votre configuration, j'ai trouvé une erreur bénigne dans les lignes suivantes:

pcs -f cluster1.xml resource master pgsql-ha pgsqld \
    master-max=1 master-node-max=1                     \
    clone-max=3 clone-node-max=1 notify=true

La paramètre "clone-max" doit être positionné à 2.

Assurez-vous que les noms de machine "pouj-pgsql-3" et "pouj-pgsql-4" que vous avez positionné dans le pg_hba.conf (sans le fqdn complet) sont bien résolus ainsi que leur reverse DNS. Sinon, positionnez les adresses IP des machines plutôt que leur nom dans le pg_hba.conf poru les reject.

Enfin, il semble que les erreurs aient eu lieues lors d'actions "stop" sur les deux instances. Pourriez-vous fournir les log de ce qui a pu se passer entre le démarrage du cluster et ce moment là ?

Ce n'est plus le cas avec les versions modernes de Corosync. Considérez la note à propos du quorum sur la page de documentation suivante: http://clusterlabs.org/doc/en-US/Pacema … lover.html

Cette note explique que la gestion du quorum est désormais possible dans un cluster à deux nœuds grâce à l'option "two_node" dans la configuration de Corosync. Ce paramètre active implicitement "wait_for_all".

Activer le quorum dans un cluster à deux nœuds est utile dans le scénario suivant par exemple:

  * démarrage des deux nœuds du cluster, le CRM démarre les instances PostgreSQL, fait une promotion, etc
  * après quelques temps, l'un des deux nœuds crash et se fait fencer
  * grâce au paramètre "two_node" le nœud encore en vie conserve le quorum et PostgreSQL peut continuer à vivre dessus
  * au redémarrage du second nœud, si ce dernier n'arrive pas à se joindre au reste du cluster (problème réseau ou autre), le paramètre "wait_for_all" l'empêche d'acquérir le quorum et il ne pourra démarrer aucune ressource.

Bonjour,

Comme l'écrivait Marc, la bascule auto est complexe à mettre en œuvre, d'autant plus pour un SGBD si on ne veut pas se retrouver dans une situation de split brain.

Le fait est que Pacemaker est une référence incontournable et qu'aucun autre projet sous Linux ne lui arrive à la cheville en terme de fonctionnalité. C'est exactement pour cette raison que PAF a été conçu comme une simple brique (ressource agent) de ce projet essentiel.

Pour rappel, jusqu'à présent, le fencing est la SEULE solution propre pour éviter les split brain, d'autant plus sur un cluster à deux nœud. Je ne vois aucune méthode de fencing dans repmgr ou dans pgpool. Ces deux projets laissent ce "détail" à la discrétion des administrateurs s'ils y pensent à travers des scripts maison à exécuter...

À propos d'avoir une IP secondaire qui se promène là où le maître se situe, là aussi repmgr laisse les administrateurs se débrouiller...C'est faisable, mais ça nécessite un peu d'huile de coude et au moins 2 scripts distincts (pour la bascule à chaud et en cas de redémarrage du serveur)

Coté pgpool, c'est pas beaucoup mieux. Ils ont **encore** ré-écrit la roue en intégrant un watchdog dans leur code. Ce dernier n'est évidement pas parfait et complet et a déjà un sacré historique en terme de bug. Un client m'a rapporté avoir abandonné le watchdog de pgpool car ce dernier provoquait des incidents sur le réseau local à cause de son activité ARP. Un autre à mis pgpool en haute disponibilité grâce à ... Pacemaker pour éviter qu'il soit un SPoF (ce dernier l'utilisait comme répartiteur de charge).

Donc oui, Pacemaker est complexe à comprendre et mettre en œuvre pour le nouveau venu, mais il y a quelques raison derrière ça. Et l'intérêt ensuite, c'est qu'il fait tout, vraiment TOUT, et le fait bien: gestion des ressources, failover, switchover, dépendances des ressources entre elles, fencing, watchdog, quorum, règles, etc. PAF n'est qu'une simple brique au dessus qui exploite au mieux ce que nous offre ce beau projet.

++

Oh, soit. Vous n'étiez pas obligé de savoir que pgsql-bugs est une liste de diffusion...
Ceci dit, notez que Tom Lane vous a répondu avec cette liste en copie et non en privé:

  http://www.postgresql.org/message-id/19 … .pgh.pa.us

Si si, mais sur la liste en directe. Donc pour information:

  http://www.postgresql.org/message-id/28 … .pgh.pa.us

Disons que face à votre non contribution, je me posais bien des questions. Maintenant, je comprends que vous ne suivez simplement pas la liste de discussion, et donc la discussion à propos de votre bug.

Quant à votre expérience, je ne vois pas tellement quoi en faire sans le contexte. "Comme par hasard", il y a 1000 façon de détruire ce retour d'expérience. Je ne m'y emploierais pas car vu le changement de ton que vous avez initié, je ne souhaite pas argumenter avec vous.

À propos de mon temps de travail...pareille, trop simple à détruire, trop bas, je vous laisse dans votre imaginaire.

Je vous rassure, c'est par pure ignorance de SQL Server, sinon, je n'aurais pas posé la question. Et oui, je suis curieux, que voulez vous.

Vous auriez pu proposer les deux représentations par soucis du détail. Ceci dit, ça ne fait pas de vous un crétin, peut-être en faite vous un peu trop non ?

Mh, votre choix. En attendant, le message est passé sur pgsql-bugs, donc si vous n'avez plus rien à y apporter hein...

J'imagine que ton trigger se déclenche avant la mise à jour (tout dépend de sa définition), donc si tu modifies les données de NEW, ce sont ces données qui seront in fine dans la table.

Ceci dit, on a tous (plus ou moins) été étudiant avant, avec le stress qui va avec et le manque de temps pour tout gérer. Mais ça n'empêche pas d'apprendre à lire une documentation en prenant son temps pour la comprendre pour éviter de perdre plus de temps ensuite à faire n'importe quoi...

Mes profs fouillaient internet pour comparer nos travaux avec de l'existant. Je te souhaite d'avoir des profs moins pointilleux, à la lecture de ce fil, à leur place je sortirais le colt.

PS: et on ne mord pas une main qui se tend vers toi et tente de t'aider en te pointant la bonne doc. Doc que tu n'avais probablement pas lue.

normalement, avec une fonction SRF, la syntaxe suivante retourne tout le résultat dans un seul champs effectivement:

  SELECT function (...)

Si vous voulez que chaque champs du type composite soit dans une colonne propre, utilisez la syntaxe suivante:

  SELECT (function (...)).*;

Soit, avec l'exemple de Marc:

  SELECT a.*, (b(test.a)).* from test;

Bonjour,

Il me semble que le problème original pourrait venir d'ailleurs: l'architecture elle même.

En effet, si vous utilisez une application PHP (avec de l'ajax ou non), il ne vous sera pas possible de créer et gérer des transactions à travers plusieurs appels coté serveur, que ce soit à avec modphp ou php-cgi.

Effectivement, dans le cas d'apache, entre 2 requêtes au serveur HTTP, même si vous conservez ouverte la connexion et la sessions entre votre httpd et PostgreSQL, rien ne dit qu'apache vous attribuera le même thread que pour votre requête HTTP précédente. La page suivante, issue de la documentation de PHP traite de ce sujet:

  http://fr2.php.net/manual/fr/features.p … ctions.php

Une solution à votre problème serait donc d'utiliser les transactions préparées. Voir: http://docs.postgresql.fr/9.0/sql-prepa … ction.html

Bonjour,

Il semble que le fichier que vous utploadez ne soit pas lui même en UTF8.

Vous auriez le même problème avec psql lui même. Il vous faut préciser au début de votre script l'encodage utilisé avec la requête "SET client_encoding TO 'iso8859-1';"

Exemple:

ioguix$ cat /tmp/test.sql
INSERT INTO test VALUES (3, 'fête');

ioguix$ psql pagila
pagila=> \i /tmp/test.sql 
psql:/tmp/test.sql:1: ERROR:  invalid byte sequence for encoding "UTF8": 0xea7465
ASTUCE : This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

pagila=> SET client_encoding TO 'iso8859-1';
SET

pagila=> \i /tmp/test.sql 
INSERT 0 1