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 | [EMAIL PROTECTED]
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 [EMAIL PROTECTED] so that
your
message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
