Re: Issues with Quorum Commit - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: Issues with Quorum Commit
Date
Msg-id 4CADC322.1000700@bluegap.ch
Whole thread Raw
In response to Re: Issues with Quorum Commit  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Issues with Quorum Commit
Re: Issues with Quorum Commit
List 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 by date:

Previous
From: Vincenzo Romano
Date:
Subject: Re: On Scalability
Next
From: Fujii Masao
Date:
Subject: Re: Sync Rep at Oct 5