From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Would you ever recommend Shared Disk Failover for HA? |
Date: | 2024-02-22 19:49:53 |
Message-ID: | CANzqJaBi6J35oUcKBzUueWz1n0cB7f_xm=L=cvn==bnm2753VA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, Feb 22, 2024 at 2:35 PM norbert poellmann <np(at)ibu(dot)de> wrote:
> 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)
>
Our DB servers are also VMware VMs, with the disks managed by VMware, too.
If a blade dies, the VM automatically restarts on a different blade.
(Heck, ESX might automagically migrate it with no downtime. I've never
*known* this to happen, but I don't have access to the VMware console; they
just stay up for months, getting migrated around as necessary for load
management.)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-02-22 23:36:43 | Re: Another way to do audit in DML operations in PostgreSQL >= 14 |
Previous Message | Michael Banck | 2024-02-22 19:39:58 | Re: Problems installing APT version |