Vous n'êtes pas identifié(e).
Bonjour à tous...
Je reviens vers vous pour des questions sur le hot standby et autre (et excusez mes questions bêtes !) :
1°) Comment sont réparties les lectures sur un serveur HotStandby ? Est-ce PGPOOL qui choisit la répartition genre : j'envoie le 'SELECT de l'utilisateurA vers Esclave' et 'Select de l'utilisateurB vers le Maître' ?
2°) J'ai pas trop compris la différence entre le 'failover' et le 'switchover' lors d'un switch entre le serveur maître et esclave...
3°) A quoi servirait un serveurs maître qui aurait par exemple 5 esclaves ?
4°) Autre chose... est-il possible d'avoir une très grosse database Postgrès, diffusée par exemple, sur 12 serveurs (1 serveur définissant 1 mois de donné)... dont les mises à jour seraient effectuées, selon les données, vers tel ou tel serveur ?
Merci pour vos réponses...
PS : Bravo pour les 2 post sur les 'mises en replication Postgrès 9.0 '... ils sont très clairs !
Merci pour l'éclaircissement...
Je pense que nous allons choisir la réplication interne, mais ce ne sera acté que la semaine prochaine... peut-être alors reviendrais-je sur cet excellent forum pour discuter de détails techniques...
Dans tous les cas, merci à vous tous pour vos précieux conseils...
Guillaume, j'ai une question à vous poser :
Dans votre réponse à ce post du 03/10/2011 à 16:33:10 vous dites que dans le cas de Slony, le serveur esclave reste en écriture (ce qui me semble normal)... ok mais dans votre excellent document : http://www.dalibo.org/postgresql_9.0_et_la_replication, il semble que le chapitre 9 (tableau récapitulatif) dise le contraire...
Votre post du 03/10/2011 à 16:33:10 parlait-il uniquement de slony ou bien incluait-il aussi Bucardo...
Merci pour votre réponse...
PS : Je pense que nous choisirons une réplication en 'log shipping'
Juste une question :
Pour moi le pooling et la réplication des données entre deux serveurs sont quand même deux choses différentes ...
Peut-on effectuer de la réplication sans installer PGPOOL ?
Excusez, je suis un vieux fan de Pink floyd !
Et je croyais en fait, qu'il y avait deux façon de répliquer les données entre le serveurs :
via les Walls
et
via les archivelogs (donc pour moi ce que l'on appelle 'log shipping') ...
Mais bon, je me suis fourvoyé !
Bonjour à tous...
Oui, les wall sont bien les journaux de transaction (comme les redo d'oracle !)... mais j'avais cru comprendre que le 'log shipping' était l'envoi des archives(log) entre deux serveurs (donc avant que les wall se ré-écrasent, archivage de ceux-ci dans fichier afin d'en conserver la trace et de les ré-appliquer en cas de catastrophe !)... mais j'ai du mal lire la chose...
Ok donc pour les walls qui se partagent entre deux serveurs...
Rjuju...
Sur la réplication sélective : Est-ce une réplication des tablesA sur le serveur A et des tablesB sur le serveurB en sachant que TablesA et tablesB sont sur le serveur Maitre (Même database) et que la réplication se découpe sur deux serveurs esclaves avec deux moitié de databases ?
Si c'est cela, à quoi ça sert ?
Merci Gleu...
qu'appelez-vous 'génération de rapports' ? Sont-ce par exemple, des rapports genre BO qui donnent des références croisées sur des données... qui seraient lancées sur le serveur esclave afin de ne pas trop surcharger le serveur maître...
Hein ?
PS : Je n'ai toujours pas vu la mode d'emploi pour faire de la réplication par WALL... a contrario de la réplication 'log Shipping' qui est très bien documentée ...
Merci à tous...
Une autre question d'un novice :
En fait nous allons installer un Postgres 9 pour faire tout ça avec un serveur maître + un esclave (j'avais oublié de vous le dire !)...
Je me pose la question suivante : Pourquoi installer slony (donc je suppose créations de x triggers sur x tables... rajout de triggers à chaque création de nouvelle table etc... donc gestion plus lourde ) alors que la réplication par WALL par exemple, semble bien plus simple à gérer ...
Quelle est la solution la plus fiable ?
je reprends :
Une autre : Nous penchons vers une structure avec 1 serveur maître et un esclave (avec répartition de charges), mais j'avoue être un peu embrouillé... ...
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
2°) Est-ce ça que vous appelez le 'synchrone asymétrique'
3°) Pour moi, d'après ce que j'avais lu, la solution du log shipping entre les deux serveurs me semblait simple, est-ce ça que vous appelez l''asynchrone asymétrique ' ou est-ce du 'warm standby'
4°) J'ai vu qu'il y avait aussi la solution de passage par les WALLS... ok, mais mais je n'ai pas lu de post là dessus... est-ce ça que vous appelez le synchrone asymétrique '
Une autre : Nous penchons vers une structure avec 1 serveur maître et un esclave (avec répartition de charges), mais j'avoue être un peu embrouillé... ...
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
2°) Est-ce ça que vous appelez le 'synchrone asymétrique' ou est-ce du 'wa
3°) Pour moi, d'après ce que j'avais lu, la solution du log shipping entre les deux serveurs me semblait simple, est-ce ça que vous appelez l''asynchrone asymétrique '
4°) J'ai vu qu'il y avait aussi la solution de passage par les WALLS... ok, mais mais je n'ai pas lu de post là dessus... est-ce ça que vous appelez le synchrone asymétrique '
Merci Guillaume, je vais lire tout ça à tête reposée ...
Merci à vous deux...
Je suis en train de lire toutes les options sur la haute disponibilité : http://docs.postgresql.fr/8.3/high-availability.html ... Quelqu'un a t'il une quelconque expérience en haute disponibilité sur Postgrès... et aussi quel fut leur choix et pourquoi ?
Nous allons je pense, intégrer une appli en haute dispo via PGPOOL... mais, les autres solutions ont aussi leurs avantages... J'aimerai en fait, avoir un retour de ceux qui ont implémenté une telle architecture sur Postgrès... et aussi pourquoi ils ont choisit telle ou telle solution ...
Merci d'avance pour vos retours !
NB : Le log Shipping fait-il partie de la solution de réplication asynchrone des données : Chapitre 'Réplication asynchrone multi-maîtres' de la page ouèb citée plus haut ?
Merci pour vos réponses..
1°) Pourquoi PGPOOL examine-t'il les requêtes ? Est-ce un pré-explain pour anticiper le temps de connexion à la database ?
2°) Qu'appelez-vous Pooling seul ?
Merci Guillaume pour vos réponses...
Bonjour à tous...
ici nous commençons à parler de PGPOOL et j'ai commencé a voir tout ça sur internet...
Sur ce que j'en ai lu, pouvez-vous me confirmer (ou pas !) mes interrogations suivantes :
1°) C'est un produit qui optimise les temps de connexions
2°) Il répartit les connexions au mieux
3°) il les 'partage', dans le sens où il conserve une connexion existante pour la donner/l'associer à une nouvelle qui arrive...
4°) Est-ce vraiment un produit qui accélère les connexion (à peu près quel ratio ?)
5°) Existe t'il sur d'autre os que la Débian ?
Merci pour vos réponses...
Merci...
Merci...
mais comment s'y prend t'il... via les archivelog ?
Merci pour votre réponse...
J'ai lu (sur un site concurrent !) ce qu'était le 'log shipping' donc c'est Ok pour moi !
Mais je butte sur ce qu'apporte Slony ? Est-ce de la réplication entre les objets d'un serveur maitre et un(des) serveurs esclave(s) ? De quelle(s) façon(s) s'effectue cette réplication ?
Merci pour vos réponses...
Bonjour à tous...
Quelle différence y a t'il entre le 'log Shipping' et Slony... Sont-ce des appellations différences pour une seule et même fonctionnalité de 'partage' d'archivelog entre un maître et un esclave...
Merci pour vos réponses...
Oui bien sûr, je ne parlais pas des databases 'systeme' Postgrès (postgrès, template0 etc...), mais bien de databases applicatives !
Merci pour vos éclaircissements...
Merci Arthurr...
Effectivement je n'avais pas pensé au cluster, car je n'ai qu'une database sur un serveur...
Donc, vous semblez me dire qu'il n'y aurait qu'une seule arborescence ////pg_log sur une architecture 'cluster' avec plusieurs database ?
Me trompe-je ?
Merci Gleu...
mais vu que pgfouine fonctionne avec un fichier log en entrée, c'est automatiquement celui de la database que l'on veut surveiller, donc je ne vois pas l'utilité d'un tel paramètre... à moins qu'une log puisse être partagée par deux instances !
A moins que ce paramètre serve à différencier la database 'utilisateur', des base postgrès, template0 et template1... est-ce le cas ?
Merci Guillaume, ça fonctionne !
pouvez-vous maintenant me dire quelle est la différence entre une exécution de pgfouine avec l'option -database et sans cette option...
Merci d'avance..
je vous envoie aussi un extrait de ma log :
2011-04-12 15:13:48 CEST [10694]: [1-1] LOG: database system was shut down at 2011-04-12 15:13:42 CEST
2011-04-12 15:13:48 CEST [10694]: [2-1] LOG: checkpoint record is at 56/30DB05C8
2011-04-12 15:13:48 CEST [10694]: [3-1] LOG: redo record is at 56/30DB05C8; undo record is at 0/0; shutdown TRUE
2011-04-12 15:13:48 CEST [10694]: [4-1] LOG: next transaction ID: 0/10711376; next OID: 106855
2011-04-12 15:13:48 CEST [10694]: [5-1] LOG: next MultiXactId: 50; next MultiXactOffset: 99
2011-04-12 15:13:48 CEST [10694]: [6-1] LOG: database system is ready
2011-04-12 15:14:05 CEST [10759]: [1-1] LOG: duration: 510.231 ms statement: SELECT d.datname as "Name",
r.rolname as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding"
FROM pg_catalog.pg_database d
JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
ORDER BY 1;
2011-04-12 15:15:06 CEST [10917]: [1-1] LOG: duration: 713.306 ms statement: set datestyle to 'ISO'; select version(), case when pg_encoding_to_char(1) = 'SQL_ASCII' then 'UNKNOWN' else getdatabaseencoding() end;
2011-04-12 15:15:06 CEST [10917]: [2-1] LOG: duration: 161.249 ms statement: set client_encoding = 'UNICODE'
2011-04-12 15:15:07 CEST [10917]: [3-1] LOG: duration: 326.314 ms statement:
