Re: Sync Rep v19

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Sync Rep v19
Дата
Msg-id AANLkTikZwWkRxf2tYMc213Gk8U1xvtivvwN2xVmOw-mx@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sync Rep v19  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Sync Rep v19  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Sync Rep v19  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Yes, that can happen. As people will no doubt observe, this seems to be
> an argument for wait-forever. What we actually need is a wait that lasts
> longer than it takes for us to decide to failover, if the standby is
> actually up and this is some kind of split brain situation. That way the
> clients are still waiting when failover occurs. WAL is missing, but
> since we didn't acknowledge the client we are OK to treat that situation
> as if it were an abort.

Oracle Data Guard in the maximum availability mode behaves that way?

I'm sure that you are implementing something like the maximum availability
mode rather than the maximum protection one. So I'd like to know how
the data loss situation I described can be avoided in the maximum availability
mode.

Regards,

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


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep v19
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)