Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 1229379020.8673.346.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: "Kevin Grittner"
Date:
Subject: 8.4 replication questions
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] odd output in restore mode