Re: Replication - Mailing list pgsql-hackers

From F Harvell
Subject Re: Replication
Date
Msg-id 200202072235.g17MZhR17707@odin.fts.net
Whole thread Raw
In response to Re: Replication  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
I'm not that familiar with the whole replication issues in PostgreSQL,
however, I would be partial to replication that was based upon the
playback of the (a?) journal file.  (I believe that the WAL is a
journal file.)

By being based upon a journal file, it would be possible to accomplish
two significant items.  First, it would be possible to "restore" a
database to an exact state just before a failure.  Most commercial
databases provide the ability to do this.  Banks, etc. log the journal
files directly to tape to provide a complete transaction history such
that they can rebuild their database from any given snapshot.  (Note
that the journal file needs to be "editable" as a failure may be
"delete from x" with a missing where clause.)

This leads directly into the second advantage, the ability to have a
replicated database operating anywhere, over any connection on any
server.  Speed of writes would not be a factor.  In essence, as long
as the replicated database had a snapshot of the database and then was
provided with all journal files since the snapshot, it would be
possible to build a current database.  If the replicant got behind in
the processing, it would catch up when things slowed down.

In my opionion, the first advantage is in many ways most important.
Replication becomes simply the restoration of the database in realtime
on a second server.  The "replication" task becomes the definition of
a protocol for distributing the journal file.  At least one major
database vendor does replication (shadowing) in exactly this mannor.

Maybe I'm all wet and the journal file and journal playback already
exists.  If so, IMHO, basing replication off of this would be the
right direction.


On Thu, 07 Feb 2002 07:52:23 EST, mlw wrote:
> 
> I have in the back of my mind, an idea of patching into the WAL stuff, and
> using that mechanism to push changes out to the slaves.
> 
> Where one machine is still the master, but no trigger stuff, just a WAL patch.
> Perhaps some shared memory paradigm to manage WAL visibility? I'm not sure
> exactly, the idea hasn't completely formed yet.
> 




pgsql-hackers by date:

Previous
From: "D. Hageman"
Date:
Subject: Re: Threaded PosgreSQL server
Next
From: "D. Hageman"
Date:
Subject: Re: Threaded PosgreSQL server