Thomas Lopatic wrote: >> So what happens in those cases where the primary node gets in trouble >> but isn't actually dead yet? > > Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply > stop accepting replicated data from the primary node before firing up > postmaster? Then the postmaster on the primary DRBD node would only > write locally and not interfere with the secondary DRBD node. > > Unless I am missing something this would be a valid problem with shared > storage but not with DRBD-like replicated storage. (As long as the > secondary node can stop replicating if it decides to do so.)
Yes, you can always force DRBD to go split brain, if your really like it to do so, bit this is usually unwanted. Usually a shared block device is not the only resource a node holds. You would like to have it hold at least an IP address as well. So it buys you nothing if you could fire up PostgreSQL on the secondary as you still need to take over additional resources to bring your service back online AND you need to make sure that the primary node won't recover and won't reclaim ownership of resources that have been taken over by the secondary again. This is exactly what STONITH is for. If the secondary has the slightest reason to believe the primary node might be dead it takes that assumption and makes it reality. -- Best regards, Hannes Dorbath ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
