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