Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rdErW-004Yc4-8U for pgsql-admin@arkaria.postgresql.org; Thu, 22 Feb 2024 19:36:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rdEqW-00DRZH-MA for pgsql-admin@arkaria.postgresql.org; Thu, 22 Feb 2024 19:35:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rdEqW-00DRZ9-B9 for pgsql-admin@lists.postgresql.org; Thu, 22 Feb 2024 19:35:04 +0000 Received: from mail.ibu.de ([136.243.18.157] helo=ibu.de) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rdEqP-000TvV-Tt for pgsql-admin@lists.postgresql.org; Thu, 22 Feb 2024 19:35:03 +0000 Received: from mail.ibu.de (localhost [127.0.0.1]) by ibu.de (8.17.1/8.17.1) with ESMTP id 41MJYtAx050916 for ; Thu, 22 Feb 2024 20:34:55 +0100 (CET) (envelope-from np@ibu.de) From: "norbert poellmann" To: pgsql-admin@lists.postgresql.org Subject: Would you ever recommend Shared Disk Failover for HA? Date: Thu, 22 Feb 2024 20:34:55 +0100 Message-Id: <20240222185937.M23609@ibu.de> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 193.187.3.11 (np) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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@ibu.de Severinstrasse 5 telefon: 089 38469995 81541 Muenchen, Germany telefon: 0179 2133436