Re: Data replication through disk replication - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: Data replication through disk replication
Date
Msg-id 20070519132819.GB13964@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Data replication through disk replication  (Ben <bench@silentmedia.com>)
Responses Re: Data replication through disk replication
Re: Data replication through disk replication
List pgsql-general
On Fri, May 18, 2007 at 05:03:30PM -0700, Ben wrote:

> that all changes are replicated, it won't say an fsync is finished until
> it's finished on the remote host too, and it won't let you mount the block
> device on the slave system (at least with 0.7x).

How can it guarantee these things?  The web pages say this:

    If the primary node fails, heartbeat is switching the
    secondary device into primary state and starts the
    application there. (If you are using it with a non-journaling
    FS this involves running fsck)

    If the failed node comes up again, it is a new secondary node
    and has to synchronise its content to the primary. This, of
    course, will happen whithout interruption of service in the
    background.

So what happens in those cases where the primary node gets in trouble
but isn't actually dead yet?  I see a potential for a race condition
here that is really troubling to me.  (Especially since it uses the
TCP/IP stack, which is notoriously subject to DoS on Linux.)  I think
you really had better have something like STONITH running to use
this.

> In case you think it matters, IBM recommends DRBD for DB2.

IBM also sells HACMP.  I refuse to comment on whether IBM's advice on
high availability products is worth taking seriously.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
        --Philip Greenspun

pgsql-general by date:

Previous
From: "ee e"
Date:
Subject: about the pgadmin3
Next
From: Kimball
Date:
Subject: tsearch2 keep throw-away characters