Ok thanks for these feedbacks.
I've understand important elements :
1 - I can tune store path
2 - logshipping is not adapted for warm-standby-like replication.

Why it seems a good idea to have 10 replicas at the "main" site ? Because
our production consists of several octocore / 24Go to serve 1000 queries /
sec and we have lag time constraint to replicate data <10sec. And obviously
we have backup databases at our main site.

J
2008/9/24 Christopher Browne <cbbrowne at ca.afilias.info>

> "J=E9r=F4me Jouanin" <jerome at jfg-networks.net> writes:
> > Because Slony documentation warns : "Reasonable," in this context,
> > is on the order of a dozen servers. If the number of servers grows
> > beyond that, the cost of communications increases prohibitively, and
> > the incremental benefits of having multiple servers will be falling
> > off at that point.  Moreover, I think a remote site could not have
> > the same level of network availability than a LAN, because of
> > external constraints. And I think that isolation is preferable in
> > this case.  Isn't it ?
>
> If it's remote, then it's remote.
>
> If you expect to have trouble getting data across the WAN to feed an
> active Slony-I node, then I wouldn't expect log shipping to be
> terribly much easier.  If either approach turns out to be problematic,
> I'd expect the other to be, too.
>
> Log shipping isn't particularly less fragile; it introduces additional
> "moving parts" in that you need to move the log files across the WAN.
>
> Actually, part of what I'd question is why it seems a good idea to
> have 10 replicas in the first place, at the "main" site.
> --
> (format nil "~S@~S" "cbbrowne" "linuxfinances.info")
> http://www3.sympatico.ca/cbbrowne/wp.html
> "war is an inappropriate analogy; ``flame war'' is a misnomer.
>  in any usenet exchange, the only casualty is time.
>  there are better uses for regret."
>    --thi <ttn at netcom.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20080925/=
db592ef9/attachment.htm