From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronization levels in SR |
Date: | 2010-05-25 19:19:36 |
Message-ID: | 4BFC22C8.4070600@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> How we handle degraded mode is important, yes. Whatever parameters we
> choose the problem will remain the same.
>
> Should we just ignore degraded mode and respond as if nothing bad had
> happened? Most people would say not.
>
> If we specify server1 = synch and server2 = async we then also need to
> specify what happens if server1 is down. People might often specify
> if (server1 == down) server2 = synch.
>
I have a hard time imagining including async servers in the quorum. If
an async servers vote is necessary to reach quorum due to a 'real' sync
standby server failure, it would mean that the async-intended standby is
now also in sync with the master transactions. IMHO this is a bad
situation, since instead of the DBA getting the error: "not enough sync
standbys to reach quorum", he'll now get "database is slow" complaints,
only to find out later that too much sync standby servers went south.
(under the assumption that async servers are mostly on too slow links to
consider for sync standby).
regards,
Yeb Havinga
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-05-25 19:20:03 | Re: Synchronization levels in SR |
Previous Message | Kevin Grittner | 2010-05-25 19:18:00 | Re: Exposing the Xact commit order to the user |