From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Real application clustering in postgres. |
Date: | 2020-03-06 14:55:27 |
Message-ID: | 29d192b7b0b198b5e1253fac35e7654331614053.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2020-03-06 at 03:25 -0600, Ron wrote:
> > RAC is not really a high availability solution: because of the shared
> > storage, it has a sibgle point of failure.
>
> This is utter nonsense. Dual redundant storage controllers
> connected to disks in RAID-10 configurations have been around for at
> least 25 years.
>
> Oracle got it's clustering technology from DEC, and I know
> that works. Cluster members, storage controllers and disks have all
> gone down, while the database and application keep on humming along.
I am not saying that it is buggy, it is limited by design.
If you have mirrored disks, and you write junk (e.g, because of
a flaw in a fibre channel cable, something I have witnessed),
then you have two perfectly fine copies of the junk.
I am not saying the (physical) disk is the single point of failure, the
(logical) file system is (Oracle calls it ASM / tablespace, but it is
still a file system).
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-03-06 15:00:46 | Re: How to allow users to create and modify tables only in their own schemas, but with generic table owner |
Previous Message | Andrei Zhidenkov | 2020-03-06 14:24:22 | Limit transaction lifetime |