Vous n'êtes pas identifié(e).
Bonjour
Je suis sur un postgresql14 (installé sur SLES12SP5) sur lequel j'ai fait la configuration pour avoir une réplication sur une autre machine identique (même versions postgresql14 et SLES12 SP5).
Tout va bien niveau config et réplication: quand on écrit sur le Primary, la réplication est bien faite sur le standby.
Il y a cependant un comportement qui m'a étonné: si le standby devient injoignable (coupure réseau, machine éteinte ou postgresql14 pas démarré), le primary "freeze" : plus aucune requête ne fonctionne, je n'ai plus accès aux données depuis mes applis web (je peux toujours aller en console consulter les bases).
Après avoir un peu cherché, j'ai vu que cela venait du mode synchrone: quand il est activé, le primary attend donc une réponse du stand by... le problème étant qu'il attend indéfiniment. Je m'attendais à ce qu'il y ait une tempo vu qu'il ne s'agit que d'une réplication sur un serveur standby indispo.
Suis-je passé à côté d'une configuration ?
Voici ma conf sur le primary:
shared_buffers = 1GB
effective_cache_size = 4GB
work_mem=128MB
maintenance_work_mem=512MB
autovacuum_vacuum_scale_factor = 0
autovacuum_vacuum_threshold = 10000
vacuum_cost_page_hit = 1
vacuum_cost_page_miss = 10
vacuum_cost_page_dirty = 20
autovacuum_vacuum_cost_delay = 4ms
autovacuum_vacuum_cost_limit = 400
autovacuum_max_workers=3
listen_addresses = 'localhost,172.25.157.182'
wal_level = replica
synchronous_commit = on
max_wal_senders = 10
wal_keep_size = 64
wal_log_hints = on
wal_receiver_status_interval = 10s
hot_standby_feedback = on
synchronous_standby_names = '*'
Comme workaround, je pourrai passer le synchronous commit à off ou local et jouer avec le wal_writer_delay, qu'en pensez vous ? sachant que l'important est de garder des données non corrompues sur la réplication, tant pis si on en perd au moment où le primary tombe.
Dernière modification par FredP (15/12/2022 16:33:21)
Hors ligne
Le comportement est normal et attendu. Soit vous choisissez de garantir la disponibilité de vos données soit de votre service, mais les deux sont incompatibles par définition.
Si perdre des données en cas d'incident majeur sur le serveur primaire n'est pas un problème, passez en réplication asynchrone et mettez en place un outil de supervision du lag de réplication voire des scripts au dessus si vous vouls garantir un volume de données perdu maximum en cas de problème avec la réplication.
Julien.
https://rjuju.github.io/
Hors ligne
Ce qui m'a étonné c'est la dualité entre le fait que ce soit 2 serveurs synchronisés (auquel cas, je comprends parfaitement cette notion de blocage dès qu'un des 2 est indisponible) et le fait que ce soit la réplication, donc le serveur de copie, qui puisse bloquer le serveur principal.
Je m'attendais à avoir un mécanisme qui permette de continuer de faire fonctionner le primaire, comme un timer qui débloque la situation si le standby venait à ne plus répondre.
Merci en tout cas de lever ce doute, je vais passer sur de l'asynchrone
Hors ligne
L'unique but de la réplication synchrone est de justement arrêter toute activité sur le primaire tant que le(s) secondaires ne sont pas revenus.
La technique habituelle pour éviter un incident sur le primaire est d'avoir N+1 serveurs secondaires, et de 1 à N serveurs en réplication synchrone (N étant le nombre de noeuds que vous pouvez vos permettre de perdre avant d'impacter le primaire).
Julien.
https://rjuju.github.io/
Hors ligne
Une dernière question: en lisant votre réponse, j'en comprends qu'à partir du moment où 1 serveur secondaire répond, le primaire continue de fonctionner ? Si j'avais eu un 2ème serveur en stand by en réplication, le primaire aurait continué de fonctionner tant que ce 2nd serveur ne tombe pas ?
Hors ligne
Avec votre configuration actuelle non car vous demandez à ce que n'importe quel serveur secondaire soit synchrone.
Regardez du côté de https://www.postgresql.org/docs/current … NDBY-NAMES pour gérer une granularité différente.
Julien.
https://rjuju.github.io/
Hors ligne
Compris, merci !
Hors ligne
