PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Réplication » Promote d'un secondaire V12 très long » 16/06/2020 22:15:35

Bonjour,

Lors de la promotion, le standby va d'abord finir de rejouer tous les WAL disponibles localement ou via les archives (restore_command).

La promotion peut prendre plus ou moins de temps en fonction du retard de votre secondaire par rapport à la production, du nombre de WAL à restaurer, de la commande de restauration, etc...

#2 Re : Réplication » Patroni et etcd » 04/05/2020 12:16:04

Bonjour,

MAHE_Alain a écrit :

Au vue de la documentation, Il faut installer ETCD sur un serveur, et PostgreSQL et Patroni sur les deux nœuds du cluster.

Il faut installer Etcd (ou un des autres DCS supporté) sur trois serveurs (minimum) et non un seul. Etcd forme lui même un cluster dans son coin. Plus vous aurez de nœuds, plus il supporte de défaillance et reste accessible. Avec trois nœuds, le quorum étant de 2, il supporte la perte d'un seul des nœuds. Au delà, le cluster passe en mode dégradé.

Quand au couple Patroni/PostgreSQL, notez que vous n'êtes pas limité à deux nœuds.

Bonne journée,

#3 Re : Général » Haute disponibilité , quelle solution choisir ? » 07/04/2020 11:20:37

Salut,


notice: dev PAF et j'aime la HA


Les deux solutions viables actuelles sont Patroni et Pacemaker/PAF, pour une raison claire: ils font de la HA correctement et pas avec des bouts de scotch ou en laissant l'administrateur développer lui même les points critique de l'archi.


Repmgr ou pgPool ne supportent ni le fencing, ni le watchdog, ni de (vrai) quorum. Ils nécessitent de fournir des scripts où vous aurez à gérer ce type de notions vous même. Des notions dev et maintenues par des experts en HA depuis plus de dix ans dans Pacemaker. Vous n'obtiendrez jamais quelque chose de propre et fiable. Néanmoins, si vous avez précisément identifié les différents cas où l'outil n'est pas capable de gérer correctement une bascule, que vous acceptez ce risque et que vous avez bien tout documenté, alors pourquoi pas.


Concernant repmgr, le witness n'est pas un vrai qorum. Chaque nœud dans son coin décide de quand il faut faire une élection. Sur ce point, c'est déjà un peu risqué. Ensuite, si il "voit" le witness, il le compte d'office pour une voix dans son calcul. Le witness est complètement passif. On pourrait le comparer au qdevice dans une stack Pacemaker, sauf que le qdevice prend réellement part à l'élection et décide à qui il donne sa voix en fonction de l'algo choisi. Mais bon, contrairement à pgPool, on peut éventuellement construire une stack repmgr convenable avec beaucoup d'investissement et une surcouche de développement importante pour fiabiliser la chose au maximum. Reste ensuite à documenter ce qui ne va pas, comme d'hab.


Patroni ne supporte pas le fencing. Mais lui, il a un vrai quorum grâce au cluster DCS (à monter de préférence *à part*) et surtout supporte le watchdog. Une stack Patroni saine active le watchdog. Il y a deux/trois petits détails (peu significatifs) dans Patroni qui me font malgré tout préférer Pacemaker. En outre, la gestion d'une vIP pour atteindre le primaire est plus complexe qu'il n'y parait. Du coup, utilisez HAProxy, mais ça rajoute un service à gérer dans votre stack...Ou collez l'intelligence dans la couche applicative si vous le pouvez, mais votre archi devient invasive coté applicatif. Nous avons creusé vip-manager ces derniers temps, plutôt une bonne idée, mais le diable se cache dans les détails. Bref, Ici aussi, tant qu'on a conscience des failles possibles de son archi et que c'est documenté, on peut dormir sur ses deux oreilles. Moi, je dors mieux en sachant Patroni/DCS aux manettes qu'avec l'un des deux précédents. Surtout quand un watchdog est prêt à te coller un reset derrière les oreilles si ton process n'est pas obéissant big_smile


Enfin, Pacemaker supporte le fencing, le quorum, le watchdog, le qdevice ou encore le storage base death (sbd). Avec tout ça, vous pouvez construire tout pleins d'archis fiables différentes et rigolotes (j'en fait trop ?) en fonction de vos moyens, matériel dispo, équipes concernées, etc:


* un cluster 2 nœuds FIABLE avec quorum (un peu spécial) et fencing quand on est serré en nombre de machine
* l'équivalent de Patroni avec 2+ nœuds + un qdevice (capable de participer à plusieurs clusters comme un cluster DCS)
* un cluster shared storage, simple et efficace si bien construit
* un cluster shared nothing avec PAF, pas très compliqué à monter et efficace si bien construit
* du poison pill pour le fencing si vous avez du stockage accessible depuis tous les nœuds (sbd)
* ...


Mais c'est bien là le problème de Pacemaker. Il propose de gérer la HA de tout type de services, le plus correctement possible. La HA et toutes ces notions sont complexes, donc Pacemaker est complexe et on se perd dans la jungle des notions et possibilités. Mais une fois l'archi construite et comprise, c'est que du bonheur. En échange:


