Re: Using RSYNC for replication?

From: "Denis A(dot) Doroshenko" <d(dot)doroshenko(at)omnitel(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Using RSYNC for replication?
Date: 2003-01-29 08:29:17
Message-ID: 20030129102917.H8476@hermit.omnitel.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)umbc(dot)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(at)postgresql(dot)org

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Oleg Bartunov 2003-01-29 08:37:13 Re: tsearch comments
Previous Message Tom Lane 2003-01-29 08:21:14 Re: postgresql 7.3.1 + readline