Er, yes, sorry, I didn't mean to imply that you should run without
some kind of STONITH solution, to catch the case when the link DRDB
uses goes down but the other network links are still working fine.
It's in the common case, when everything is working, that DRBD won't
accidentally let you mount the same device on both machines. (In my
experience, operator error more common than hardware error.)
On May 19, 2007, at 6:28 AM, Andrew Sullivan wrote:
> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly