PostgreSQL Administration - Re: [Slony1-general] "Blueprints for High Availability"

Author

Re: [Slony1-general] "Blueprints for High Availability"

Jim C. Nasby

2006-01-20, 1:23 pm

<dons Nomex undies>
Well, I would generally have to agree on not using Slony 1 for HA. I
don't see how it could be considered acceptable to potentially lose
committed transactions when the master fails. Unless maybe my
understanding of Slony is flawed...

On Thu, Jan 19, 2006 at 07:42:47PM -0500, Brian A. Seklecki wrote:
> Wiley Press, ISBN 0-471-43026-9, Even Marcus & Hal Stern
>
> Whatever you do, don't read this book when planning your enterprise-class
> PostgreSQL cluster using Slony1. The author(s) give a scathing opinion of
> network based asynchronous database replication. Especially for redundant
> configurations within the same facility. They concede that the method has
> some applicable uses (facility to facility replication), but they go so
> far as to recommend long distance SAN before software+network.
>
> The entire text has a highly anti-microsoft undercurrent which makes it a
> real page-turner, unfortunately, most of the advice regarding HA
> application clusters has a commercial-UNIX oriented slant (they all but
> endorse VERITAS).
>
> The book only serves to further emphasize that there is no definitive FMS
> (Fail over Management Software) solution for Open Source UNIX-like OSs.
> No true platform-independent (well, Linux-HA[.org]) project that
> integrates with monitoring, databases, web servers, load balancers, RAID
> / SAN controller, etc.
>
> The projects are there (PostgreSQL, Slony, PGPool, Nagios, Net-SNMP,
> FreeVRRPd, FreeBSD, GNU/Linux, Linux-HA, etc..), there just no integration
> yet.
>
> ~BAS
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general@gborg.postgresql.org
> http://gborg.postgresql.org/mailman.../slony1-general
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Chris Browne

2006-01-20, 8:24 pm

jnasby@pervasive.com ("Jim C. Nasby") writes:
> <dons Nomex undies>
> Well, I would generally have to agree on not using Slony 1 for HA. I
> don't see how it could be considered acceptable to potentially lose
> committed transactions when the master fails. Unless maybe my
> understanding of Slony is flawed...

Well, that presumably depends on perspective.

A bank generally cannot ever afford to lose ANY transactions, which
would tend to mean that only synchronous replication would be any kind
of answer.

That kind of application points to really forcibly needing 2PC, which
doesn't tend to play well across WAN links.

Maximizing availability, which is what HA is forcibly and
unambiguously about ("High Availability"), is NOT exactly the same
thing as "providing guarantees that committed transactions can never
be lost."

- HA, in the context of DNS services, may not have any "transactional"
nature to it; you might well want to have several DNS servers kicking
around so that if one falls over, you don't have to notice. That does
not really imply anything about how you update your DNS configuration.

- HA, in the context of running your corporate web server, may just
involve having several web servers, any of which can take over upon
failure of other web servers.

Updating the static bits of those web servers might well be done by
taking them out of service, one by one, and copying the new data
into place; again, no "transactional" issue there at all.

Those are both reasonable examples of applications where one might
want to use HA; neither involve transactional guarantees *at all*.

I don't think Slony-I is the *only* tool one would want to use to
"improve availability;" if you do have bank-like "can't lose
transactions" requirements, that might well rule it out. Of course,
if those are the requirements, there may be a whole lot of possible
mechanisms that are ruled out.
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/emacs.html
Rules of the Evil Overlord #113. "I will make the main entrance to my
fortress standard-sized. While elaborate 60-foot high double-doors
definitely impress the masses, they are hard to close quickly in an
emergency." <http://www.eviloverlord.com/>

Sponsored Links