Re: Synchronization levels in SR
От | Fujii Masao |
---|---|
Тема | Re: Synchronization levels in SR |
Дата | |
Msg-id | AANLkTimkxn-2jLDyBnGWGl_meKql3wn06kJRJJjplU25@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronization levels in SR (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Synchronization levels in SR
(Simon Riggs <simon@2ndQuadrant.com>)
|
Список | pgsql-hackers |
On Thu, May 27, 2010 at 7:21 PM, Simon Riggs <simon@2ndquadrant.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
В списке pgsql-hackers по дате отправления: