Re: Real application clustering in postgres.

On 2020-03-09 09:57:37 +0100, Laurenz Albe wrote:
> On Sun, 2020-03-08 at 21:13 +0100, Peter J. Holzer wrote:
> > 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).
>
> Of course, nobody debates that.
>
> A high-availability solution only protects you from certain, well-defined
> kinds of problems, usually related to hardware.

Right. And enterprise class SAN storage does this: It protects you from
failure of a single disk, a single cable, a single controller. Very
often you can physically spread out the components so that loss of a
whole rack (or server room) wouldn't affect availability. There are of
course limits: When a message sent over a single cable is corrupted in a
way that the checksum doesn't catch, corrupted data may be stored. But
then if data in RAM is corrupted that ECC doesn't catch, the same will
happen. A Patroni-based cluster isn't free of single points of failure
either.

So I don't buy the argument "X isn't a high availability solution
because it uses shared storage". While I have seen expensive SAN boxes
fail, I've also managed to wreck Patroni clusters. I'm not at all
convinced that the availability of a Patroni cluster is higher than that
of a failover cluster using shared storage.

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!"