Re: Sync Rep Design

Поиск
Список
Период
Сортировка
От Joshua Tolley
Тема Re: Sync Rep Design
Дата
Msg-id 4d1d4d96.c605ec0a.1af2.ffffb7ef@mx.google.com
обсуждение исходный текст
Ответ на Re: Sync Rep Design  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: Sync Rep Design  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Dec 30, 2010 at 03:24:09PM -0500, Aidan Van Dyk wrote:
> On Thu, Dec 30, 2010 at 3:07 PM, Robert Treat <rob@xzilla.net> wrote:
>
> >> If primary crashes while commits are waiting for acknowledgement, those
> >> transactions will be marked fully committed if the primary database
> >> recovers, no matter how allow_standalone_primary is set.
> >
> > This seems backwards; if you are waiting for acknowledgement, wouldn't the
> > normal assumption be that the transactions *didnt* make it to any standby,
> > and should be rolled back ?
>
> This is the standard 2-phase commit problem.  The primary server *has*
> committed it, it's fsync has returned, and the only thing keeping it
> from returning the commit to the client is that it's waiting on a
> synchronous "ack" from a slave.

<snip>

> 2) initiate fsync on the primary first
>    - In this case, the slave is always slightly behind.  If if your
> primary falls over, you don't give commit messages to the clients, but
> if it recovers, it might have committed data, and slaves will still be
> able to catch up.
>
> The thing is that currently, even without replication, #2 can happen.

For what little it's worth, I vote for this option, because it's a problem
that can already happen (as opposed to adding an entirely new type of problem
to the mix).

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

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

Предыдущее
От: Joachim Wieland
Дата:
Сообщение: Re: Snapshot synchronization, again...
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Sync Rep Design