Re: Synchronization levels in SR

On 5/26/2010 12:55 PM, Heikki Linnakangas wrote:
> On 26/05/10 18:31, Robert Haas wrote:
>> And frankly, I don't think it's possible for quorum commit to reduce
>> the number of parameters.  Even if we have that feature available, not
>> everyone will want to use it.  And the people who don't will
>> presumably need whatever parameters they would have needed if quorum
>> commit hadn't been available in the first place.
> 
> Agreed, quorum commit is not a panacea.
> 
> For example, suppose that you have two servers, master and a standby, 
> and you want transactions to be synchronously committed to both, so that 
> in the event of a meteor striking the master, you don't lose any 
> transactions that have been replied to the client as committed.
> 
> Now you want to set up a temporary replica of the master at a 
> development server, for testing purposes. If you set quorum to 2, your 
> development server becomes critical infrastructure, which is not what 
> you want. If you set quorum to 1, it also becomes critical 
> infrastructure, because it's possible that a transaction has been 
> replicated to the test server but not the real production standby, and a 
> meteor strikes.
> 
> Per-standby settings would let you express that, but not OTOH the quorum 
> behavior where you require N out of M to acknowledge the commit before 
> returning to client.


You can do this only with per standby options, by giving each standby a 
weight, or a number of votes. Your DEV server would have a weight of 
zero, while your production standby's have higher weights, depending on 
their importance for your overall infrastructure. As long as majority 
means >50% of all votes in the house, you don't have a split brain risk.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin