Vous n'êtes pas identifié(e).
Pages : 1
Compris, merci !
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 ?
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
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.
Pages : 1
