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.
]]>Le répertoire ./UPDATE correspond-il a un tablespace, et plus précisément un tablespace stocké DANS le répertoire PGDATA (ou PGDATA/pg_tblspc)? Si c'est le cas, ce n'est pas officiellement supporté et tout problème résultant est sous votre responsabilité.
]]>Oui je confirme les propos de ioguix : si vous vous lancez dans le HA, quelque soit la solution choisie il faut avoir dans la maison quelqu'un qui connait bien le sujet car ça peut rapidement devenir complexe.
Au passage pour vos tests sur Patroni : vous pouvez toujours mettre le cluster en mode maintenance (patronictl pause) : cela va empêcher les bascules et donc l'élection d'un nouveau leader si vous arrêtez volontairement le leader actuel.
]]>Mais plus globalement, je ne sais pas pourquoi vous voyez cette erreur ni même si elle a un rapport avec vos actions. Vous devez investiguer pour comprendre pourquoi le fichier est demandé, qui le demande, si c'est normal et vous pourrez alors résoudre (ou pas) le problème. Mais comme indiqué précédemment c'est impossible à dire avec les informations que vous avez fournies.
]]>La section bootstrap n'est utilisée qu'une fois : lors de la création initiale du cluster.
Ensuite ce sont les autres sections qui sont utilisées (dont celle qui s'appelle create_replica_method)
ok.
Merci de tes explications et de ton aide.
Bonne journée.
Katia
existe-t-il un moyen de superviser par nagios le hot_standby_delay sur un cluster postgresql a 4 noeuds tout en sachant que n'importe quel noeud peut devenir PRIMARY?
actuellement le check que j'ai ne marche que quand on met deux noeuds donc l'un est PRIMARY
Le problème c’est que je ne me vois pas modifier la surveillance à chaque fois que je switch
]]>j'avais attaché un Screenshot mais il n'est pas affiché en fait ...
J'ai un cluster actif / passif pour deux serveurs postgres.
Dans le dashboard j'ai ça en rouge :
user Application IP backend start transaction start state wait event
postgres walreceiver 179.111.26.194 2023-02-03 14:51:33 CET "RIEN : normal ?" Active WalSenderMain
Dans la table pg_stat_activity, cette ligne rouge me donne ça :
datid datname pid leader_pid usesysid usename application_name client_addr client_hostname client_port backend_start xact_start query_start state_change wait_event_type wait_event state backend_xid backend_xmin query_id query backend_type
NULL NULL 6204 NULL 10 postgres walreceiver 179.111.26.194 NULL 52882 2023-02-03 14:51:33.797658+01 NULL 2023-02-03 14:51:33.824599+01 2023-02-03 14:51:33.824617+01 Activity WalSenderMain active NULL NULL NULL START_REPLICATION 0/16000000 TIMELINE 1 walsender
Avec les Screenshots ça devrait être plus compréhensible ...
Je décline toute responsabilité d'avoir un postgres qui tourne sous Windows !
Le comportement n'est pas spécifique à patroni. Pour un switchover patroni devrait se contenter d'arrêter le serveur primaire avant d'intervertir les rôles, et lors d'un arrêt de postgres toute transaction en cours est annulée.
C'est au client de gérer l'interruption et repartir de 0.
]]>