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
