Non

Slony fonctionne grace à des triggers qui se déclenchent à chaque modification de la base. Ces triggers remplissent une table d'activités (  sl_log_1 ou sl_log_2 ) qui contient les modifications à propager. Ces tables et ces triggers doivent être installés sur chaque bases du cluster de réplication puisque chaque noeud slony peut potentiellement devenir le noeud maitre.

\ds

Que donne le résultat de la requête ci-dessous ?

select * from pg_catalog.pg_tables where tablename = 'matable';

As-tu mis des majuscules dans le nom de la table quand tu l'as créée ?

Yahoo stocke plusieurs peta-octets dans un SGBD dérivé (fork) de Postgres :

http://glinden.blogspot.com/2008/05/yah … resql.html

D'autres systèmes de datawarehouse sont basés sur postgres ( netezza, greenplum )

Je ne connais pas d'exemples de bases PostgreSQL "non modifiées" hébergeant plusieurs Petas.  Il me sembla qu'arrivé à ce niveau-là, le problème essentiel est l'infrastructure de stockage.

Quoiqu'il en soit , si pour le moment vous avez "simplement" quelques Teras de données , démarrer avec PostgreSQL est un bon choix. Si jamais vous atteignez les limite de PG d'ici 3 ans, vous pourrez facilement migrer vers des entrepots de données basés sur Postgres.

Pour faire de la synchronisation à basse fréquence, plusieurs solutions sont possibles. Le choix dépend souvent de la taille de la base et du volume moyen de changements à propager.

On peut bien sur faire de la synchro par batch. Je ne connais pas assez Talend pour dire si c'est un outil adapté dans ce cas de figure.

On peut aussi opter pour du "log replay" : on stocke tous les ordres SQL sur le serveur maitre et on les transfert sur l'esclave pour qu'il les rejoue.  Playr (https://area51.myyearbook.com/trac.cgi/wiki/Playr ) peut faire ce genre de choses.

On peut également choisir un logiciel de réplication plus évolué comme Slony. Le temps de prise en main est un peu plus long mais au final ça apporte plus de souplesse et c'est plus évolutif en cas de montée en charge de la plate-forme.

Le dump que tu fais est au format SQL . pg_restore utilise des dumps binaires.

Donc soit tu fais des dumps au format binaire avec l'option -Fc

pg_dump -Fc -U postgres mabase > save%d%.dump

soit tu restaures avec la commandes psql

psql -d nouvellebase -f savexxxxx.dump

Quelle version de PostgreSQL utilisez-vous ?

Vérfiez la valeur de shared_buffers dans le fichier postgresql.conf. 
En général  sous windows quand le shared_buffers est trop élevé ( > 2GB ), on peut rencontrer ce genre de problèmes.

avec DBlink ça devrait pouvoir se faire comme ça. A vérifier

DROP TABLE table_destination; 
CREATE TABLE table_destination 
AS SELECT * 
     FROM dblink('dbname=base_source', 'select * from table_source')  AS lien_source (...);

Sinon le faire en ligne de commande me paraitplus élégant :

pg_dump --clean -t table_source base_source| psql base_destination

Bonjour,

Il faudrait un peu plus d'information :

Quelle est la version de PostgreSQL ?
Quelle la vitesse des disques ?
Quelle la commande de sauvegarde ?
Quelle est la valeur de checkpoint_segment ?

Je comprend pas cette phrase. PostgreSQL n'a pas n'ont plus le controle sur la pile TCP/IP et sur le driver de la carte ethernet
C'est pareil pour MySQL. La différence c'est que MySQL te cache cette complexité et ne te laisse pas le choix.

C'est faux. Il est possible avec la Warm Standby de savoir précisément quel est le dernier journal de transcation envoyé et déduire si l'esclave est désynchronisé. C'est plus rustique que ce que tu décris mais ça sera amélioré avec le Hot Standby

Regarde du coté de walmanager, un projet développé par Skype.

Là encore c'est faux :-) Le seul cas ou tu dois reconstuire entièrement ta base c'est lorsque master a subit un crash et que tu demandes à l'esclave de prendre le relai. En gros une fois que tu as transformé l'esclave en maitre, tu ne peux plus le retransformer en esclave. ça s'appelle le FAIL BACK, je suis pas certain que MySQL soit capable de le faire non plus.

Je vois déjà le troll arriver.  En terme de bidouillage, je suis pas sur que le projet MySQL ait des leçons à donner :-)
Pour donner juste deux exemples :

* Il y a des bugs connus depuis MySQL 5.0 qui n'ont pas été corrigés dans la 5.1. C'est le fondateur de MySQL qui le dit : http://monty-says.blogspot.com/2008/11/ … eased.html

* La doc de la 5.1 n'est pas traduite en français. Je trouve ça relativement décevant pour un projet qui a le prétention d'être le SGBD le plus populaire.

Attention à ne pas tout mélanger. Derrière le mot "réplication" on peut mettre énormément de concepts différents : Haute-disponibité ou répartition de charge, réplication synchrone ou asynchrone, symétrique ou asymétrique.

En l'occurence, le Warm Standby est une technique simple pour mettre en place un serveur de secours et garantir une reprise rapide en cas de panne. Cela n'a pas d'autre prétention. Le Hot Standby apportera des avancées intéressantes ( synchronicité, esclave accessible en lecture) et dans ce cas là les noeuds auront "conscience" de la présence des autres noeuds mais cela restera une solution limitée  sur certains aspects, le fail back et la granularité notamment.

Pour avoir, plus de finesse il faut se tourner vers des outils externes (Slony, bucardo) qui ajoutent de la complexité.

Il me parait également important de préciser quel moteur on utilise avec MySQL : les différences entre MyISAM et InnoDB ne sont pas anodines. Par exemple, je serais curieux de connaitre les perfs d'un cluster de réplication avec MYSQL/InnoDB

Druid ? ---> http://druid.sourceforge.net

Bonjour,

Je te conseille de rapporter ces différents problèmes directement aux développeurs de PostgreSQL :

http://www.postgresql.org/support/submitbug
http://www.postgresql.org/docs/current/ … rting.html