Vous n'êtes pas identifié(e).
Bonjour à tous...
pouvez-vous me dire (en gros et rapidement ce qui vous vient à l'esprit... ensuite je creuserai !) quelles sont les + grandes différences entre les versions 8.2 et 8.4 de Postgrès...
Si elles sont vraiment différentes... et quel est le + gros apport de la 8.4 par rapport à la 8.2.
Merci d'avance...
Hors ligne
Bonjour.
En premier je dirais le HOT (8.3) et les window functions (8.4) qui peuvent apporter un gros gain de performance.
Julien.
https://rjuju.github.io/
Hors ligne
Celles qui me viennent à l'esprit: disparition de la free space map, window functions et cte, améliorations de l'optimiseur, des perfs en écriture de façon générale.
Rien que la premièer justitife de ne pas mettre la 8.2.
Un autre point: la 8.2 n'est plus supportée.
D'ailleurs, pourquoi mettre en place des «vieilles» versions, si c'est pour un nouveau projet ?
Marc.
Hors ligne
Merci pour vos réponses...
Nous devons creer/installer un logiciel maison (avec PGPOOl et Hot Standby) mais nos RedHat supportent :
- openldap 2.4.19
- httpd 2.2.15
- postgresql-server 8.4.7
- tomcat6 6.0.24 sous redHat
Sans minimiser les disparitions des FSM et consorts, je vois que les grandes différences entre les deux versions portent plutôt sur les performances... me trompje-je ?
Nous ne pouvons pas installer un Postgrès 9, car Redhat n'a pas encore de support sur cette version... et cela, pour nous, est irrecevable !
Qu'en pensez-vous ?
Hors ligne
Il y a eu beaucoup d'améliorations/nouveautés, et sans savoir ce qui vous intéresse le plus il est difficile de répondre de façon vraiment juste.
Pour une liste plus exhaustive, vous pouvez-voir les pages consacrées aux nouveautés des version 8.3 et 8.4 :
http://wiki.postgresql.org/wiki/WhatsNew83
http://wiki.postgresql.org/wiki/WhatsNew84
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour ces tuttos...
Faites-moi râler... Qu'avons-nous raté entre les versions 8 et 9 ?
Hors ligne
EN 9.0 :
* la réplication interne
* une gestion plus simple des droits
* les fonctions anonymes
* un grand nombre d'amélioration en PL/Perl et PL/Python
* des améliorations pour les requêtes de fenêtrage
* des nouvelles fonctionnalités sur les triggers
* la possibilité de différer la vérification des contraintes uniques
* les contraintes d'exclusion
* une nouvelle implémentation du VACUUM FULL beaucoup plus rapide
* quelques améliorations sur l'EXPLAIN
Et pour la 9.1 :
* la réplication synchrone
* le support des tables distantes/étrangères
* le collationnement par colonne
* les extensions
* le SSI
* les tables non journalisées
* les requêtes CTE en écriture
Et pas mal d'autres améliorations un peu partout.
Guillaume.
Hors ligne
http://blog.postgresql.fr/index.php?pos … ostgreSQL2 et https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.1/fr sinon …
Marc.
Hors ligne
Merci pour vos réponses...
En fait, je reprend une étude commencée fin 2011 sur l'installation d'une application avec serveur maitre et esclave en 'hot stanby'... et qui commence à voir le jour...
J'ai relu toutes les réponses à mes questions de néophyte, mais je m'en pose une autre maintenant que nous avons peu plus de billes sur le sujet...
1°) Quel(s) type(s) de réplication peut-on espérer avec la 8.4 ?
2°) Gillaume, quand vous écrivez qu'une des nouveautés principales de la 9.0 est la 'réplication interne', est-ce de la 'streamin réplication' dont vous voulez parler ?
3°) Si je dis que la 8.4 ne gère que de la réplication asynchrone, je me trompe ?
Merci pour vos réponses...
Merci pour vos réponses...
Hors ligne
1) Avec la 8.4, c'est du warm standby: la base esclave n'est pas accessible en lecture. Par ailleurs, c'est du log shipping en mode fichiers: on envoie les fichiers WAL au fur et à mesure de leur génération (donc par paquet de 16Mo, donc un lag non négligeable)
2) C'est la streaming replication dont il parle. Ça fait que le lag est bien plus faible. Mais à part ça, c'est exactement la même chose: on rejoue le journal de transaction
3) Oui, et très asynchrone, puisque par paquet de 16Mo de modifications. La 9.0 reste asynchrone, mais avec un retard plus faible, et la 9.1 peut à la demande être synchrone.
Marc.
Hors ligne
J'ajouterai juste que le hot standby est accessible à partir de la version 9.0
Julien.
https://rjuju.github.io/
Hors ligne
Juste une dernière pour préciser...
Quelle est la différence entre une 'HOT standby'(9.0) et la 'streaming réplication'(9.1) ? Est-ce le fait que l'un est asynchrone et l'autre synchrone ?
Encore désolé !
Hors ligne
Hot Standby, c'est le fait qu'on puisse connecter à un esclave. Un esclave est soit en Warm Standby (pas de connexion possible sur l'esclave) soit en Hot Standby (connection possible en lecture seule).
Streaming Replication, c'est le mode d'envoi des données de réplication du maître vers l'esclave. Sans le Streaming Replication, le maître envoie des fichiers de 16 Mo. Avec le Streaming Replication, le maître envoie ce qu'il a pratiquement dès qu'il l'a... donc moins de lag. La Streaming Replication n'est qu'asynchrone en 9.0 et peut être asynchrone ou synchrone en 9.1.
Guillaume.
Hors ligne
Merci à tous pour vos réponses...
Hors ligne
Re-bonjour à tous...
Juste une dernière confirmation, suite à une discussion...
Pouvez-vous me confirmer que PGPOOL tout seul, est incapable d'effectuer des réplications de bases de données... et qu'il faut y ajouter Slony ou le warm ou le hot standby ou un autre produit ?
Merci pour vos réponses...
Hors ligne
Pgpool seul peut effectuer une réplication, mais cette réplication se base sur une duplication des toutes les requêtes sur chacun des esclaves, ce qui peut être plus lent, et parfois amener des problèmes "cachés" (oid d'objets différents ...).
Julien.
https://rjuju.github.io/
Hors ligne
Oui, ou pour répondre encore plus directement: pgpool a un mode réplication. Mais je ne l'utiliserai jamais en production, personnellement. Bien trop dangereux.
Marc.
Hors ligne
Pfuittt donc j'avais tort...
Vous écrivez que 'Pgpool SEUL' peut effectuer des réplications... j'avoue là, ne plus rien comprendre car vous ne semblez pas inclure dans la réplication, le warm/hot/Slony etc...
Alors, dois-je comprendre dans votre réponse que PGPOOL duplique tous les inserts, updates ou delete du serveur maître vers les serveurs esclaves, mais que les autres duplications (warm/hot, Slony) sont d'autres 'formes' de réplications (Trigger ou envoie des logs !)...
Me trompe-je ?
Hors ligne
À mon avis, rjuju voulait dire pgpool seul comme "pgpool tout seul"
Marc.
Hors ligne
Je pense aussi Marc... mais peut-être nous enverra t'il sa réponse...
Quel sont d'après vous, les dangers les plus graves que peut encourir ce genre de réplication en environnement de prod... la sécurité ? la fiabilité ?
Hors ligne
De ne pas avoir les mêmes données sur les deux serveurs. Ce qui, pour une solution de réplication, est un peu embêtant tout de même.
Marc.
Hors ligne
Dans le sens ou s'il y a un plantage lors par exemple d'un UPDATE sur l'esclave, les serveurs n'ont plus les mêmes données ?
Hors ligne
Dans le sens où si 2 updates ne sont pas joués dans le même ordre sur les deux nœuds (race condition entre sessions) on n'aura pas forcément le même résultat. Dans le sens où certaines fonctions qui sont appelées par select modifient les données (il suffit d'oublier d'en déclarer une à pgpool). Dans le sens aussi où il y a plein de hacks dans pgpool pour que ça marche quand même: que se passe-t-il si ma session fait un update toto set timestamp=now() sur les deux nœuds ? => pgpool doit d'abord aller faire now() sur un nœud, puis le substituer dans les requêtes. Bref, beaucoup trop de «gotchas» pour que je lui confie mes données 
Marc.
Hors ligne
Merci pour tout !
Hors ligne
Juste une dernière :
La création d'un table (CREATE TABLE toto) est-elle répercutée sur l'esclave où faut-il effectuer les creates sur les deux noeuds ?
Hors ligne
