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

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: [Slony1-general] "Blueprints for High Availability"
Дата
Msg-id 60fynipmna.fsf@dba2.int.libertyrms.com
обсуждение исходный текст
Ответ на "Blueprints for High Availability"  ("Brian A. Seklecki" <lavalamp@spiritual-machines.org>)
Список pgsql-admin
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/>

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Dominic J. Eidson"
Дата:
Сообщение: Strange errors after some DB problems
Следующее
От: Stijn De Weirdt
Дата:
Сообщение: alter role