Re: Sync Rep Design

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Sync Rep Design
Дата
Msg-id 795581D6-9C8B-4DE3-B99F-CA7120FE6BFB@nasby.net
обсуждение исходный текст
Ответ на Re: Sync Rep Design  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Sync Rep Design  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Dec 30, 2010, at 3:27 PM, Robert Haas wrote:
>> synchronous_replication (boolean)
>>        Specifies whether transaction commit will wait for WAL records
>>        to be replicated before the command returns a "success"
>>        indication to the client.
>
> The word "replicated" here could be taken to mean different things,
> most obviously:
>
> - slave has received the WAL
> - slave has fsync'd the WAL
> - slave has applied the WAL

I think that comment is valid for the entire set of docs, actually. The document goes out of its way to avoid simple
phraseslike "replicated", but doesn't spell out exactly what is happening, ie: 

"Synchronous replication offers the ability to guarantee that all changes
made by a transaction have been transferred to at least one remote
standby server. This is an extension to the standard level of durability
offered by a transaction commit. This is referred to as semi-synchronous
replication."

Reading that, I'm left with the sense that this isn't a simple matter of "Oh, the data has been replicated to the slave
beforecommit returns", but nothing does a good job of clearly explaining what the distinction is and what it means.
Thissection: 

"The guarantee we offer is that the application will not receive
explicit acknowledgement of the successful commit of a transaction until
the WAL data is known to be safely received by the standby. Hence this
mechanism is technically "semi synchronous" rather than "fully
synchronous" replication."

does provide some enlightenment, but it's at the end of the section. I think it would be best if there was a section
rightat the beginning that talked about the data quality issue of sync replication and how we're avoiding it with our
semi-syncsolution. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




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

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep Design