Vous n'êtes pas identifié(e).
Bonjour
Concernant les outils graphiques de gestion j'utilise EMS Postgresl Manager
Il est sous Windows et malheureusement payant mais il est très complet.
La même chose sous linux et j'abandonne EMS...
Concernant la réplication, j’attends avec impatience la future version qui devrait implémenter quelque chose. Il parait que la version 8.4 devait le faire mais comme ce n'était pas encore au point il ne l'on pas implanté).
Hors ligne
Je pensais effectivement à MySQL, mais le but n'était pas de polémiquer. Je pense que si les lecteurs de ce forum pensaient que MySQL était meilleur que PostgreSQL, ils seraient plutôt sur un forum dédié à ce SBGD...
Je tiens à préciser que je n'accusais personne de FUD en dehors de moi 
Non, par contre, je continue à penser qu'un système de "cluster" au sens où on l'entend traditionnellement (plusieurs machines physiques participant à un seul système logique) reste plus souple pour l'usager que des systèmes de réplications tiers, donc moins intégrés.
RedHat Cluster Suite le permet. DRBD le permet aussi. Mais dans ces deux cas, impossible d'utiliser l'esclave en lecture seule.
En ce qui concerne la réplication maitre/esclaves, sur beaucoup d'applications qui réalisent plus de lectures que de modifications, c'est là encore une réponse qui peut être satisfaisante, à condition que les esclaves soient accessibles en lecture. D'ailleurs, je pense que si la "core-team" PostgreSQL cherche à améliorer son actuelle réplication par log-shipping, c'est probablement que leur point de vue n'est pas si éloigné que ça du mien ;-)
Je ne critique pas le problème que vous énoncez, à savoir que la réplication est un sujet complexe et donc pas simple à mettre en œuvre. Par conte, je réfute le fait que la réplication de MySQL soit la panacée. Qu'elle soit simple à mettre en œuvre, soit. Mais j'ai aussi envie que mes données soient en sécurité, et il semble que ce n'est pas le cas.
Par contre, ce que je regrette dans les systèmes de réplication maitre/esclave, c'est que s'il est généralement assez simple de promouvoir un esclave en tant que nouveau maitre (par exemple en cas de nécessité d'arrêt du maitre pour maintenance), resynchroniser a postériori un serveur pour le "re-promouvoir" maitre n'est pas toujours chose aisée.
Slony le permet assez simplement en cas de switchover. Le faire après un failover est plus critiquable vu que le maître est souvent sérieusement plantée (panne de disque par exemple).
Enfin, une question un peu naïve. Les systèmes de réplication ont basiquement (c'est très réducteur, je sais !) pour mission de "rejouer" les modifications apportées à une base vers une ou plusieurs autre(s) base(s). Or, sous PostgreSQL, la description de la base est elle-même accessible via le schéma spécifique information_schema (c'est, je trouve, un atout pour PostgreSQL). Pourquoi ne peut-t-on pas mettre les systèmes actuels de réplication à l'écoute de ce schéma particulier ?
C'est un schéma système et il est impossible de placer un trigger sur un schéma système. Sinon il serait assez simple de le faire sur les tables pg_class et autres pour trouver les nouvelles tables ou les tables supprimées.
En espérant avoir éteint l'incendie que je ne voulais pas allumer,
Autant vous le dire tout de suite, il n'y a aucun incendie à éteindre
Et si vous avez trouvé ma réponse dure, j'en suis désolé.
Si quelqu'un possède du poids pour attirer l'intérêt de l'équipe de développement de PG sur ces gros sujets, je pense que "l'Histoire lui sera reconnaissante d'avoir défendu une BONNE CAUSE en faveur des utilisateurs et des développeurs sous PG."
Ils y sont déjà intéressés. Ensuite, il faut qu'un développeur ait le temps et le financement pour le faire. Hot Standby et Rep Sync devrait déjà bien améliorés les choses. Le jour où ils sortent, cela devrait faire grand bruit à mon avis. pgAdmin sera là pour intégrer les composantes nécessaires.
Guillaume.
Hors ligne
Il semblerait que, décidément, mes exemples sont tous mauvais. Je ne connais du "RAC" d'Oracle que la brochure commerciale et je ne souhaite pas que PostgreSQL copie telle ou telle base, mais qu'il s'améliore encore et encore. N'est-il de toutes façons pas déjà le meilleur SGBD ;-) ?
Honnêtement, je ne plains absolument pas de la disponibilité de PostgreSQL, même en version "mono-serveur". En 7 ans, sur un système gérant plusieurs millions de requêtes par jour, je n'ai eu qu'un seul plantage, qui était dû à un défaut sur une carte mère. Difficile de faire mieux en terme de disponibilité !
Néanmoins, j'aimerais pouvoir "facilement" basculer sur un 2ème serveur, le temps par exemple d'upgrader mon serveur principal en 8.4, sans pour autant interrompre le service. En effet, si l'installation des binaires est relativement rapide, remonter un dump demande beaucoup de temps (je n'ai pas testé en 8.4 qui, d'après ce que j'ai compris, améliore ces performances en parallélisant les requêtes, mais jusqu'ici, cette opération nécessitait plusieurs heures).
En fait, ma principale réflexion concerne la répartition de charge. Non pas que les performances de PostgreSQL soient mauvaises, loin de là, mais ses nouvelles fonctionnalités, notamment T-search, m'ont ouvert la voie à de nombreux développements complémentaires. Là où j'utilisais autrefois PostgreSQL comme un simple entrepôt de données, il devient aujourd'hui une "brique" offrant des services de plus en plus riches. Or, dans ce cas, la montée en charge commence à devenir problématique. J'ai par exemple une table sur laquelle je fais des recherches T-search. Elle contient environ 4 millions de lignes et, bien que le 'tsvector' y soit renseigné et indexé, une recherche dure quelques secondes. Ce n'est pas un problème quand un utilisateur lance une requête, mais ça le devient quand j'en ai 5000 simultanés. Je cherche donc un moyen de répartir la charge (je peux rajouter plusieurs serveurs si nécessaires), sans pour autant trop me compliquer la vie, sachant que les développements s'intensifient, et que, par conséquence, les évolutions du schéma sont relativement fréquentes.
Voilà, vous savez tout sur mes besoins actuels; ceci éclairera peut-être sous un angle différent mes précédents posts.
En tout cas, merci pour votre attention et vos précieux conseils.
Jérôme
Hors ligne
Le mieux est qu'il est possible de faire actuellement est d'installer PostgreSQL sur plusieurs serveurs, de répliquer les données du serveur maître vers les X esclaves (avec Slony ou Londiste) et de faire de la répartition de charge avec pgPool-II. D'après une étude faite pour un client, les performances vont clairement en s'améliorant, à condition bien sûr d'avoir un nombre important de clients simultanés (de toute façon, cette réalisation n'a pas d'intérêt dans le cas contraire). Plus on ajoutait de serveurs, plus les performances s'amélioraient. Nous sommes allés jusqu'à trois serveurs esclaves (donc quatre serveurs en tout), ce qui n'est pas énorme mais cela permettait d'arriver à des temps de réponse intéressant.
Il est aussi possible d'utiliser Bucardo en master/master, mais il faudra trouver un moyen pour régler plus ou moins automatiquement les conflits. Et vous ne pourrez avoir que deux nœuds dans ce cas, ce qui limite clairement la répartition de charge (qu'il faudra en plus gérer vous-même).
Guillaume.
Hors ligne
