Re: Synchronization levels in SR

On Wed, May 26, 2010 at 1:26 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2010-05-26 at 11:31 -0400, Robert Haas wrote:
>> > Your reply has again avoided the subject of how we would handle failure
>> > modes with per-standby settings. That is important.
>>
>> I don't think anyone is avoiding that, we just haven't discussed it.
>
> You haven't discussed it, but even before you do, you know its better.
> Not very compelling perspective...

I don't really understand this comment.  I have said, and I believe,
that a system without quorum commit is simpler than one with quorum
commit.  I'd debate the point with you but I find the point so
self-evident that I don't even know where to begin arguing it.  I am
not saying, and I have not said, that we shouldn't have quorum commit.I am saying that it is not something that we need
toadd as part of 
an initial sync rep patch, because we can instead add it in a
follow-on patch.  As far as I can tell, we are not trying to decide
between two competing approaches and therefore do not need to decide
which one is better.

Everything you are proposing sounds useful and valuable.  I am not
sure whether it handles all of the use cases that folks might have.
For example, Heikki mentioned the case upthread of wanting to wait for
a commit ACK from one of two servers in the data center A and one of
two servers in data center B, rather than just two out of four servers
total.  So, we might need to think a little bit about whether we want
to handle those kinds of cases and what sort of infrastructure we
would need to support it.  But certainly I think quorum commit sounds
like a good feature and I hope it will be included in 9.1, or if not
9.1, then some future version.

What I don't agree with is that it needs to be part of the initial
implementation of sync rep.  If there's a case for doing that, I don't
believe it's been made on this thread.  At any rate, the fact that I
don't see it as a sine qua non for sync rep is neither obstructionism
nor an ad hominem attack.  It's simply an opinion, which I believe to
be based on solid technical reasoning, but which I might change my
mind about if someone convinces me that I'm looking at the problem the
wrong way.  That would an involve someone making an argument of the
following form: "If we don't implement quorum commit in the very first
implementation of sync rep, then it will be hard to add later because
X."  So far no one has done that.  You have made the similar argument
"If we do implement quorum commit in the very first version of sync
rep, it will save implementation work elsewhere" - but I don't think
that's true and I have explained why.

>> The thing is, I don't think quorum commit actually does anything to
>> address that problem.  If I have a master and a standby configured for
>> sync rep and the standby goes down, we have to decide what impact that
>> has on the master.  If I have a master and two standbys configured for
>> sync rep with quorum commit such that I only need an ack from one of
>> them, and they both go down, we still have to decide what impact that
>> has on the master.
>
> That's already been discussed, and AFAIK Masao and I already agreed on
> how that would be handled in the quorum commit case.

I can't find that in the thread.  Anyway, again, you're going to
probably want the same options there that you will in the "master with
one standby" case, which I personally think is going to be a LOT more
common than any other configuration.

> [configuration example]
> The Oracle way doesn't allow you to specify that if near1 and near2 are
> down then we should continue to SYNC via remote, nor does it allow you
> to specify things from user perspective or at transaction level.
>
> You don't need to do it that way, for sure. But we do need to say what
> way you would pick, rather than just arguing against me before you've
> even discussed it here or off-list.

Well, again, I am not arguing and have not argued that we shouldn't do
it, just that we shouldn't do it UNTIL we get the basic stuff working.On the substance of the design, the Oracle way
doesn'tlook that bad 
in terms of syntax (I suspect we'll end up with some of the same
knobs), but certainly I agree that it would be nice to do some of the
things they can't which you have detailed here.  I just don't want us
to bite off more than we can chew.  Then we might end up with nothing,
which would suck.

>> I agree we need to talk about, but I don't agree
>> that putting in quorum commit will remove the need to design that
>> case.
>
> Yes, you need to design for that case. It's not a magic wand.
>
> All I've said is that covering the common cases is easier and more
> flexible by choosing transaction-centric style of parameters, and it
> also allows user settable behaviour.

One of the ideas you proposed upthread, in terms of
transaction-centric behavior, is having an individual transaction be
able to ask for a weaker integrity guarantee than whatever the default
is.  I think that is both a very good idea and probably something we
should implement relatively early on - though still maybe not in the
first patch.  I think there are a lot of people who will have SOME
transactions (user transfers money to other user) that absolutely have
to be durable and other transactions (user logs in) that we can risk
losing in the event of a crash.

> I want to do better than Oracle, if possible, using lessons learned. I
> don't want to do the same thing because we're copying them or because
> we're going down the same conceptual dead end they went down. We should
> try to avoid doing something obvious and aim a little higher.

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company