Re: Real application clustering in postgres.

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Real application clustering in postgres.
Date: 2020-03-06 16:56:10
Message-ID: 35ec4417-d7cb-3981-16c1-d98eb60a84cc@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/6/20 8:55 AM, Laurenz Albe wrote:
> 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.

Why do you have just one FC path?

> 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).

Why isn't the filesystem (or RDBMS) throwing checksum errors?  This was
standard stuff in legacy Enterprise RDBMSs 20 years ago.

--
Angular momentum makes the world go 'round.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Kerber 2020-03-06 17:19:46 Re: Real application clustering in postgres.
Previous Message Fabio Ugo Venchiarutti 2020-03-06 16:18:53 Re: Limit transaction lifetime