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

Database replication under Postgres

From: Paul Breen <pbreen(at)computerpark(dot)co(dot)uk>
To: pgsql-admin(at)postgresql(dot)org
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Database replication under Postgres
Date: 1999-12-16 14:36:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Hello all, I wonder if anyone could help me.

I'm currently working on a project where it is essential that we have some
kind of replication of our production database.  I've found a number of
'near' solutions (e.g., doing a piped 'COPY IN/OUT' using psql - one
local and one remote - from a simple shell script) but this doesn't
'synchronise' the data, it just piles ALL the data from one database into
the other.

I've also looked into setting up rules on a table to NOTIFY me of an
insert|update|delete and then have a program that queries the difference
between the two databases and synchronises them accordingly. This is ok to
a point but is not particularly elegant or efficient.  Basically I was 
wondering if anyone knows of a better way of doing it or if someone has
written a tool for automating replication with Postgres.

If we were replicating data from one table to another in the SAME DATABASE
it would be easy to set up a rule such as:


Ideally, I suppose what I am after - and I dare say I'm hoping to much - 
is a simple solution that says the same as the above rule but where
"tbl2" is a table in a remote host's database.

I would be really grateful to hear from other users' experiences with any
form of replication/synchronisation under Postgres.

Thanks in advance.

Paul M. Breen
Computer Park Ltd
Email: pbreen(at)computerpark(dot)co(dot)uk

pgsql-interfaces by date

Next:From: Christophe MDate: 1999-12-16 15:41:31
Subject: Compatibility postgresql6.5.3 and psqlodbc drivers
Previous:From: Mike MascariDate: 1999-12-15 21:09:39
Subject: Re: [INTERFACES] <string> in pgconnection.h (?)

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