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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice pgsql-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

Browse pgsql-novice by date

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

Browse pgsql-performance by date

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