* gérer une vIP avec Pacemaker, c'est 4 lignes de **définition** (https://clusterlabs.github.io/PAF/Quick … -resources). Nous n'avons toujours pas trouver comment faire fiable avec les autres solutions.
* une bascule de rôle se fait en une commande, sans redémarrage des standby
* pas de split brain possible
* un projet *activement* développé par RedHat, Suse, Linbit et hastexo
* du support professionnel coté système (RH et Suse entre autre)
* paquets dispos et à jour sur toutes les distro Linux de bon goût (utilisez pcs!)
* intégrer HAProxy au dessus de votre stack Pacemaker (inutile de l'y intégrer), c'est aussi complexe qu'avec Patroni. Pas plus pas moins. Bienvenue la répartition de charge


Bref, je suis biaisé, c'est évident. Plus je creuse Pacemaker, plus je découvre sa souplesse et sa robustesse. Sans parler de sa petite communauté bienveillante et accueillante. On peut éventuellement lui reprocher de ne pas avoir assez de documentation, mais nous avons tenté d'y répondre un peu dans la doc PAF...et nous devrions encore ajouter des pages de doc.


Concernant Patroni, il est simple et fiable et je l'aime aussi pour ça. Mais pour être juste dans la comparaison, il faut aussi compter la montée en compétence sur le DCS choisi (mais parfois déjà présent dans le réseau) et l'ajout au dessus d'autres briques (eg. HAProxy, confd). Reste que se prendre des backtrace python sur de la prod (coté cli ou daemon) ça peut parfois effrayer un peu smile (rare hein, mais par exemple: https://github.com/zalando/patroni/issues/1418)


Quelque soit l'outil choisi, vous ne devez pas faire l'économie de tests poussés, de torture de votre cluster, de tout documenter, d'écrire **toutes** les procédures, de penser à vos backups, de prévenir l'équipe réseau, l'équipe SAN, les dev ou devops. Bref, préparez-vous à l'imprévisible smile


Bon courage !

#4 Re : Général » Fichiers tmp.QHoZCixFte (tmp.zorglub) créées par Postgrès dans /tmp » 17/02/2020 19:06:08

Bonjour,

Ce n'est pas forcément l'instance postgres qui a créé ces fichiers, mais une autre commande lancée par l'utilisateur postgres.

Il n'est pas rare qu'un fichier temporaire soit créé, ouvert, puis détruit par le processus qui l'a créé et qui continue à l'utiliser, bien que le fichier soit supprimé. La commande "lsof|grep (deleted)" (en tant que root) devrait vous les montrer si certains existent au moment de la commande.

#5 Re : Réplication » Slony en 2020 » 14/02/2020 19:04:45

Salut,

Je l'utilise principalement pour les mises à jour majeure.

Dans les autres cas, je lui préfère la répli logique quand c'est possible...sauf que je n'ai pas eu d'autres cas depuis que la répli logique existe smile

C'est moins complet, mais beaucoup plus simple.

++

#6 Re : Réplication » Plugin Munin log streaming réplication » 09/01/2020 19:32:53

rjuju a écrit :

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 smile

#7 Re : pgAdmin4 » problème de connexion au serveur postgresql » 23/05/2018 12:40:29

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.

#8 Re : Général » savoir si une table / colonne existe » 24/04/2018 20:59:40

Alors bon courage et bonne continuation pour votre migration de donnée trainvapeur ! smile

#9 Re : Général » savoir si une table / colonne existe » 22/04/2018 14:13:09

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 wink

++

#10 Re : Installation » Linux: Systemd plusieurs services Postgresql ? » 31/10/2017 11:19:12

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.

#11 Re : Réplication » [RESOLU] [PAF v2.2.0] Test avec plusieurs instances dans le cluster » 26/09/2017 19:43:38

Excellent, heureux que tout fonctionne bien. L'apprentissage de Pacemaker est un peu rude, mais ensuite, c'est juste plaisant effectivement smile

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" smile

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 !

#12 Re : Réplication » [RESOLU] [PAF v2.2.0] Test avec plusieurs instances dans le cluster » 25/09/2017 21:45:21

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 [...]

#14 Re : Réplication » [RESOLU] [PAF v2.2.0] instance "pgsqld" is not listening » 25/09/2017 14:44:53

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 smile

#15 Re : Réplication » [RESOLU] [PAF v2.2.0] instance "pgsqld" is not listening » 24/09/2017 14:25:09

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

#16 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 18/09/2017 18:46:17

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

#17 Re : Général » Architecture base de données. » 31/08/2017 10:46:27

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

Voir: https://www.postgresql.org/docs/current … hemas.html

#18 Re : Général » Débutante postgre » 04/08/2017 10:02:09

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/

#19 Re : Installation » [RÉSOLU] Système de fichier préconisé. » 07/07/2017 12:55:05

Bonjour,

De mon coté, ext4 ou xfs indifféremment, sur LVM.

#21 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 27/06/2017 14:30:23

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 !

#22 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 13/06/2017 17:30:26

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.

#23 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 13/06/2017 16:03:49

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

#24 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 13/06/2017 16:02:19

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.

#25 Re : Réplication » [PAF] cluster HA et plusieurs instances par serveur » 13/06/2017 15:37:49

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

Pied de page des forums

Propulsé par FluxBB