Re: Sync Rep Design - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Sync Rep Design
Date
Msg-id 4D23D09D.3000207@2ndquadrant.com
Whole thread Raw
In response to Re: Sync Rep Design  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> Based upon that series of conversations, I've reworked the design so
> that there is (currently) only a single standby offering sync rep at any
> one time. Other standbys can request to be sync standbys but they only
> become the sync standby if the first one fails. Which was simple to do
> and bridges the challenges of an exactly identified sync standby and the
> fragility of too closely specifying the config.
>   

That seems like a good enough starting point to cover a lot of cases.  
Presuming the two servers each at two sites config that shows up in a 
lot of these discussions, people in the "I need sync to a remote spot" 
can get that, and if that site is unavailable for long enough to be 
kicked out they'll smoothly degrade to sync on a secondary local copy.  
And those who want high performance local sync and best-effort for the 
remote site can configure for that too, and if the local secondary dies 
they'll just degrade to the slow remote commits.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: can shared cache be swapped to disk?
Next
From: Greg Smith
Date:
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid