The scenario where the cost seems regrettable is where someone is using
a PostgreSQL in an ISP web hosting context, where it would certainly be
nice to have 50 customers' data in separate databases. Slony-I really
isn't attuned to that scenario.
But if the load on the system is low enough that you can afford to have
50 databases hosted on one postmaster, then it seems improbable that
load balancing is one of the goals. I think, for that scenario, I'd
point to PITR as being "the answer." Slony-I isn't intended to be the
answer to every problem.
Hi the list,
After reading all you interesting answers, here are my conclusions :
Hosting 50+50 Slony clusters on *each* server is definitively not a
viable solution.
So :
- wether I group them into 50 schemas in one big database, and I use
Slony to handle replication,
- wether I keep my 50 databases distinct, and I use PITR.
In both cases, any failover will apply anyway to the 50 "entities"
(databases or schemas).
So I abandon completely the idea of managing switchover/failover of each
entity separately.
The question is now : which replication system will be the most adapted
to this situation (Slony or PITR) ?
- In the first case (50 schemas / 1 database / 1 Slony), I think I will
loose some flexibility (administration, migration of one entity to other
servers, etc...).
- In the second case (50 databases and PITR), I think I will be able to
handle switchover/failover in a similar manner than slony, but keeping
flexibility, allowing for example to still use Slony to migrate one
database to another server (correct me if I'm wrong) !
Moreover, Christopher is completely right on the fact that I don't need
load-balancing at all. I only need switchover/failover.
So, it seems that PITR is really the right solution for my case.
I think that I will setup the following scenario, on each server
(working by pairs) :
- 50 live databases hosted on one running instance of PostgreSQL,
- 50 other databases replicated via PITR (coming from the other
server), and ready to be serviced if needed, by a distinct PostgreSQL
instance (on a different TCP port).
So, in normal operation, 100 distinct databases should be splitted over
a pair of servers (running 50 databases per server).
And in case of switchover/failover, one of them would be servicing the
whole 100 databases.
Does it seem ok ?
Thank you very much !
Philippe Ferreira.
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
