Re: Replication

Thanks to all who replied and filled in the blanks.  The problem with the web is you never know if you've missed
something.

Joshua D. Drake wrote:
>> Looking for replication solutions, I find...
>> Slony-II
> Dead

Wow, I'm surprised.  Is it dead for lack of need, lack of resources, too complex, or all of the above?  It sounded like
sucha promising theoretical foundation. 

Ben wrote:
> Which replication problem are you trying to solve?

Most of our data is replicated offline using custom tools tailored to our loading pattern, but we have a small amount
of"global" information, such as user signups, system configuration, advertisements, and such, that go into a single
small(~5-10 MB) "global database" used by all servers. 

We need "nearly-real-time replication," and instant failover.  That is, it's far more important for the system to keep
workingthan it is to lose a little data.  Transactional integrity is not important.  Actual hardware failures are rare,
andif a user just happens to sign up, or do "save preferences", at the instant the global-database server goes down,
it'snot a tragedy.  But it's not OK for the entire web site to go down when the one global-database server fails. 

Slony-I can keep several slave databases up to date, which is nice.  And I think I can combine it with a PGPool
instanceon each server, with the master as primary and few Slony-copies as secondary.  That way, if the master goes
down,the PGPool servers all switch to their secondary Slony slaves, and read-only access can continue.  If the master
crashes,users will be able to do most activities, but new users can't sign up, and existing users can't change their
preferences,until either the master server comes back, or one of the slaves is promoted to master. 

The problem is, there don't seem to be any "vote a new master" type of tools for Slony-I, and also, if the original
mastercomes back online, it has no way to know that a new master has been elected.  So I'd have to write a bunch of
SOAPservices or something to do all of this. 

I would consider PGCluster, but it seems to be a patch to Postgres itself.  I'm reluctant to introduce such a major
pieceof technology into our entire system, when only one tiny part of it needs the replication service. 

Thanks,
Craig