Re: Using RSYNC for replication? - Mailing list pgsql-general

From Denis A. Doroshenko
Subject Re: Using RSYNC for replication?
Date
Msg-id 20030129102917.H8476@hermit.omnitel.lan
Whole thread Raw
In response to Re: Using RSYNC for replication?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Using RSYNC for replication?
List pgsql-general
Do not like stepping in with thoughts on a subject that can already
cause anger. Anyway, just a thought.

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
it is very healthy to laugh... :-)

This is how I understand FFS (fast file system) snapshots work for
background fsck and online backups. It is said to work in FreeBSD 5.0
(though I did not try it)...

On Tue, Jan 28, 2003 at 01:39:43PM -0500, Tom Lane wrote:
> jhihn1 <jhihn1@umbc.edu> writes:
> > I don't understand what is so hard about doing it this way.
>
> If you want separate installations, make separate installations.  Don't
> expect multiple databases in a single installation to be implemented
> with the same amount of overhead as separate installations would be.
> If we did it that way, we'd legitimately get complaints.
>
> > It would make replication so simple and fast.
>
> No it wouldn't; as I've been trying to explain to you, there are a lot
> of reasons why rsync'ing a database won't work.  Fixing a few of them
> doesn't produce a working solution.  Nor are we going to contort the
> system design to make a fundamentally wrongheaded approach to
> replication work.  rsync is just not the basis of a workable solution,
> because it doesn't and can't know anything about the database state or
> the semantics of the different files in the database.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
Denis A. Doroshenko, GPRS engineer, d.doroshenko@omnitel.net, +37069863486
Omnitel Ltd., Muitines Str. 35, LT-2600 Vilnius, Lithuania; www.omnitel.lt

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgresql 7.3.1 + readline
Next
From: "Alain RICHARD"
Date:
Subject: Re : Getting results from a dynamic query in PL/pgSQL