[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slony1-general
Subject:    Re: [Slony1-general] possible application
From:       Christopher Browne <cbbrowne () ca ! afilias ! info>
Date:       2005-11-24 15:59:25
Message-ID: 60oe4a3ule.fsf () dba2 ! int ! libertyrms ! com
[Download RAW message or body]

"Jim Kunkel" <jkunkel@laurcat.com> writes:
> We have a couple of dozen postgresql / apache servers running on
> LAN's for a client.  These are scattered around the country. 
> Presently, we pg_dump the databases once a day and rsync the files
> to a central backup.
>
> I would like to provide a read-only copy of the databases on a
> central server, so individual site data could be queried and
> analyzed centrally, but not changed and pushed back out.
>
> The overview documentation indicates that Slony is intended to be a
> single master to multiple slaves.  Can multiple masters replicate to
> many separate slave databases running on a single server?

That sounds relatively compatible with what Slony-I does.

Let me reword that a bit; let's see if this still makes sense...

You have 24 servers here and there where you wish to consolidate
read-only copies of the data onto one central server.

On Slony-I, one might do this by having 24 Slony-I clusters.

Each of those clusters has two nodes:
 - The origin node, scattered hither and thither by geography
 - One subscriber, a node sitting at [central location]

It would be theoretically possible to have the 24 clusters attached to
a single database on a single PostgreSQL backend, assuming you had 24
unique cluster names, and assuming all of the tables being replicated
had unique names across all 24 clusters.  (That would presumably
require that there be a distinct namespace/schema used for each
server...)

If the table names were not unique, then it would be more sensible to
have a separate database (probably on the same cluster) for each
subscriber.

There's another way this could, in principle, be handled...  

Again, assuming the table names are unique across the couple dozen
origin servers, you might set up ONE cluster that all 24 servers
participate in.  There would be a replication set for each origin; the
central server would be one database, which has all 24 sets of tables.
What is unfortunate about that approach is that if any node "falls
off," it will have some (indirect) performance effects on all the
other nodes.
-- 
output = ("cbbrowne" "@" "ca.afilias.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

[prev in list] [next in list] [prev in thread] [next in thread]