Re: Real application clustering in postgres.

On 2020-03-06 15:55:27 +0100, 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.

I have certainly seen enterprise SAN boxes go down (or deliver corrupted
data) because of controller or firmware problems or just because a
second disk in a RAID-5 failed before the spare could be brought online.

But to be fair, a master/slave setup a la patroni isn't immune against
"writing junk" either: Not on the hardware level (either of the nodes
may have faulty hardware, and you may not notice it until too late), and
more importantly, not on the software level. An erroneus DML statement
(because of a bug in the application, or because the user/admin made a
mistake) will cause the same wrong data to be distributed to all nodes
(of course this also applies to RAC).

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"