Vous n'êtes pas identifié(e).
bonjour,
pour me connecté à partir de postgresql14 sur mes serveurs en cluster j'utilise la commande suivante pour etre sur de bien me connecté sur le primaire:
psql postgresql://postgres@serveur1:Port,serveur2:port,serveur3:port/postgres?target_session_attrs=read-write
hors si je fait des update dans ma base et le leader bascule je me retrouve en read-only et donc obligé de relancer une session...
message d'erreur dans l application:
Caused by: org.postgresql.util.PSQLException: ERROR: cannot execute UPDATE in a read-only transaction
ma question: est ce que vous connaissez un attribu à rajouter à ma connexion psql pour ne pas passer en mode read-only sur ma session si je change de leader et que je puisse continuer à faire des transactions de type DML?
Merci d'avance pour vos réponses.
Katia
Hors ligne
Ça n'existe pas et ça ne peut pas exister. L'option que vous donnez est utilisée uniquement à la connexion. Elle vous assure que votre connexion se fait directement sur le bon serveur en lecture/écriture. Si jamais ce serveur change de rôle, la connexion étant déjà établie, vous restez sur le même serveur. Il faudrait que l'outil (psql ici) ait une option de vérification du type de connexion qui le contraigne à vérifier régulièrement l'état du serveur. Cette option n'existe pas (mais pourrait être ajoutée dans une prochaine version, même si ça me paraît peu probable).
Guillaume.
Hors ligne
bon je m en doutais un peu 
merci de votre réponse et bonne journée.
Hors ligne
Bonjour,
ça m'étonne un peu que votre connexion persiste ?
En effet lors d'une bascule avec patroni, les noeuds sont redémarrés et une nouvelle timeline est créée, donc votre connexion devrait être perdue et votre update rollbacké.
quelqu'un pour infirmer ou confirmer ?
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Ma connexion persiste car je ne fais qu'un changement de leader ou un arret du leader en cours et non pas un arret complet du cluster.
Vu que les 2 autres membres sont en standby lors de l 'arrêt du leader , un des 2 autres membres passe leader.
Cordialement
Katia
Hors ligne
re ...
Un collègue a trouvé cette commande :
psql postgresql://postgres@serveur1:Port,serveur2:port,serveur3:port/postgres?target_session_attrs=primary hostRecheckSeconds=2
et quand on arrete le leader et laissons les 2 autre membre du cluster démarré on peut continuer à faire des insertion de données ....
Par contre comportement surprenant de Patroni : quand on a 2 membres d'arrêté nous ne sommes plus en read-only mais toujours en read-write et donc on peut continuer à insérer des données comme si nous étions sur une base postgresql classique ....
surprenant .
Cordialement
Katia
Hors ligne
ah ok , vous ne faites pas un switchover mais un stop du service patroni du leader seulement.
Par contre pourquoi vous faites comme ça ?
Car ça casse le principe du HA patroni (toujours 3 noeuds en ligne dans votre cas avec bascule des rôles de chacun)
Dernière modification par ruizsebastien (30/08/2023 15:47:10)
Cordialement,
Sébastien.
Hors ligne
Le moe applicatif fait des tests car son application fait des update en continue ... donc il veut voir jusqu ou il peut inséré ....
Il passe d'une configuration postgresql/ safekit à postgresql/Patroni.
Cordialement
Katia
Hors ligne
bonjour,
j'ai toujours mon soucis .... si j’arrête 2 membres de mon cluster ( simulation de perte de 2 site) ma conexion ne passe pas en read only mais reste bien en read-write ....
ma chaine de connection:
psql postgresql://postgres@serveur1:Port,serveur2:port,serveur3:port/postgres?target_session_attrs=read-write
j'ai juste un message me disant une erreur de connexion mais je peux continuer à faire des insert ...
--------------------------------------------------------
p03=> insert into depart values ('10','interne');
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
p03=> insert into depart values ('10','interne');
INSERT 0 1
---------------------
Normalement j'aurai du passer en read only.... voyez vous ce que je dois faire ou rajouter dans ma chaine de connexion pour etre sur de pas resté en read-write ?
Merci d'avance de votre réponse.
Katia
Hors ligne
Bonjour,
ça me semble normal puisque dans votre chaine de connection il y a "target_session_attrs=read-write"
https://docs.postgresql.fr/14/libpq-connect.html
target_session_attrs
Cette option détermine si la session doit avoir certaines propriétés pour être acceptable. C'est typiquement utilisé en combinaison avec plusieurs noms d'hôte pour sélectionner la première alternative acceptable parmi différents hôtes. Il existe six modes :
any (default)
toute connexion réussie est acceptable
read-writela session doit accepter les transactions en lecture/écriture par défaut (c'est-à-dire que le serveur ne doit pas être en mode hot standby et le paramètre default_transaction_read_only doit être à off)
read-onlyla session ne doit pas accepter les transactions en lecture/écriture par défaut (l'inverse)
primaryle serveur ne doit pas être en mode hot standby
standbyle serveur doit être en mode hot standby
prefer-standbyessaie tout d'abord de trouver un serveur secondaire, mais aucun des hôtes listés n'est un serveur secondaire, alors tente de nouveau dans le mode any
Cordialement,
Sébastien.
Hors ligne
Bonjour Sébastien,
Merci de ta réponse .
Si je mets standby ou prefer-standby je peux pas faire d'insert car je dois etre sur le primaire pour cela ... meme si j'ai mon cluster complètement démarrer .
Si je mets any c'est comme read-write ou primary vu que ma connexion va d office sur le primaire .. si j'arrete les 2 standby ( simulation de perte de 2 sites) je peux toujours ecrire à travers ma session active ....
Donc il faut peu etre que je met autre chose que target_session_attrs dans ma ligne de commande mais quoi .... je seche ..... 
Cordialement
Katia
Hors ligne
Je ne suis pas sûr de comprendre ce que vous cherchez à faire exactement.
Dans votre premier message vous disiez vouloir rester sur une connexion en écriture en cas d'interruption de la connexion, et maintenant vous dites vouloir l'inverse ?
Julien.
https://rjuju.github.io/
Hors ligne
bonjour Julien,
alors oui si mon leader switch et que j'ai encore 2 ou 3 membres je veux pas perdre ma connexion en cours et continué à faire des insertion .... en mettant primary à la place read-write ca fonctionne. j'ai juste 1 mezssage d'erreur et je peux continué à faire des insert/update etc....
Mais si je n'ai qu'un seul membre je veux passé en read-only .... et donc perdre ma connexion à la base ....
la si je n'ai qu'un membre mon patroni reste en mode leadrt ce qui n'est pas normal.
----------------------
root@div6sv000198:/var/log/patroni# patronictl -c /etc/patroni/patroni.yml topology
+ Cluster: clusterp03 (7216717851421801304) --+---------+-----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+--------------+---------------------+--------+---------+-----+-----------+
| p03-cluster1 | 172.16.171.152:5434 | Leader | running | 293 | |
+--------------+---------------------+--------+---------+-----+-----------+
et donc ma connexion reste et je peux faire des insertions ....
Cordialement
Katia
Hors ligne
et bien oui c'est normal que le leader soit présent sur le dernier noeud disponible.
C'est bien le but de patroni, heureusement ;-)
Cordialement,
Sébastien.
Hors ligne
Si je comprends votre problème n'a rien à avoir avec psql ni avec target_session_attrs, mais avec le fait que votre cluster "reste en vie" (du moins conserve le noeud restant en tant que leader) après la perte de 2 noeuds ?
Difficile de répondre sans connaître la configuration ni ce que vous faites exactement. J'imagine que si par exemple vous vous contentez d'arrêter postgres mais que patroni reste démarré il n'y a aucun problème pour conserver le dernier noeud en tant que leader car il n'y a pas de possibilité de split brain.
Julien.
https://rjuju.github.io/
Hors ligne
Je me demande même si vous n'auriez pas intérêt à sortir de patroni pour avoir un système en streaming sans couche HA.
Ainsi vous pourriez "maitriser"/"décider" qui est le leader
Cordialement,
Sébastien.
Hors ligne
Sébastien,
Normalement patroni devrai se mettre en read-only car il n y a qu'un noeud de démarrer ? le corrum n'est plus bon vu que c'est normalement n+1 et la je n'ai que 1 serveur sur 3 de démarrer.
Cela ne viendrai pas d'un pb entre etcd et Patroni qui concidere quand meme les 3 membres present bien que 2 sont arreté?
rjuju:
Ma conf:
-----------------------------
patroni.yml
------------------------------------
scope: clusterp03
namespace: /service/ # valeur par défaut
name: membre2-p03
restapi:
listen: IP_PATRONI:8008
connect_address: IP_PATRONI:8008
log:
level: INFO
dir: /var/log/patroni/
etcd:
hosts:
- IP_ETCD1:2379
- IP_ETCD2:2379
- IP_ETCD3:2379
username: root
password: Supp0rt
protocol: http
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
use_slots: true
parameters:
archive_command: 'cp %p /bases/pgsql/14/var/journaux/%f'
archive_mode: true
archive_timeout: 1800
effective_cache_size: 1536MB
hot_standby: true
logging_collector: true
log_directory: /bases/pgsql/14/var/log/
log_file_mode: 0640
log_filename: 'postgresql-%d.log'
log_truncate_on_rotation: true
log_rotation_age: 1440
log_rotation_size: 0
log_checkpoints: true
log_connections: true
log_disconnections: true
log_error_verbosity: verbose
log_hostname: true
log_line_prefix: '%t [%p]: [%l-1] '
log_lock_waits: true
log_temp_files: 0
log_timezone: 'Europe/Paris'
max_connections: 100
restore_command: 'cp /bases/pgsql/14/var/journaux/%f %p'
shared_buffers: 512MB
wal_level: replica
work_mem: 2MB
dynamic_shared_memory_type: posix
max_worker_processes: 1
max_parallel_workers: 1
hot_standby: true
max_wal_senders: 10
max_replication_slots: 5
initdb:
- encoding: UTF8
- data-checksums
pg_hba:
- host all all all scram-sha-256
- host replication replication all scram-sha-256
- local all postgres trust
users:
dba:
password: dba_password
options:
- createrole
- createdb
admin:
password: admin
options:
- createrole
- createdb
commvault:
password: hotbackup
postgresql:
listen: "*:5434"
connect_address: IP_PATRONI:5434
data_dir: /bases/pgsql/14/data/clusterp03
bin_dir: /usr/pgsql-14/bin
authentication:
replication:
username: replication
password: PWD_REPLICATION
superuser:
username: postgres
password: PWD_POSTGRES
rewind:
username: rewinder
password: PWD_REWINDER
parameters:
unix_socket_directories: '/var/run/postgresql'
basebackup:
max-rate: "100M"
checkpoint: "fast"
watchdog:
mode: automatic
device: /dev/watchdog
safety_margin: 5
tags:
nofailover: false
noloadbalance: false
clonefrom: false
nosync: false
----------------------------------
etcd.conf:
-----------------------------
ETCD_DATA_DIR="/logi/etcd/"
ETCD_NAME="etcd-1"
ETCD_LISTEN_PEER_URLS="http://IP-ETCD1:2380"
ETCD_LISTEN_CLIENT_URLS="http://IP_ETCD1:2379"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://IP_ETCD1:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://IP_ETCD1:2379,http://IP_ETCD2:2379,http://IP_ETCD3:2379"
ETCD_INITIAL_CLUSTER="etcd-1=http://IP_ETCD1:2380,etcd-2=http://IP_ETCD2:2380,etcd-3=http://IP_ETCD3:2380"
ETCD_INITIAL_CLUSTER_TOKEN="ETCD-PreProd"
ETCD_INITIAL_CLUSTER_STATE="new"
--------------------------------------------------------------------------
ce que je fais:
je démarre les 3 membres patroni depuis les service (systemctl start patroni.service) par une connexion putty sur chaque serveur.
je me connecte à l'utilisateur postgresql depuis le membre1
je lance la commande :
psql postgresql://postgres@serveur1:Port,serveur2:port,serveur3:port/postgres?target_session_attrs=read-write
je fais des insert
j'arrete 2 des membres du cluster à partir d'autre fenetre putty.
sur ma session lancé precedemment je continue à faire des insert.
Cela passe ....
-----------------------------
voila voila tout le detail ....
Cordialement
KAtia
Hors ligne
en fait le seul cas (à ma connaissance) où patroni est en read-only de son propre fait (c'est à dire quand il y a un problème) c'est quand les etcd ne sont plus disponibles.
On peut très bien avoir un seul noeud patroni en ligne et donc en leader.
C'est dangereux mais ça marche.
Avec mes maigres connaissances, je pense qu'avoir un seul noeud n'a plus de sens au niveau quorum, car à quoi sert le quorum sinon à provoquer une élection avec choix majoritaire ?
Et quand on est plus qu'un dans le quorum, l'élection est vite vue.
Cordialement,
Sébastien.
Hors ligne
Perso je pense que quand il est tout seul cela reviens à dire que postgresql se retrouve en mode standolone ... Il faut juste faire attention de pas planter ce leader ou si il s’arrête de le redemarrer en 1er pour ne pas perdre ce qu'on a rajouté comme donnée dedans ....
La surveillance du cluster devient primordial.
Le MOE applicatif est en train de tester les limites de patroni pour voir si il a des régressions par rapport à son architecture precedente qui etait du safekit/postgresql loadbalancé à travers une vip .... donc il test tout les cas de figure possible.
Merci de votre implication et vos réponses.
Bonne fin de journée
Katia
Hors ligne
et puis etcd ne "considère" rien du tout. Il ne fait que stocker des informations cruciales pour patroni (dont l'unicité du lock leader).
Patroni interroge etcd pour savoir notamment qui est qui dans le cluster patroni car etcd est le garant de cette information.
Cordialement,
Sébastien.
Hors ligne
si vous voulez des VIP et du load balancing il faut se tourner vers des produits type HA Proxy ou F5 (par exemple, il y en a d'autres) qui font ça très bien.
Le target_session_attrs c'est bien mais ce n'est pas suffisant.
Par exemple, les produits que je cite sont capable d'interroger l'API patroni pour savoir qui est leader et qui est replica pour faire de la redirection automatique vers le bon noeud.
Cordialement,
Sébastien.
Hors ligne
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,
Hors ligne
Bonjour,
Merci Ioguix pour ta réponse tres clair.
Et merci à vous 3 pour vos réponses très clair et détailler.
Je pense que Patroni n'a pas finit de me donner du fils à retordre mais c'est assez intéressant de découvrir de nouveau produit et leur limite ....
Bonne journée à tous.
Katia
Hors ligne
Bonjour,
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.
Cordialement,
Sébastien.
Hors ligne
