Vous n'êtes pas identifié(e).
Pages : 1
Merci pour ta réponse
Du coup ça peut être dangereux finalement ce genre de chaîne de connexion : jdbc:postgresql://serveur_master:5432,serveur_slave:5432/accounting?targetServerType=master
Si après un failover, les connexions se font sur le slave (devenu master), il faut bien faire attention à ce que le master ne redevienne pas opérationnel et accessible ?
Il y a un moyen moins risqué de faire ça ?
Avec un alias DNS qu'on modifierait manuellement ou bien un outil tierce pour pooler les connexions ? (pgpool, pgbouncer, ...) ?
Bonjour
J'ai un master et 1 slave en Streaming replication
Le slave sert juste pour le PRA, toutes les connexions lecture et écriture de l'application se font uniquement sur le master
L'URL JDBC paramétrée au niveau du driver JDBC de l'application :
jdbc:postgresql://serveur1:5432,serveur2:5432/accounting?targetServerType=master
Si je comprends bien, avec "targetServerType=master", toutes les connexions lecture et écriture se feront uniquement sur le serveur qui est le master
Ma question est la suivante :
Si après un PRA failover où le slave devient master, mais que l'ancien master est redémarré et redevient opérationnel, je peux me retrouver dans la situation où les 2 serveurs sont master (chacun en standalone). Dans cette situation, les connexions applicatives lecture et écriture vont-elles être faites aléatoirement sur l'un ou l'autre serveur, ou bien toujours sur le premier serveur de la liste trouvé à l'état master (serveur1 dans mon exemple) ?
Avec les risques de split brain qui en découlent ...
Merci d'avance
Des bases Oracle et SQL Server sont migrées vers PostgreSQL quotidiennement. L'inverse n'est pas vrai. Ces bases sont utilisées dans la grandes distributions, dans le secteur public, les médias..
Je n'ai jamais dit que Postgresql ne poyvait pas convenir en entreprise bien au contraire
Pouvez-vous nous en dire plus sur la volumétrie, la complexité des requêtes, le nombre d'utilisateurs simultanés, etc ... des bases que vous migrez en Postgresql, et des éventuels problèmes remontés par vos clients ?
Encore une fois, ce genre d'affirmations polémiques et moralisantes marchent peut-être sur developpez.com mais ici ça fait flop :-)
Je suis d'accord avec vous, sur developpez.com les gens sont pour la plupart des DBA sans parti pris ni intérêt commercial qui donnent leur point de vue objectivement sans dénigrer ou lyncher, alors qu'ici malheureusement ça n'a pas l'air d'être le cas, dommage ...
scheu.postgresql a écrit :J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise
quand je lis ça j'ai vraiment l'impression que les devs de postgres devraient s'excuser de faire un produit libre qui n'a pas la performance d'un produit qui coûte une fortune...
Pas s'excuser non, juste être un peu plus explicites et précis concernant les fonctionnalités de Postgresql qu'ils avancent et leurs limitations
Personne ne vous a demandé de migrer votre décisionnel. Je signale juste que vous avez écrit quelque chose de faux. Votre décisionnel ne m'intéresse pas.
J'aurais simplement aimé qu'on reconnaisse que Postgresql ne peut par encore, aujourd'hui, remplacer Oracle ou SQL Server pour une application complexe, volumineuse et critique en entreprise
Ce qui me gêne dans la démarche de certains membres c'est qu'à chaque problème que quelqu'un soulève concernant un manquement de Postgresql, on lui répond "on peut s'en sortir en faisant comme cela ou en mettant telle rustine", ce qui laisse sous-entendre qu'on pourrait tout résoudre avec Postgresql.
En gros on lit la doc Postgresql sur le partitionnement et on a l'impression qu'on peut faire tourner un datawarehouse de 500 Go ...
Jamais ou très rarement on va lire "non Postgresql ne fait pas encore cela comparé à Oracle ou SQL Server"
Cette démarche ne me semble donc pas toujours honnête
Merci néanmoins de m'avoir répondu
par contre ça ne marche que pour les égalités. Si ça avait été foreign_table.col_date> '2011-01-01', PostgreSQL aurait effectivement échoué
Ca me paraît bien insuffisant pour pouvoir migrer un décisionnel sous Postgresql, quand on a des utilisateurs qui font des requêtes ad-hoc via des outils de reporting
Sur un datawarehouse la majorité des requêtes se font sur une période avec un "between", donc dans ce cas Postgresql ne sait pas gérer le partitionnement si j'ai bien compris ?
gleu a écrit :Par contre, je suis bien d'accord que le partitionnement dans PostgreSQL n'existe pas. Il existe un moyen de contourner ce manque et il faut en connaître les avantages et les inconvénients. Ce n'est qu'un contournement.
Je trouve ça tout à fait honnête, crédible et objectif.
Mouais enfin au premier abord SQL Pro s'est fait incendier, pour finalement que gleu avoue à demi-mots qu'il a raison sur le fond. C'est au moins une bonne chose qu'il l'ai reconnu, mais au final si personne ne soulève les limitations du partitionnement sous Postgresql, on a l'impression en lisant la doc que c'est génial, alors que cça fait un peu publicité mensongère
Car au final quand on creuse, on se rend compte que ce n'est pas sérieux, et là on entend "oui mais au pire en faisant comme ceci pour faire telle rustine ça peut être faisable pour certains cas" ... Mouais ...
Quand une entreprise choisit un produit pour répondre à un besoin pour une appli critique, volumineuse, complexe, elle préfère payer pour un produit qui répondra aux besoins plutôt que de croire naïvement qu'elle va faire des économies en prenant un produit open-source, et au final avoir des ennuis derrière car, une fois le vernis gratté, on se rend compte des manquements ...
En entreprise on veut un produit qui marche quand on l'installe, pas un produit sur lequel il faut installer soi-même les rustines
Je suis quand-même atterré devant tant de dénigrement de l'article de SQL Pro (que je ne connais pas personnellement je précise).
Vous avez l'air de le faire passer pour un commercial intéressé pour vendre ses bouquins, alors qu'il ne renvoie que vers des liens internet ou vers des articles publics gratuits
Vous voulez le faire passer pour un perturbateur qui ne dit que des sottises, c'est méconnaître tous les articles qu'il a déjà pu publier notamment sur developpez.com
Alors oui sur le forum officiel de Postgresql vous êtes peut-être en majorité, mais cela ne doit pas interdire de pouvoir débattre sans que ça tourne au lynchage
Et venant de la part de personnes d'une société (Dalibo) faisant des prestations sur Postgresql, je ne suis pas certain que votre avis soit plus objectif que celui de SQL Pro pour reconnaître les quelques lacunes que Postgresql peut encore avoir aujourd'hui comparé aux SGBD payants
En gros l'article de SQL Pro n'est pas anti-Postgresql, il dit que Postgresql peut remplacer un SGBD payant dans beaucoup de cas, mais n'est pas encore suffisamment "mature" pour des applications volumineuses, critiques ou complexes
Etant personnellement DBA en entreprise avec plusieurs années d'expérience Oracle et Postgresql (avec migrations effectuées de l'un à l'autre), je suis entièrement d'accord avec cela
D'ailleurs SQL Pro a précisé ses arguments sur cette discussion pour ceux qui ne l'auraient pas lu et/ou critiquent ses arguments :
http://www.developpez.net/forums/d11409 … l-ecueils/
L'optimiseur Postgresql a encore de grosses lacunes pour des requêtes complexes
Vous parlez par exemple de hints dans les précédents commentaires, et bien oui les hints, bien que leur utilisation doit rester exceptionnelle, sont indispensables sur une application critique.
Quand du jour au lendemain, sur une requête complexe (jointure avec au moins 5-6 tables), votre plan d'exécution change et votre batch en production utilise le mauvais index, consomme 100% de CPU pendant 3 heures et non plus 5 minutes, vous vous en sortez comment ?
En achetant un nouveau CPU ?
Ben sur un SGBD payant vous mettez un hint et en 2 minutes vous éteignez le feu. Je me vois mal dire au DSI "oui mais c'est au développeur à modifier sa requête ou à tel éditeur à modifier la requête dans son progiciel, ça prendra 1 semaine minimum"
Même les paramètres tels que enable_nestedloop, enable_seqscan, ... ne suffisent pas à s'en sortir
Le principal défaut de l'optimiseur Postgresql est qu'il sous-estime trop souvent les cardinalités (nombre de lignes retournées à chaque étape du plan), ce qui conduit au bout d'un moment :
- soit à lui faire choisir des "nested loop" au lieu de "hash join" en cas de jointure
- soit à des "index range scan" trop coûteux alors qu'un full scan de la table serait au final meilleur
Je pense que ce problème est lié au fait que Postgresql sait très mal évaluer les nombres de lignes retournés pour des filtres qui comportent plusieurs colonnes
Là où Oracle ou SQL Server, sur un index (col1,col2,col3), sait faire des stats dessus et savoir estimer, pour chaque valeur du triplet, le nombre de lignes dans la table, Postgresql ne sait le faire que dans de très rares cas, les histogrammes se limitant sur des colonnes uniques et pas des t-uples
Quand, dans un autre exemple, on explique que pour pallier à l'absence de transactions autonomes il faut créer un dblink de la base sur elle-même, ça ressemble plus à une bidouille qu'autre chose.
Idem pour le partitionnement (dans un autre sujet de ce forum), qui en est encore au stade préhistorique sur Postgresql, alors que si on ne lit que les commentaires des pro-Postgresql, on a l'impression que c'est simple et génial, et qu'on va pouvoir migrer demain notre décisionnel de 500 Go sous Postgresql. Alors que c'est encore loin d'être le cas
Autre exemple au hasard : quand une requête est longue, impossible de savoir ni pourquoi, ni quand elle va se terminer, ni le plan d'exécution qu'elle a (on doit attendre qu'elle se termine pour le voir dans la log avec auto_explain)
Sérieusement sur un environnement critique et volumineux en entreprise vous croyez vraiment que c'est suffisant ?
Je ne trouve pas très honnête de conseiller Postgresql aux entreprises sans parler des mises en garde pour des applications critiques et volumineuses (au moins ça peut faire vendre de la prestation pour venir corriger les problèmes chez le client après coup ...)
La plupart des détracteurs ici n'ont même pas l'air de connaître lmes fonctionnalités de SQL Server ou Oracle, après comment être crédibles pour expliquer que Postgresql n'a rien à leur envier ?
J'aurais espéré de la part de Dalibo et des membres de la communauté Postgresql une réponse un peu moins commerciale et un peu plus honnête du genre "oui effectivement Postgresql a encore du retard sur certaines fonctionnalités, c'est encore compliqué à utiliser et peu performant, mais dans une prochaine version ça va être amélioré", ça aurait été plus objectif.
Mais là je ne suis pas certain que ça renforce votre crédibilité
A tout hasard, j'ai un décisionnel de 1 To sous Oracle 10g avec
- des jointures sur 10 tables
- du partitionnement
- du sous-partitionnement
- de la compression d'anciennes partitions dans des tablespaces en lecture seule
- quelques hints car parfois même Oracle se plante pour des requêtes ultra-complexes
A vous écouter demain je le migre sans problèmes sur Postgresql 9.1 c'est ça ? Et ne me répondez pas oui, vous savez très bien que c'est impensable dans la version actuelle de Postgresql
A titre personnel en tout cas, je maintiens mon sentiment initial qui est que Postgresql ne peut pas (encore) remplacer un SGBD payant sur des applications volumineuses ou critiques (données accessibles 24h/24 sans verrous) ou complexes (requêtes dépassant les 4-5 jointures)
Alors que je conseille Postgresql dans les cas inverses, ça fait très bien l'affaire et ça fait faire des économies : j'encourage Postgresql quand ça répond au besoin, je ne suis pas anti-Postgresql bien au contraire
Je précise, je ne travaille ni chez Oracle, ni chez SQL Server, je n'ai aucun intérêt commercial, je ne connais pas personnellement SQL Pro, je suis juste un DBA dont l'entreprise a une expérience Oracle et Postgresql depuis plusieurs années.
De ce fait j'ai comme tout le monde le droit de faire part de mon retour d'expérience. Ca serait d'ailleurs intéressant si d'autres DBA du monde de l'entreprise pouvaient nous faire part de leur expérience
PS : Monsieur Damien Clochard, je ne suis pas certain que vos interventions à base d'images font avancer le débat ... néanmoins je vous souhaite une bonne journée
Salutations
Je suis d'accord avec SQLpro sur tout son article
Le peu de tests que j'ai fait m'a suffi pour voir les lacunes de Postgresql sur le partitionnement. Quand on voit que, sur un cas simple, à la première requête un peu complexe l'optimiseur Postgresql perd les pédales et n'est même pas capable de ne lire que la bonne partition, pas besoin d'aller beaucoup plus loin dans l'analyse ...
J'ai testé en version 8.2, depuis aucune note de version des nouvelles versions n'indique une amélioration concernant le partitionnement. A contrario, vous n'avez pas admis que je me trompais sur mes commentaires.
Quand SQL Pro dit que le partitionnement est complexe avec les règles, triggers, etc ... et que votre argument c'est "vous n'avez pas testé la dernière version", ça me fait rire car la doc a l'air similaire et rien d'indique qu'il y a eu réellement un changement ou une amélioration de ce côté
A contrario, vous avez l'air de très mal connaître les possibilités d'Oracle ou SQL Server, dans ce cas je peux comprendre que ça vous dépasse d'admettre que Postgresql puisse avoir des lacunes.
J'aurais espéré de la part de Dalibo et des membres de la communauté Postgresql une réponse un peu plus honnête du genre "oui effectivement Postgresql a encore du retard sur ce point, c'est encore compliqué à utiliser et peu performant, mais dans une prochaine version ça va être amélioré", ça aurait été plus objectif.
Là je ne suis pas sûr que ça renforce votre crédibilité, dommage
Je précise, je ne travaille ni chez Oracle, ni chez SQL Server, je n'ai aucun intérêt commercial, je ne connais pas personnellement SQL Pro, je suis juste un DBA dont l'entreprise a une expérience Oracle et Postgresql depuis plusieurs années.
De ce fait j'ai comme tout le monde le droit de faire part de mon retour d'expérience. Ca serait d'ailleurs intéressant si d'autres DBA du monde de l'entreprise pouvaient nous faire part de leur expérience
Salutations
Au pire, je remets mes commentaires sur ce forum si vous souhaitez en débattre ici
Très intéressant et très complet ton article
Le peu que j'avais testé du partitionnement sous Postgresql m'avait amené à la même conclusion que toi : une usine à gaz difficile à maintenir et impensable dans un environnement de production
Pour compléter ton article, tu aurais aussi pu parler des performances en insertion : j'avais fait il y a quelques années un bench entre Oracle 10g et Postgresql 8.2, et pour une boucle d'insert ligne à ligne dans une table partitionnée, c'était 2 fois plus long sous Postgresql (sans doute à cause de tous les triggers et contraintes à vérifier à chaque insert)
Ca pourrait être intéressant de comparer les temps entre Postgresql et SQL Server
Egalement pour aller plus loin sur les plans d'exécution, sous Postgresql pour que le plan d'exécution ne lise que la bonne partition (et pas toutes les autres), il faut faire un filtre direct sur la table (ex : "where col_date = '2010-01-05'").
Mais dès l'instant où le filtre sur ta clé de partitionnement est issu d'une condition de jointure, ça ne marche pas la plupart du temps, et Postgresql parcourt toutes les partitions.
Exemple avec "table1" partitionnée par mois sur col_date et une requête du style "where table1.col_date = table2.col_date and table2.col_date = '2010-01-05'" : Postgresql 8.2 parcourt toutes les partitions de "table1" et non pas seulement celle correspondante à janvier 2010
Alors qu'Oracle (et aussi SQL Server j'imagine) est capable par association d'en déduire table1.col_date='2010-01-05' et de ne lire que la partition de janvier 2010
J'ai rencontré plusieurs fois ces problèmes de mauvais plans d'exécution en Postgresql 8.2, je n'ai pas testé si c'était toujours le cas dans les dernières versions
Je suis effaré devant tant de commentaires pour dénigrer SQL Pro (que je ne connais pas personnellement) alors que son article est tout-à-fait objectif.
Ce forum ressemble à une secte Pro-Postgresql extrêmiste qui n'accepte pas les critiques ni les comparaisons, et dont les avis sont tout sauf objectifs
A la limite je vous dis merci de ne pas censurer les messages de ceux qui ne pensent pas comme vous car on n'en est pas loin
Mr Argudo, Mr Lelarge et d'autres, vous êtes tout-à-fait louables de participer activement à Postgresql (produit que j'apprécie je précise) de manière bénévole et communautaire, mais aussi via votre société Dalibo qui fait apparemment des prestations. De ce point de vue, on ne peut pas dire que votre avis soit forcément plus objectif que celui de SQL pro, bien que je peux comprendre que ce soit dans votre intérêt de vanter les mérites de Postgresql
Mais quand ça tourne au dénigrement de tous ceux qui osent émettre des critiques sur Postgresql, je n'accepte pas.
Je ne connais pas l'historique du conflit "historique" vous opposant apparemment, je me contenterai donc juste d'intervenir concernant l'article de SQL Pro sur le partitionnement
L'article de SQL Pro sur le partitionnement est tout-à-fait objectif et ses arguments sont fondés, pour l'avoir testé moi-même dans mon entreprise je peux vous confirmer que jamais je ne conseillerai d'utiliser le partitionnement sous Postgresql dans les versions actuelles.
J'ai d'ailleurs émis mon point de vue, je vous invite à participer au débat sur developpez.com si vous souhaitez défendre vos arguments :
http://www.developpez.net/forums/d11401 … ql-server/
Franchement à voir comment vous dénigrez les arguments de SQL Pro, quelqu'un qui passe sur ce forum sans connaitre le partitionnement en arriverait presque à croire que c'est aussi bien fait sous Postgresql que sous Oracle ou SQL Server, alors que c'est loin d'être le cas
Salutations
Merci pour ta réponse
En fait mon problème était de pouvoir faire des sauvegardes (via pg_dumpall) cohérentes sur la hot-standby, c'est-à-dire :
- désactiver temporairement la réplication sur la standby
- faire un pg_dumpall sur la hot-standby, et tant que la sauvegarde tourne la réplication est désactivée
- réactiver la réplication sur la standby une fois la sauvegarde terminée
Néanmoins j'arrive à une situation de bloquage irrémédiable si le backup se déclenche alors qu'un lock est présent sur mon maitre :
- le backup sur ma standby se met en attente quand il tente de backuper la table lockée
- comme sur mon secours j'ai désactivé la réplication tant qu'un backup est en cours, la réplication ne reprend jamais même si le verrou se libère sur le maitre (la standby ne réappliquera pas le WAL contenant l'ordre SQL de libération du verrou)
Du coup la réplication ne se fait plus et mon backup reste en attente
Je pensais pouvoir réussir avec la hot-standby à faire des exports cohérents (sans que les données de la base soient modifiées pendant l'export) mais à priori ce n'est pas possible (facilement du moins) :-(
Bonjour
J'ai installé la 9.0.1 sur 2 serveurs avec log shipping, la hot-standby étant ouverte en lecture seule (hot_standby = on)
Tout marche bien (réplication avec pg_standby, accès à la hot-standby, ...) sauf que j'ai des locks sur ma hot-standby avec le scénario suivant :
- je pose un lock sur une table du serveur maitre (LOCK TABLE ma_table)
- je force un switch du wal (select pg_switch_xlog() ) pour que le lock soit propagé sur la hot-standby
- je fais une requête en lecture sur ma hot-standby (SELECT COUNT(*) FROM ma_table) qui est en attente (lock sur ma hot-standby ce qui est à priori normal). Sauf que l'attente est infinie !
Pour débloquer cette situation le seul moyen, si j'ai bien compris, est de libérer le verrou de ma_table sur le serveur primaire, du coup ça débloquera ma requête sur ma hot-standby
J'avais cru comprendre que le nouveau paramètre max_standby_archive_delay permettait de mettre un "timeout" au bout duquel la requête sur ma hot-standby était annulée, mais ce n'est apparemment pas le cas (j'ai mis max_standby_archive_delay=3s sur ma hot-standby, et ma requête attend néanmojns indéfiniment)
Du coup c'est gênant car, si le lock de ma_table sur le serveur maître dure 1 heure, la réplication sur la hot-standby est bloquée pendant 1 heure !
Le paramètre max_standby_archive_delay permet-il vraiment de débloquer ce genre de situation ?
Si oui, comment ?
Si non, existe-il une autre solution pour éviter ces blocages ?
Merci d'avance
Pour ceux que ça intéresse, j'ai enfin eu le temps de tester un peu cet outil
Il comporte dans la version actuelle (1.1.2) encore des bugs assez impactants pour pouvoir réellement l'utiliser sereinement dans un cadre professionnel :
- ne gère pas le passage à l'heure d'été (http://code.google.com/p/pg-rman/issues … ty%20Owner)
- pour les restaurations à un instant passé, il ne sait pas trouver lui-même depuis quel backup full partir pour rejouer les logs, il ne part que du dernier. Pas pratique si l'on veut restaurer à un instant plus ancien que le dernier backup full (http://code.google.com/p/pg-rman/issues … ty%20Owner)
Des contournements existent pour ces 2 bugs mais ne sont pas encore intégrés dans la prochaine version ...
Bref à utiliser éventuellement en supplément d'un export full régulier (pg_dump), mais à mon sens pas suffisamment encore mature pour devenir l'unique mode de backup d'une base Postgresql
Pages : 1
