Re: Synchronization levels in SR

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

In response to

Responses

Browse pgsql-hackers by date

  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