Re: Synchronization levels in SR

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronization levels in SR
Date: 2010-05-27 10:50:34
Message-ID: AANLkTimkxn-2jLDyBnGWGl_meKql3wn06kJRJJjplU25@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 27, 2010 at 7:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Seems strange. If you have 2 standbys and you say you would like node1
> to be the preferred candidate, then you load it so heavily that a remote
> server with by-definition much larger network delay responds first, then
> I say your preference was wrong. The above situation is caused by the
> DBA and the DBA can solve it also - if the preference is to keep a
> "preferred" server then that server would need to be lightly loaded so
> it could respond sensibly.

No. Even if the load is very low in the "preferred" server, there is
*no* guarantee that it responds first. Per-standby setting can give
such a guarantee, i.e., we can specify #2, #3 or #4 in the "preferred"
server and #1 in the other.

> This is the same thing as having an optimizer pick the best path and
> then the user saying "no dumb-ass, use the index I tell you" even though
> it is slower. If you really don't want to know the fastest way, then I
> personally will agree you can have that, as is my view (now) on the
> optimizer issue also - sometimes the admin does know best.

I think that choice of wrong master causes more serious situation than
that of wrong plan.

>> Also the administrator generally doesn't
>> put the remote standby under the control of a clusterware like heartbeat.
>> In this case, the remote standby will never be the candidate for failover.
>> But quorum commit cannot cover this simple case.
>
> If you, Jan and Yeb wish to completely exclude standbys from being part
> of any quorum, then I guess we need to have per-standby settings to
> allow that to be defined. I'm in favour of giving people options. That
> needn't be a mandatory per-standby setting, just a non-default option,
> so that we can reduce the complexity of configuration for common cases.
> If we're looking for simplest-implementation-first that isn't it.

For now, I agree that we support a quorum commit feature for 9.1 or later.
But I don't think that it's simpler, more intuitive and easier-to-understand
than per-standby setting. So I think that we should include the per-standby
setting in the first patch.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2010-05-27 10:54:31 Re: pg_trgm
Previous Message Simon Riggs 2010-05-27 10:33:41 Re: Synchronization levels in SR