Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Existe-t-il la possibilité d'avoir plusieurs serveurs postgres pout faire de la répartition de charge. En d'aitres termes postgres est -il scalable ? A priori je n'ai rien trouvé sur la doc .
Merci de votre aide
A+
G.
Dernière modification par Gil34 (26/09/2011 11:07:09)
Hors ligne
Plusieurs serveurs pour faire de la répartition de charge, oui, mais évidemment avec des limitations.
Ça dépend de ce qu'on cherche… on peut tout simplement faire une architecture avec un maître et plusieurs esclaves, et un pgpool devant qui redirige les requêtes en lecture seule qui n'ont pas besoin de données extrêmement fraîches vers les esclaves. Ou le faire au niveau applicatif, avec 2 pools tomcat par exemple, suivant l'application.
Il y a aussi des technos de réplication pour Postgresql multi-maitre, synchrone ou asynchrone, chacune avec évidemment ses défauts…
Bref, la question est un peu trop vague pour te donner une réponse approfondie. Décris plutôt ton besoin, si ce n'est pas juste une question de curiosité…
Marc.
Hors ligne
En fait je veux que la charge (cpu, memoire...) se répartisse automatiquement sur plusieurs serveurs postgres. Un peu comme ça existe pour des applis tomcats ou les requetes vont sur l'un ou l'autre des serveurs tomcats.
Je fais déjà de la réplication mais ça ne sert que pour gérer un éventuel crash serveur ou disque.
Maintenant je veux avoir 2 serveurs postgres qui prennent chacun des requetes afin de diminuer la charge systeme de chaque machine et de la répartir équitablement entre eux deux. Les requetes pouvant etre en lecture et en ecriture...
Je pense que c'est ce qu'on appelle de la scalabilité.
Est ce plus clair ?
A+
G.
Dernière modification par Gil34 (26/09/2011 11:40:37)
Hors ligne
C'est plus clair. Et le problème: Postgres est avant tout là pour garantir la cohérence des données entre toutes les tables (les contraintes d'intégrité…).
On a donc plusieurs architectures possibles:
- Un seul maître, qui garantit la cohérence, et des esclaves, synchrones ou asynchrones, ça dépend de la techno de réplication. Celle livrée avec la 9.0 est asynchrone, en 9.1 elle est potentiellement synchrone, mais même en mode synchrone, il n'y a aucune garantie qu'une donnée validée sur le maître devienne visible instantanément sur l'esclave. La seule garantie qu'on a, c'est qu'elle est écrite sur le disque de l'esclave, et ne sera pas perdue. Dans ce cas, il vous faut envoyer les requêtes au bon endroit, soit par pgpool, soit à la main (2 pools de connection par exemple, c'est pas si dur que ça à gérer d'un point de vue logiciel)
- Plusieurs maîtres. Dans ce cas, si on est synchrones, on peut avoir de la cohérence, comme avec Postgres-R. Mais ça se fait forcément au détriment des performances en mise à jour, puisqu'on a du dialogue entre les nœuds. Si on est asynchrone, adieu la cohérence…
Il y a tout un chapitre dessus, dans la doc, pour se mettre le pied à l'étrier : http://docs.postgresql.fr/9.1/high-availability.html
Marc.
Hors ligne
Merci, je vais lire la doc que tu m'indiques et reviendrais sans doute vers toi aprés ...
A+
Hors ligne
En fait je veux que la charge (cpu, memoire...) se répartisse automatiquement sur plusieurs serveurs postgres. Un peu comme ça existe pour des applis tomcats ou les requetes vont sur l'un ou l'autre des serveurs tomcats.
Je fais déjà de la réplication mais ça ne sert que pour gérer un éventuel crash serveur ou disque.
Maintenant je veux avoir 2 serveurs postgres qui prennent chacun des requetes afin de diminuer la charge systeme de chaque machine et de la répartir équitablement entre eux deux. Les requetes pouvant etre en lecture et en ecriture...
Je pense que c'est ce qu'on appelle de la scalabilité.
Est ce plus clair ?A+
G.
De manière général, les SGBDR ne peuvent en aucun cas reproduire les mécanisme de répartition de charge des serveur Web, et cela pour une raison toute simple : il faudrait que les données soient simultanément présente sur tous les serveur. Autrement dit une insertion d'une ligne dans une table doit être envoyé à tous les serveurs...
Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1038 … #more10383
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ok, je me rends compte que la répartition de charge pour un SGBD n'est pas simple.
Je vais peut etre me diriger vers un serveur maitre pour les écritures et plusieurs serveurs pour les lectures.
Je dois pouvoir utiliser pour cela le mécanisme des warm et hot standby donnant en plus la possibilité, si j'ai bien compris, qu'un serveur puisse remplacer à la volée le maitre si celui ci tombe en panne.
Bon j'ai encore du boulot.
A+ et encore merci de vos remarques et docs
Hors ligne
C'est une décision tout à fait sage et PG commence à avoir un bon mécanisme pour ce faire... mais attention en 9.1 c'est encore en béta :
« Transaction-controlled Synchronous Commit ».
Mea culpa... La version finale 9.1 est sortit depuis le 13/9... Désolé
A +
Dernière modification par SQLpro (11/10/2011 12:16:07)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pages : 1
