On Mon, Dec 03, 2007 at 09:16:40AM +0100, Pascal Cohen wrote:
* For High-availability, I mainly studied PgPool and Log-shipping (and
in fact forgot Slony).
Until now I feel more comfortable with Log-shipping because it seems
safer (I am not sure I can't get some problems with sequences and
current_timestamp with PgPool - it is even mentioned in the doc).
Slony can do most things the current log shipping code can do (but it does
_not_ solve DDL changes automatically; you must control that differently).
Slony imposes a load on your origin server that log shipping does not.
I am not concerned with warm DDL changes (I would say currently because
one never knows ;) ).
In fact, if my master server only handles updates while request are
handled by one or more slaves, I can probably accept some overload on it
or if I adjust weights between Master and Slaves through PgPool, I
should be able to accept some load on Master.
Do you mean that Log-shipping is well for a Standby server not handling
request while Slony is good with "select" load balancing ?
Why and what limits Log-shipping for that case ?
When you ship logs, you more or less have the "replica" in recovery mode all
the time (as though you pulled the plug on the server). So it is always
recovering the shipped logs. This is also how Oracle did this for years,
although they've recently addressed the limitation. There is some promise
of doing this in Postgres in future, but it's not done yet.
Also, have a look at hardware answers for HA. That's the real current
answer for always-on service, if you ask me.
What kind of hardware solutions do you know ? - I will look on my own
what I can find.
Thanks
Pascal
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
