Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 25/07/2019 16:12:35
- lajoumard
- Membre
Répartition de charge sur standby physique
Bonjour,
Je cherche la meilleure solution pour répartir la charge des requêtes sur un serveur postgres maitre et son standby physique.
J'aimerai que les transactions en lecture seule aillent sur le slave (ou master si slave indispo ) pour alléger la charge.Mais l'ideal serait qu'un outil tiers le fasse sans qu'on soit obligé de retoucher le code applicatif et gérer cela
avec 2 connectiions JDBC . Existe-t-il un outil ou une stack qui permettre de faire le tri des transactions entrantes pour les rediriger ensuite vers la bonne connexion ? la base étant en autocommit cet outil devrait être capable de dire sur un SELECT "j'envoi cette transaction " vers le seveur standby . A l'opposé si la transaction commence par un BEGIN ou est un ordre DML différent de SELECT alors la transaction sera dirigée vers le master .
Merci
Dernière modification par lajoumard (25/07/2019 16:13:47)
Hors ligne
#2 25/07/2019 18:26:35
- gleu
- Administrateur
Re : Répartition de charge sur standby physique
pgpool le fait. Cependant, vous pouvez aussi avoir le cas "SELECT fonction_qui_fait_des_ecritures()" et vous retrouvez avec des SELECT envoyés sur le secondaire qui vont de ce fait échoués. Pgpool propose une parade à ça qui est de lui indiquer toutes les fonctions en lecture seule ou toutes les fonctions en écriture.
Un autre problème est que toutes les requêtes doivent passer par pgpool pour que cela fonctionne bien. pgpool devient donc votre SPOF. (pgpool ou tout autre outil du même acabit).
Un autre problème est que vous devez avoir une réplication synchrone entre vos serveurs. Sinon vous n'avez aucune garantie qu'une écriture faite sur le primaire sera immédiatement visible sur le secondaire.
Autant vous dire tout de suite que cela ne va pas être simple...
Guillaume.
Hors ligne
#3 26/07/2019 07:37:18
- rjuju
- Administrateur
Re : Répartition de charge sur standby physique
Plus qu'une réplication synchrone, il faut également positionner la réplication en remote_apply pour attendre l'acquittement du rejeu sur le standby.
Un autre problème est que chaque requête sera également parsée 2 fois (une fois par pgpool pour savoir où l'envoyer et une fois par postgres). Ce simple fait rend la balance de charge via un outil externe (quel qu'il soit) plus couteuse que tout envoyer sur un seul serveur avec de l'oltp et des requêtes très rapides.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1