replication recommendation

We are running PG 8.4.4 on Suse 9 and would like to set up a master/slave c=
onfiguration but have the following requirements:
- we want to be able to freeze the slave and only force it to update 'on de=
mand'
- we have data in other schemas in the slave database that we would like to=
preserve

The master and slave will exist on different servers if that helps. The mas=
ter DB is roughly 40 GB in size. I realize we could do a dump on master and=
restore to slave, but it seems like there might be a more elegant and effi=
cient solution.

Does anyone have any recommendations about the best replication solution gi=
ven these requirements?
Thanks in advance

Information in this e-mail may be confidential. It is intended only for the=
addressee(s) identified above. If you are not the addressee(s), or an empl=
oyee or agent of the addressee(s), please note that any dissemination, dist=
ribution, or copying of this communication is strictly prohibited. If you h=
ave received this e-mail in error, please notify the sender of the error.

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: replication recommendation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> We are running PG 8.4.4 on Suse 9 and would like to set up a
> master/slave configuration but have the following requirements:
> - we want to be able to freeze the slave and only force it to update 'on demand'
> - we have data in other schemas in the slave database that we would like to preserve
>
> The master and slave will exist on different servers if that helps.
> The master DB is roughly 40 GB in size. I realize we could do a dump on
> master and restore to slave, but it seems like there might be a more elegant
> and efficient solution.

This could be accomplished with Bucardo (http://bucardo.org). Setup a sync,
make sure "ping" is off (so it does not automatically update the slave
on master activity), and then you can manually "kick" the sync whenever you
want to update the slave. (Apologies for all the Bucardo terminology)

Some possible drawbacks:

* Bucardo can only replicate tables incrementally that have a primary
key or a unique index. If the table has neither, it can only copy
the entire table each time.

* If you go a long time between slave updates, the table that holds
queued changes on the master will get quite large, and the update
will, naturally, take longer. Both are not too much of a concern, but
if you have tables that change nearly all of their data between updates,
you may want to switch to a different method and copy the entire table
instead.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201007191737
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B90 6714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxExdYACgkQvJuQZxSWSshTMgCgmNBMil740wtFMtAut083 GKET
dv8AoOqhtNLy5orQGOJK4eZrWJzbJxG9
=iUBd
-----END PGP SIGNATURE-----



--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin