Re: Standalone synchronous master

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Standalone synchronous master
Дата
Msg-id CAA4eK1K4X=J2Xju6nRHHGXaT8_ND975OKH+eSVK5MDQHCj5dFw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Standalone synchronous master  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Standalone synchronous master  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Список pgsql-hackers
On Sun, Jan 12, 2014 at 8:48 AM, Josh Berkus <josh@agliodbs.com> wrote:
> On 01/10/2014 06:27 PM, Bruce Momjian wrote:
>> How would that work?  Would it be a tool in contrib?  There already is a
>> timeout, so if a tool checked more frequently than the timeout, it
>> should work.  The durable notification of the admin would happen in the
>> tool, right?
>
> Well, you know what tool *I'm* planning to use.
>
> Thing is, when we talk about auto-degrade, we need to determine things
> like "Is the replica down or is this just a network blip"? and take
> action according to the user's desired configuration.  This is not
> something, realistically, that we can do on a single request.  Whereas
> it would be fairly simple for an external monitoring utility to do:
>
> 1. decide replica is offline for the duration (several poll attempts
> have failed)
>
> 2. Send ALTER SYSTEM SET to the master and change/disable the
> synch_replicas.
  Will it possible in current mechanism, because presently master will  not accept any new command when the sync
replicais not available?  Or is there something else also which needs to be done along with  above 2 points to make it
possible.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "MauMau"
Дата:
Сообщение: Re: Recovery to backup point
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] pg_upgrade & tablespaces