Re: Sync Rep: First Thoughts on Code

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Sync Rep: First Thoughts on Code
Дата
Msg-id 1229081707.13078.259.camel@hp_dx2400_1
обсуждение исходный текст
Ответ на Re: Sync Rep: First Thoughts on Code  ("Fujii Masao" <masao.fujii@gmail.com>)
Ответы Re: Sync Rep: First Thoughts on Code  (Aidan Van Dyk <aidan@highrise.ca>)
Список pgsql-hackers
On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote:
> >
> > Quite possibly a terminology problem.. I my case I said "sync rep"
> > meaning the mode such that the transaction doesn't commit successfully
> > for my PG client until the xlog record has been "streamed" to the
> > client... and I understand that at his presentation at PGcon, Fujii-san
> > there could be possible variants on when the "streamed" is considered
> > done based on network, slave ram, disk, application, etc.
> 
> I'd like to define the meaning of "synch rep" again. "synch rep" means:
> 
> (1) Transaction commit waits for WAL records to be replicated to the standby
>       before the command returns a "success" indication to the client.

> (2) The standby has (can read) all WAL files indispensable for recovery.

I would change "can read" in (2) to "has access to". "Can read" implies
we have read all files and checked CRCs of individual records.


The crux of this is what we mean by "synchronous_replication = on".
There are two possible meanings:

1. Commit will wait only if streaming is available and has waited for
all necessary startup conditions.
This provides "Highest Availability"

2. Commit will wait *until* full sync rep is available. So we don't
allow it until standby fails and also don't allow it if standby goes
down.
This provides "Highest Transaction Durability", though is fairly
fragile. Other systems recommend use of multiple standby nodes if this
option is selected.

Perhaps we should add this as a third option to synchronous_replication,
so we have either off, on, only

So far I realise I've been talking exclusively about (1). In that mode
synchronous_replication = on would wait for streaming to complete even
if last WAL file not fully transferred. 

For (2) we need a full interlock. Given that we don't currently support
multiple streamed standby servers, it seems not much point in
implementing the interlock (2) would require. Should we leave that part
for 8.5, or do it now?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: "Ian Caulfield"
Дата:
Сообщение: Re: WIP: default values for function parameters
Следующее
От: Zeugswetter Andreas OSB sIT
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)