Admins, https://www.postgresql.org/docs/current/different-replication-solutions.html is listing a shared disk solution for HA. It also mentions, "that the standby server should never access the shared storage while the primary server is running." In a datacenter, where we have postgresql servers running on vmware VMs, the shared disk configuration sounds like an appealing solution: simple configuration, single server at a given time, simple fail-over, fully non-or-nothing write mechanics, no hazzle with replication_slots during/after failover, etc... But "Attempts to use PostgreSQL in multi-master shared storage configurations will result in extremely severe data corruption" (https://wiki.postgresql.org/wiki/Shared_Storage). So it seems to me, getting the comfort of a single server solution, which, in a failover, gets replaced by another single server, is paid by getting the low risk of high damage. I know of the provisions of fencing, STONITH, etc. - but in practise, what is a robust solution? For example: How can I STONITH a node while having network problems? Whithout reaching the host, I cannot shoot it, nor shut it. I also cannot wait for it get visible in the network again: another client might have interfered and commited a transaction upon the retired master server, faster than I can do some fencing/stonith or whatever. Would you share your opinions or practical business experiences on this topic? Thanks a lot cheers Norbert Poellmann -- Norbert Poellmann EDV-Beratung email : np@xxxxxx Severinstrasse 5 telefon: 089 38469995 81541 Muenchen, Germany telefon: 0179 2133436
