Re: Issues with Quorum Commit

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: Issues with Quorum Commit
Дата
Msg-id 4CADC322.1000700@bluegap.ch
обсуждение исходный текст
Ответ на Re: Issues with Quorum Commit  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Issues with Quorum Commit  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Issues with Quorum Commit  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
Salut Dimitri,

On 10/07/2010 12:32 PM, Dimitri Fontaine wrote:
> Another one is to say that I want sync rep when the standby is
> available, but I don't have the budget for more. So I prefer a good
> alerting system and low-budget-no-guarantee when the standby is down,
> that's my risk evaluation.

I think that's a pretty special case, because the "good alerting system"
is at least as expensive as another server that just persistently stores
and ACKs incoming WAL.

Why does one ever want the guarantee that sync replication gives to only
hold true up to one failure, if a better guarantee doesn't cost anything
extra? (Note that a "good alerting system" is impossible to achieve with
only two servers. You need a third device anyway).

Or put another way: a "good alerting system" is one that understands
Postgres to some extent. It protects you from data loss in *every* case.
If you attach at least two database servers to it, you get availability
as long as any one of the two is up and running. No matter what happened
before, even a full cluster power outage is guaranteed to recover from
automatically without any data loss.

[ Okay, the standby mode that only stores and ACKs WAL without having a
full database behind still needs to be written. However, pg_streamrecv
certainly goes that direction already, see [1]. ]

Sync replication between really just two servers is asking for trouble
and certainly not worth the savings in hardware cost. Better invest in a
good UPS and redundant power supplies for a single server.

> The question then is, should the new configuration alter running
> transactions?

It should definitely affect all currently running and waiting
transactions. For anything beyond three servers, where quorum_commit
could be bigger than one, it absolutely makes sense to be able to just
lower the requirements temporarily, instead of having to cancel the
guarantee completely.

Regards

Markus Wanner


[1]: Using streaming replication as log archiving, Magnus Hagander
http://archives.postgresql.org/message-id/AANLkTi=_BzsYT8a1KjtpWZxNWyYgqNVp1NbJWRnsD_Nv@mail.gmail.com


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

Предыдущее
От: Vincenzo Romano
Дата:
Сообщение: Re: On Scalability
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Sync Rep at Oct 5