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