MARK CALLAGHAN <mdcallag(at)gmail(dot)com> wrote:
> Markus Wanner <markus(at)bluegap(dot)ch> wrote:
>> Google invented the term "semi-syncronous" for something that's
>> essentially the same that we have, now, I think. However, I full
>> heartedly hate that term (based on the reasoning that there's no
>> semi-pregnant, either).
To be fair, what we're considering calling semi-synchronous is
something which tries to stay in synchronous mode but switches out
of it when necessary to meet availability targets. Your analogy
doesn't match up at all well -- at least without getting really
ugly.
> We didn't invent the term, we just implemented something that
> Heikki Tuuri briefly described, for example:
> http://bugs.mysql.com/bug.php?id=7440
>
> In the Google patch and official MySQL version, the sequence is:
> 1) commit on master
> 2) wait for slave to ack
> 3) return to user
>
> After step 1 another user on the master can observe the commit and
> the following is possible:
> 1) commit on master
> 2) other user observes that commit on master
> 3) master blows up and a user observed a commit that never made it
> to a slave
>
> I do not think this sequence should be possible in a sync
> replication system.
Then the only thing you would consider sync replication, as far as I
can see, is two phase commit, which we already have. So your use
case seems to be covered already, and we're trying to address other
people's needs. The guarantee that some people are looking for is
that a successful commit means that the data has been persisted on
two separate servers. Others want to try for that, but are willing
to compromise it for HA; in general I think they want to know when
the guarantee is not there so they can take action to get back to a
safer condition.
-Kevin