Vous n'êtes pas identifié(e).
Bonjour,
Après une analyse un peu plus profonde du code, j'ai commencé à avoir des doutes. Le callback "on_shutdown" permet surtout de relacher le leader lock plus rapidement pour laisser les secondaires se jeter dessus plus rapidement si certains d'entre eux ont bien reçu le "shutdown checkpoint" donc.
Sauf que si aucun standby n'a reçu ce checkpoint, ce callback n'effectue aucune attente. Aussi, il est de toute façon asynchrone et la méthode "demote()" poursuit son chemin quoiqu'il arrive, et fini par relâcher le lock sans se soucier de l'état des standby.
J'ai voulu tester ma compréhension avec un scénario très, très artificiel:
* créer une base pgbench suffisamment grosse
* ralentir si besoin la réplication avec une boucle de kill -STOP/kill -CONT sur le walreciver
* dans une séquence rapide:
- exécuter un "VACUUM FULL pgbench_accounts" sur le primaire
- commander un switchover immédiatement après le vacuum
- tuer (SIGKILL) immédiatement le walreceiver sur le secondaire pour simuler un incident
Et effectivement, avec ce scénario, l'ancien primaire ne réussi pas à raccrocher car le nouveau a créé une nouvelle timeline avant le "shutdown checkpoint".
Il est bon d'avoir conscience de cette race condition, mais elle reste malgré tout bien peu probable. De plus, il est relativement aisé de s'assurer que le switchover s'est déroulé correctement avec un simple "patronictl list" pendant quelques secondes.
Aussi, il est possible de se prémunir d'un tel incident avec une procédure un peu plus blindée:
* une interruption des écritures en production
* attendre que les instances soient toutes à flot
* déclencher le switchover
* valider le bon raccrochement de l'ancien primaire en tant que standby
- si ok: fin
- sinon: reconstruction de l'ancien primaire en tant que standby, par exemple
avec une restauration PITR optimisée
* relancer les écritures en production
Avec une telle procédure, il devient franchement improbable que l'ancien primaire ne puisse plus raccrocher suite à la bascule.
Bonjour Sébastien,
«En asynchrone la doc indique que la priorité est l'aspect "availability" au détriment des données. Donc dans ce mode patroni est autorisé à sacrifier des données»
Parles-tu de cette page de doc : https://patroni.readthedocs.io/en/lates … durability ?
Si c'est bien cela, elle décrit simplement le mode de réplication asynchrone de PgSQL qui autorise fatalement la perte de transaction en cas de bascule d'urgence. Ce n'est pas un choix de Patroni lui même.
Aussi, je discute ici de bascule planifiée, pas une bascule sur incident. Or, une bascule planifiée passe par l'appel à la méthode "demote" où il semble que le nécessaire soit fait pour que les standby attendent d'avoir reçu le "shutdown checkpoint" avant de se lancer dans la course au leader lock.
Ceci dit, je suis évidemment intéressé si tu as un bout de code laissant croire le contraire ! Je ne suis pas dev sur Patroni, je ne maîtrise pas le python et je peux totalement mésinterpréter ou oublier un bout de code...
Bonjour Sébastien,
Je crois bien que oui.
La fonction "demote" crée un callback "on_shutdown" faisant appel à la méthode "is_failover_possible" en positionnant le paramètre "cluster_lsn" pointant sur le shutdown checkpoint. Voir le code et le commentaire là : https://github.com/zalando/patroni/blob … a.py#L1234
On observe ensuite dans la méthode "is_failover_possible" que si le paramètre "cluster_lsn" est positionné et que la position du standby dans les WAL est inférieure, alors le standby est exclu à cause de son lag. Voir: https://github.com/zalando/patroni/blob … a.py#L1044
Ce code remonte au minimum à octobre 2021, mais je n'ai pas été cherché s'il existait ailleurs avant le commit d394b63c.
Salut,
Si le but est «de diminuer le risque de perte de données en cas de basculement contrôlé», alors la réplication asynchrone suffit largement.
Au moment où on arrête le primaire, ce dernier attend que les secondaires connectés aient bien récupéré l'ensemble des WAL avant de s'arrêter. Par contre, si la réplication est coupée pour une raison ou une autre (coupure réseau, arrêt du secondaire, ...), le primaire ne fait aucun effort pour s'assurer du statut des secondaires absents.
Donc, après avoir arrêté le primaire, il vous suffit de comparer l'adresse du dernier "shutdown checkpoint" du primaire avec ce qu'a reçu le secondaire. S'ils sont égaux, vous pouvez promouvoir le standby sans perte de données. Voir par exemple: https://public.dalibo.com/exports/forma … -promotion
Bonjour,
« combien de etcd je dois mettre ? »
Le nombre minimal de serveur etcd à installer est de 3, 7 au maximum d'après les recommandation du projet.
« si je met 1 etcd dans la zone A du primaire et 2 etcd dans la zone B du replicat. si la zone B tombe je me retrouve avec 1 seul etcd dans la zone A du primaire. »
Oui.
« Dans ce cas est-ce que fait patroni ? est-ce que le primaire continue de tourner ? »
Oui et Non.
Le cluster etcd ayant perdu le quorum dans la zone A, l'instance etcd passera en lecture seule, Patroni ne pourra plus y maintenir son leader lock, Patroni finira par exécuter un "demote" de votre primaire en secondaire.
Coté zone B, les instances etcd ayant toujours le quorum se débrouilleront si nécessaire entre elles et finiront par accepter les écritures, pour peu que le primaire etcd ne soit pas déjà dans cette zone B dès le départ. Quoiqu'il en soit, Patroni effectuera donc une bascule sur l'une des instances de la zone B.
Si vous souhaitez déployer un cluster étendu sur plusieurs zones, il vous faut 3 zones minimum afin d'établir en quorum entre ces zones.
Bonjour,
Plusieurs choses dans cette discussion.
1. Pour commencer, lors d'une bascule, comme vous le constatez, vous perdez votre connexion à l'ancienne instance primaire. Cette connexion est donc définitivement terminée, toute transaction en cours est perdue. Le seul élément qui permet à vos UPDATEs de reprendre, c'est simplement "psql" qui tente de se reconnecter automatiquement. Étant donné le paramètre "target_session_attrs" dans la chaine de connexion, psql retrouve le nouveau primaire.
2. Sébastien a raison. Patroni ne gère aucune notion de Quorum. Le Quorum est situé et géré au sein du cluster DCS utilisé (ici ETCd), pour ses propres besoins. Le seul moment où Patroni effectue un "demote" de son primaire local est lorsqu'il perd sa connexion au DCS, car il n'est plus capable de maintenir son leader lock, ni de déterminer le statut des autres nœuds.
3. Si vous voulez empêcher toute le écriture en cas de non réplication (un seul nœud actif dans le cluster, "last man standing"), votre seule solution (à ma connaissance) est d'activer la réplication synchrone coté PostgreSQL et d'activer le paramètre "synchronous_mode_strict" coté Patroni. Ce dernier demande à Patroni de ne pas repasser en mode asynchrone si le primaire n'a aucun standby en réplication. Attention, les conséquences de ce mode sont très impactantes en cas d'incident.
Une dernière solution est de passer sur un cluster Pacemaker, en shared disk sans réplication ou avec réplication grâce à l'agent PAF. Pacemaker par défaut "demote" toute ressource s'il ne reste qu'un seul nœud actif. Dans le premier cas, la solution requiers un architecture de stockage fiable et redondée, mais reste relativement simple à mettre en place. Dans le second cas, la mise en œuvre et administration demandent une bonne formation et du temps, Sébastien pourra confirmer 
.
Dans tous les cas, Patroni ou Pacemaker, la solution reste complexe et demande beaucoup de rigueur.
Cordialement,
Bonjour,
Dans le script, on utilise la variable avec :nom ou :'nom' ou :"nom" en fonction de la syntaxe voulue en sortie (sans guillemets, avec guillemets simple ou double).
Bonjour,
La réplication logique repose sur un slot de réplication, situé coté source (publisher) et qui permet d'y conserver les WAL tant qu'ils n'ont pas été décodés et envoyés vers la cible (subscriber) associée.
Donc, si le subscriber se déconnecte, le slot impose au publisher de conserver les WAL jusqu'au retour du subscriber afin qu'il rattrape son retard.
L'absence prolongée d'un subscriber induit donc un risque sur le publisher en cas de saturation de l'espace disque à cause de la rétention des WALs.
Bonjour,
Il y a eu des modification depuis la 10.
À minima, il vous manque de standby_mode dans votre config principale (eg. postgresql.conf). Le recovery.conf quand à lui a disparu.
Par défaut, pgcompacttable tente de limiter son impact sur le système en appelant "ionice -c 3" sur son backend. En théorie donc, le backend ne sera actif qu'en période de faible activité en IO.
C'est cependant à double tranchant. Cela peut tout à fait avoir le résultat opposé à ce qu'on cherche, notamment si le processus n'est pas schédulé alors qu'il a un lightweight lock, ou pire un spinlock.
Yep...ceci dit, j'ai du mal à estimer si ce type de situation puisse être très fréquente...
pg_compact n'est pas exposé à ce risque car lui permet de contrôler l'impact système non pas avec un outil externe (ici ionice) indépendant de sa volontée, mais en prenant lui même des pauses en fonction du paramétrage passé. Le rythme est donc contrôlé, mais forcé. Bref, dommage qu'il soit à l'abandon 
Salut,
pgcompacttable fait en sorte d'être lent, pour justement éviter de surcharger le système. L'avantage des UPDATE est que l'outil défragmente lentement la table. Un vacuum est exécuté régulièrement durant toute la période du traitement afin de libérer de l'espace de façon "incrémentale" dirons nous.
Par défaut, pgcompacttable tente de limiter son impact sur le système en appelant "ionice -c 3" sur son backend. En théorie donc, le backend ne sera actif qu'en période de faible activité en IO.
Coté index, il me semble que l'outil utilise un "create index concurrently"/"drop index concurrently" et gère les contraintes associées. Il va donc utiliser un verrou bloquant lors de la bascule d'index, mais l'opération est en théorie plus courte. reste que la remarque de rjuju est toujours valable à propos de leur performance... À mesurer, puis déterminer si le jeu en vaut la chandelle. Un traitement plus ou moins agressif et régulier pourrait aussi limiter le problème, par rapport à un traitement d'urgence après une longue période de non maintenance. En attendant, faute de mieux...
Enfin, il reste aussi pgcompact, qui utilise le même principe: https://github.com/grayhemp/pgtoolkit/b … /pgcompact
Mais ce dernier est abandonné et n'a plus bougé depuis longtemps. Néanmoins, si vous avez le temps d'y jeter un œil, n'hésitez pas à partager vos conclusions
++
Les instances ont été redémarrées avec pg_ctl -D et aucune autre option particulière. Il n'y a eu aucun problème pour le rejeu des WAL ou la réouverture de l'instance. Les seules erreurs dans les logs concernent les tentatives d'accès à la table en question - une fois la base déjà up - lorsque la requête tente de remonter la ligne défectueuse. Je n'ai aucun WAL perdu ou problème d'archivage (qui se fait sur un serveur tiers). Et ma "restore_command" est également bien configuré. Mon master et mes slaves ont bien retrouvés leurs petits. Consistent recovery state reached.
OK, la phase de rejeu semble donc s'être déroulée convenablement. Par acquis de conscience, pourriez-vous retrouver les messages avant et après la fin de la période de recovery sur l'instance principale ?
Je voulais dire que j'ai envisagé de restore un backup full sur un serveur tiers puis de lui faire rejouer les WAL un par un jusqu'à ce que ce fichier pg_clog manquant resurgisse pour ensuite aller le copier sur la vraie prod où il est marqué comme not found.
Ce n'est jamais trop une bonne idée de manipuler soit même ces fichiers à la main.
Mais ce fichier n'a peut-être pas lieu d'exister. Le problème peut venir d'une corruption dans les entêtes des lignes. Vous pouvez vérifier cela en comparant l'age de vos bases (datfrozenxid dans pg_database) avec le premier clog disponible (dans pg_xact ou pg_clog). Pensez bien que chaque transaction utilise 2 bits et que chaque fichier clog a une taille maximale de 256k, ce qui nous fait 1048576 de transaction par fichier clog (0x100000 en hexa, pratique). N'hésitez pas à coller ici ces informations.
Aussi, il pourrait être intéressant de récupérer les valeurs de xmin/xmax pour la ligne "corrompue" (mais accessible) sur le standby. Coté primaire, vous pouvez peut-être essayer de lire les entête de la ligne fautive grace à l'extension pageinspect et la fonction heap_page_items(). Voir pour un exemple de requête: https://www.postgresql.org/docs/current … spect.html
Comparer toutes ces valeurs entre elles (xmin/xmax, relfrozenxid, datfrozenxid, fichiers clog disponibles, denrière transaction connue, etc ) pourrait nous permettre de détecter où se trouve l'anomalie.
J'ai remarqué que les fichiers dans pg_clog s'incrémentent dans le temps, manque de bol, mon dernier backup (datant d'avant l'incident) ne possède déjà plus ce fichier avant même de commencer à rejouer les WAL. Cela semble donc rejoindre la piste d'un problème latent depuis un moment et effectivement peut-être pas lié à l'incident réseau.
Je doute qu'un problème réseau puisse corrompre une instance. Quel type de scénario imaginez vous ?
Du coup, la méthode du dumpall pour détecter la corruption est-elle suffisante ?
Faudrait-il (dans l'idéal) reboot l'ensemble de nos noeuds avant de refaire un dumpall pour mettre en évidence une corruption ?
Faire un script pour check chaque transaction vs le courant et son datfrozenxid me parait un peu compliqué (sauf si une extension fait déjà cela) ?Egalement, nous avions essayé de delete / update la ligne, mais peut-être que la forcer/marquer comme frozen pourrait suffir (si cela est possible manuellement) ?
J'insiste, avant de se poser ces questions et y trouver des réponses, il faut comprendre comment ces corruptions ont pu apparaître. Et au risque de paraître désagréable, rien pour le moment ne nous indique que la méthode employée pour démarrer les instances ait été fiable ou n'ait pas provoqué ces corruptions justement...
Comment les instances ont démarrés ? Avez vous des erreurs dans vos log ? Ont-elles bien démarré en mode recovery ? Ont-elles rejoués tous les WAL présents dans leur pg_wal ? Ceux-ci étaient ils complets ? ...
le lien que je fais est que les pg_clog contiennent les historiques de commits/transactions qui permet ensuite à la map de visibilité de savoir quelles sont les lignes à afficher ou non, or, s'il lui manque un fichier clog, il n'est plus capable d'assurer l'intégrité de sa map de visibilité (ou si j'ai mal compris, je veux bien qu'on me corrige svp smile )
les clog contiennent l'état des transactions et ont donc un impact sur la visibiblités des lignes en fonction que la transaction soit en cours, annulée ou validée. Mais quand vous parlez de visibility map, on parle d'une autre mécanique, dont la partie visible sont les fichiers "_vm" et les fonctions de l'extension pgvisibility que vous utilisez ici. Ces visibility map n'ont rien à voir avec les clog. Comme je l'écrivais, ce n'est qu'une optimisation du moteur lui permettant de déterminer rapidement si l'ensemble des lignes d'un bloc sont visibles, voir même freezées.
Faire appel à pg_truncate_visibility_map() ne pose aucun risque de corruption, il ne fait que remettre à zéro la visibility map associée aux fichiers de la table concernée, forçant le vacuum et vos requêtes à parcourir TOUS les blocs de la table et à valider la visibilité (dans les clog notamment) ligne à ligne.
J'aurais bien rejoué WAL par WAL depuis mon dernier backup jusqu'à l'apparition de ce fichier pour le réintégrer, mais avec 2T de wal par jour, ce n'est pas la 1ère option qui a été envisagée.
Je pense qu'on approche du problème. En théorie, votre instance aurait dû rejouer les WAL créés depuis son dernier checkpoint (et non depuis son dernier backup) automatiquement. Vous pouvez par ailleurs lui indiquer où trouver les WAL archivés grâce à l'"archive_command" si les WAL locaux sont considérés comme corrompus ou incomplets.
Le rejeu des WAL aurait dû remettre d'équerre et en cohérence, clog, VM et données. Ce qui n'est manifestement pas le cas ici. Je m'intérroge donc sur la méthode avec laquelle l'instance a été démarrée.
Si la rejeu des WAL "n'est pas la 1ère option qui a été envisagée", comment avez vous démarré vos instances ? Ces dernières ont-elles pu rejouer les WAL produits depuis leur dernier checkpoint valide connu ?
Bonjour,
Je ne suis pas certain de comprendre la relation que vous faites entre l'erreur suivante et la visilibty map:
ERROR: could not access status of transaction xxxxxx
DETAIL: Could not open file "pg_clog/yyyy": file not foundDe plus, la visibility map ne consigne pas les "pages obsolètes", mais les blocs où toutes les lignes sont visibles (voir freeze). Les espace disponibles dans les blocs sont consignés dans le FSM associé à la table.
Je suppose donc que vos corruptions ont affecté plusieurs mécaniques distinctes, et entre autre la cohérence entre certains fichiers de données et la VM associée.
Concernant les clog, une ligne fait manifestement référence à une transaction plus ancienne que l'actuel horizon connu. Cet horizon bouge entre autre lors des vacuum. Il se peut que l'action d'un vacuum qui aura supprimé le clog en question suite à son travail de freeze ait été perdu. Reste à savoir comment cela est possible. Corruption matériel ? fysnc=off ? perte d'un cache sans BBU au fond d'une baie SAN ?
Concernant la détection des corruptions des VM, votre requête semble suffisante. La correction quand à elle peut se faire avec un appel à pg_truncate_visibility_map() suivit d'un vacuum sur la table.
Cependant, si vous arrivez à trouver de telles corruptions, la première action consiste probablement à faire une sauvegarde physique de l'instance, puis identifier les composant matériel ou de configuration à l'origine de cette corruption.
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...
Bonjour,
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,
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 
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 (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
Bon courage !
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.
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
C'est moins complet, mais beaucoup plus simple.
++
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.