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

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: [Slony1-general] "Blueprints for High Availability"
Date: 2006-01-20 22:20:09
Message-ID: 60fynipmna.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

jnasby(at)pervasive(dot)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/>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Stijn De Weirdt 2006-01-21 11:48:36 alter role
Previous Message Dominic J. Eidson 2006-01-20 22:11:51 Strange errors after some DB problems