Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] slony replication

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: sarlav kumar <sarlavk(at)yahoo(dot)com>
Cc: pgsqlnovice <pgsql-novice(at)postgresql(dot)org>,pgsqlperform <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORM] slony replication
Date: 2004-12-29 03:57:28
Message-ID: 200412282257.28265.xzilla@users.sourceforge.net (view raw or flat)
Thread:
Lists: pgsql-novicepgsql-performance
I didn't see any responses to this, but given it is off topic for both groups 
that wouldn't surprise me. In the future please direct these questions to the 
slony project mailing lists. 

On Monday 20 December 2004 17:25, sarlav kumar wrote:
> Hi All,
>
> I installed slony1.0.5 and tried the example replication of pgbench
> database. That seemed to work. Now I need to replicate a DB running on a
> different server. slony1.0.5 is installed on the Fedora core 3 machine
> where Postgres 7.4.6 is installed. I have to replicate the 'test' database
> installed on a different machine using Postgres 7.3.2.
>
> In the instructions to replicate the pgbench example, there is script file
> to create the initial configuration for the master-slave setup of the
> pgbench database. Is this the script file that has to be modified
> accordingly, to replicate my 'test' DB. And ofcourse, the shell variables
> have to be changed to indicate the correct location of the master and slave
> DBs. Am I right?
>

More or less.  The scripts provided are just examples, but you can modify them 
to suite your einvironment rather than write your own. 

> Also, in the script, the following lines are used to create sets of tables:
> # Slony-I organizes tables into sets.  The smallest unit a node can
>     # subscribe is a set.  The following commands create one set containing
>     # all 4 pgbench tables.  The master or origin of the set is node 1.
>  #--
>  create set (id=1, origin=1, comment='All pgbench tables');
>  set add table (set id=1, origin=1, id=1, fully qualified name =
> 'public.accounts', comment='accounts table'); set add table (set id=1,
> origin=1, id=2, fully qualified name = 'public.branches', comment='branches
> table'); set add table (set id=1, origin=1, id=3, fully qualified name =
> 'public.tellers', comment='tellers table'); set add table (set id=1,
> origin=1, id=4, fully qualified name = 'public.history', comment='history
> table', key = serial);
>
>  #--
>
> Can this be skipped? I have over 200 tables, and I am not sure if I have to
> list each of them in the "set add table" part of the scripts file.
>

nope, you have to do them all, and dont forget the sequences. easiest way i 
found was to generate the list programatically around a select * from 
pg_class with appropriate where clause to get just the desired tables. 

> Do I need to change any of the other scripts file in the example?
>

Chances are yes, since those scripts were written for the example scenario 
provided, and your environment is sure to be different.  Again, post to the 
slony mailing lists if you need more help. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In response to

pgsql-novice by date

Next:From: Keith WorthingtonDate: 2004-12-29 18:33:05
Subject: Creating a database with pg_restore
Previous:From: Alexander BorkowskiDate: 2004-12-28 23:58:06
Subject: Re: [PERFORM] user defined data type problem while dumping?

pgsql-performance by date

Next:From: george youngDate: 2004-12-29 18:58:58
Subject: Re: [PERFORM] INSERT question
Previous:From: Alexander BorkowskiDate: 2004-12-28 23:58:06
Subject: Re: [PERFORM] user defined data type problem while dumping?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group