Re: Sync Rep: First Thoughts on Code

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Sync Rep: First Thoughts on Code
Дата
Msg-id 1229379020.8673.346.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Sync Rep: First Thoughts on Code  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Mon, 2008-12-15 at 13:06 -0800, Josh Berkus wrote:
> Peter Eisentraut wrote:
> > Simon Riggs wrote:
> >> I am truly lost to understand why the *name* "synchronous replication"
> >> causes so much discussion, yet nobody has discussed what they would
> >> actually like the software to *do*
> > 
> > It's the color of the bikeshed ...
> 
> Hmmm.  I thought this was pretty clear.  There's three levels of synch 
> which are useful features:
> 
> 1) "synchronus" standby which is really asynchronous, but only has a gap 
> of < 100ms.
> 
> 2) Synchronous standby which guarentees that all committed transactions 
> are on the failover node and that no data will be lost for failover, but 
> the failover node is still in standby mode.
> 
> 3) Synchronous replication where the standby node has identical 
> transactions to the master node, and is queryable read-only.

> Any of these levels would be useful and allow a certain number of our 
> users to deploy PostgreSQL in an environment where it wasn't used 
> before.  So if we can only do (2) for 8.4, that's still very useful for 
> telecoms and banks.

The (2) mentioned here could be any of sync points #2-5 referred to
upthread. Different people have requested different levels of
robustness. Looking at DRBD and Oracle, they both subdivide (2) into at
least two further levels of option. So (2) is too broad a brush to paint
with.

I don't believe that (2) as stated is sufficient for banks, though is
reasonable for many telco applications. But #4 or #5 would be suitable
for banks, i.e. we must fsync to disk for very high value transactions.

The extra code to do this is minor, which is why I've asked Fujii-san to
include it now within the patch.

All of this is controllable by the parameter synchronous_replication,
which it is important to note can be set for each individual transaction
rather than just fixed for the whole server. This is identical to the
way we can mix synchronous commit and asynchronous commit transactions.

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



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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: 8.4 replication questions
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] odd output in restore mode