Re: Using RSYNC for replication?

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Using RSYNC for replication?
Date: 2003-01-29 17:48:26
Message-ID: 20030129124826.M4935@mail.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jan 29, 2003 at 10:29:17AM +0200, Denis A. Doroshenko wrote:
> What if there would be such a method: the database is "frozen", which
> means, all commited work is flushed to the database, ongoing changes
> are going to an alternative destination (kind of journal), while the
> original database becomes read-only with the "journal" on top of it
> (i.e. all inserts, updates and deletes made to journal are visible for
> the clients); later once the database is unfrozen, the jorunal is joined
> into the database (i.e. database is synched).
>
> Well, may be at least the above paragraph made you laughing. Doctors say

Actually, there is nothing to laugh about in the proposal. Some
commercial systems do it more or less like that.

This is really a way of making point-in-time backups, and using them
as a basis for replication, too. I think it may be a mistake to try
to overload point-in-time recovery and replication, however.
PostgreSQL stays remarkably close to the traditional UNIX approach of
small, specialised tools that can be stuck together to do something
larger. I like this approach, because it tends to localise bugs: a
problem in one area doesn't cause you pain in another.

That said, there is work going on with point-in-time for 7.4, so I
suspect you'll be able to take this approach in the near-ish future.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Garo Hussenjian 2003-01-29 17:58:48 Query gone wild
Previous Message Lincoln Yeoh 2003-01-29 17:41:55 Re: Firewalls and Postgres